Closed cshaa closed 7 years ago
The only thing that jumps out as a possible culprit is it being a regional thing, however this is doubtful. This is kind of why frameworks like .Net are so useful.
Please install this special build attached; I have implemented a lot of Try...Catch statements, especially in calling the Settings dialogue box. Send me some screenshots of any error messages that appear; they should all be handled now, if it has anything to do with the Settings form class.
The error when exiting the app is still the same:
The error window when opening the settings has changed, but the message is virtually the same:
+1, same issue on Windows 10 Pro build 15007
English version of the stack trace, just in case due to the possibility of it being a regional thing.
See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.
** Exception Text ** System.NullReferenceException: Object reference not set to an instance of an object. at AlwaysOnTop.Classes.FormSettings.FormSettings_Load(Object sender, EventArgs e) at System.Windows.Forms.Form.OnLoad(EventArgs e) at System.Windows.Forms.Form.OnCreateControl() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl() at System.Windows.Forms.Control.WmShowWindow(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ContainerControl.WndProc(Message& m) at System.Windows.Forms.Form.WmShowWindow(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
** JIT Debugging ** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled.
For example:
When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.
Interesting... I never had this issue before, but I just reinstalled Windows 10 build 1607 on my dev PC (had OneDrive issues anyway), and now I get the same thing, but only when I'm running from the installed application (the debugging app, which is wrapped around vshost.exe, still works fine). This tells me there's a dependency issue in the installer and that I'm leaving something out when compiling.
Do either of you get the same results when opening other dialogue boxes (About or Help)?
Appears to only happen with settings, I tried all the other tray options.
I forgot to mention, I haven't used the special build. Would it be helpful if I tried that?
@jwhipp are you using 32 bit Windows or 64 bit?
So this started happening to me (see above, reinstalled Windows), until I installed Visual Studio. There was a couple Visual C++ packages that got installed alongside Visual Studio 2015 Community
@jwhipp & @m93a , I am attaching a batch script that will search your registry for all installed software labeled "Visual C++". It will output a file called "software_list.txt" in the same folder as the batch script. Please run that script and attach the text file in a reply. May have a solution very soon.
Also attaching the Visual C++'s I have installed, as I'll likely be at work before I see this, rather than home.
Windows 10 Pro 64 bit
software_list.text:
Visual C++ Packages Installed ================= "Microsoft Visual C++ 2013 x64 Additional Runtime - 12.0.21005" "Microsoft Visual C++ 2013 x64 Minimum Runtime - 12.0.21005"
Ok, good news is I have found the cause of the unhandled exception in the Exit method.
In my primary class, I had a check against the user settings in the registry... if Use Hotkey = 1 and Hotkey != "", register a globalKeyboardHook and provide it the keys signaled in the registry.
The Exit method was calling the unhook method in the keyboard hook, so that any hotkeys registered would be de-registered. Since conditionals will only declare that IF the condition is true (so only in half scenarios) .Net was saying "Ok, this object may or may not exist, so let's throw a vague exception".
This is fixed by added an Else { } statement and declaring a blank globalKeyboardHook that does not register any keys or key events. This fix will be implemented in the next release.
Now on to troubleshoot the Settings exception....
And more good news. Found the settings crash. Turns out, if the hotkey was never set, it never created a registry entry. When the settings was opened, it was trying parse and separate the registry setting into the separate keys (modifier + key). If that setting was blank, it was returning NULL - so rather than checking to see if the setting returned "", it now determines if the string IsNullOrWhiteSpace (so it checks for null, "", or whitespace".
Fixes are implemented in code, will be fixed in next release (waiting until I get the updater portion corrected)
Bug fixed in version 0.6.1. Please download and install that version.
Thanks for catching this guys - I really need to set up a "clean" VM to test my products on, and will do that in the near future, to hopefully avoid this issue.
Let me know if you encounter any new bugs by filling out a new issue. If this one requires re-opening, please let me know!
I've got a fresh install of v0.5.0 (I downloaded the
AlwaysOnTop-Installer.exe
). When I try to open the settings window, the JIT runtime throws this error:Its in Czech but basically it says
Text of the exception
andLink (pointer?) is not set to the object's instance
. However if I clickContinue
, it runs anyway. Similarly if I choose to exit the program, an error shows up, this time:My system info:
More debug info:
I've got Visual Studio 2015, very basic knowledge of C# and I'm willing to help with debugging, if it doesn't take too much time.