BEopt 3b1 crashes on Windows 11
I was recently required to upgrade to Windows 11 and can no longer run BEopt 3. The beta worked fine on Windows 10, but on Windows 11 it crashes immediately after selecting and confirming the application type. It also crashes if I open one of the sample files via the context menu. I see the two following events in the application event log:
Application: BEopt.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.NullReferenceException at NREL.BEopt.BEoptUIVB.My.MyApplication.MyApplication_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.raise_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnUnhandledException(Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[]) at NREL.BEopt.BEoptUIVB.My.MyApplication.Main(System.String[])
Faulting application name: BEopt.exe, version: 3.0.1.0, time stamp: 0x64133c6a Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x0d4af466 Faulting process id: 0x0x7D28 Faulting application start time: 0x0x1DAD7ABB054DED1 Faulting application path: C:\Program Files (x86)\NREL\BEopt_3.0.1\BEopt.exe Faulting module path: unknown Report Id: 26a8b599-d66f-4e51-8a32-0e2176035a3c Faulting package full name: Faulting package-relative application ID:
What's the solution? Is 3.0 final coming soon and able to resolve this?
UPDATE: This appears to be because Windows 11 has some harsher controls on Program Files. If one runs BEopt as administrator (not a viable solution, just a debugging check) it will launch without crashing, although a warning is thrown:
Message: The following application error has occurred in BEopt v3.0.1.0. Please report this to the BEopt development team and restart the application.
Could not find a part of the path 'C:\Users\jpierce\Documents\BEopt_3.0.1\Data\Emissions'.
Stack Trace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileSystemEnumerableIterator
1.CommonInit() at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost) at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption) at System.IO.DirectoryInfo.GetFiles(String searchPattern, SearchOption searchOption) at NREL.BEopt.BEoptUIVB.SiteControl.PopulateCO2eElectricityFiles() in C:\git\beopt\Source\BEopt\SiteControl.vb:line 742 at NREL.BEopt.BEoptUIVB.SiteControl..ctor(BEoptCase& aCase, Font parentFont) in C:\git\beopt\Source\BEopt\SiteControl.vb:line 64
BEopt has not been tested on Windows 11 yet. Weird that it's complaining about a missing directory (C:\Users\jpierce\Documents\BEopt_3.0.1\Data\Emissions). Does it really not exist? If you delete your C:\Users\jpierce\Documents\BEopt_3.0.1 directory and run BEopt again, do you get the same problem?
Fair enough, Windows 11 is awful... contributing to the low market penetration (~1/3) two years on.However, 10 is reaching end of life "real soon now."
Yes, the Emissions directory error occurs after deleting the the Documents folder. However, I just noticed that path has a username in it. Perhaps the code is cobbling together the path based on username rather than the official user directory getter? The issue with that is that due to the unfortunate way the IT folks setup this new machine, my home directory is not the same as my username, but is instead "username.hostname".
BEopt retrieves the documents directory using
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments). I don't immediately see any reason why it should be doing something different...Hmm, I don't know. What I presume is the powershell analog (I would expect it uses the same Win32 API) of [Environment]::GetFolderPath("MyDocuments") does return the accurate path of "C:\Users\jpierce.hostname\Documents\" rather than "C:\Users\jpierce\Documents\".
"C:\Users\jpierce\" exists, but is a different user, and this account [jpierce.hostname] does not have access to that folder.