What Happens When My Application Throws An Unhandled Exception


There are several different behaviors that can occur when a managed application throws an unhandled exception.  The two most common are to bring up an error dialog box, or to pop up the Visual Studio Just In Time Debugger dialog box.


The first behavior is the default when you install the CLR, but don’t install Visual Studio.  Installing VS modifies the default to pop up the select-a-debugger dialog.  How does the CLR figure out what behavior to use?  It checks a registry key, located at HKLM\Software\Microsoft\.NetFramework\DbgJITDebugLaunchSetting.  The value of this key lets the CLR know what to do when it encounters an unhandled exception.  Possible values are:















Value Action
0 Bring up the unhandled exception dialog box. (Click OK to terminate …)
1 Print out the stack trace of the exception and terminate the application
2 Invoke the default managed debugger

If the value is set to 2, then the CLR consults HKLM\Software\Microsoft\.NetFramework\DbgManagedDebugger to determine which debugger to launch.  This debugger is expected to be a managed debugger, that uses the CLR debugging interface.  The debugger listed in this key will get four parameters, specified using printf style % format characters.  The parameters are:


















Parameter number Meaning
1 PID of the process
2 ID of the AppDomain
3 Exception string (“System.OutOfMemoryException”), as a wide character string
4 Event handle to signal when aborting the attach operation

By default, Visual Studio registers the VSJITDebugger.exe program as the debugger, which is what is responsible for displaying the familiar choose-a-debugger dialog box.  The default registration for this debugger in Visual Studio 2003 is:



“C:\Program Files\Common Files\Microsoft Shared\VS7Debug\VsJITDebugger.exe” PID %d APPDOM %d EXTEXT “%s” EVTHDL %d


 

Comments (6)

  1. Anderson Imes says:

    This has been broken in my IDE for ages. Thanks for posting this. My DbgJITDebugLaunchSetting was set to ‘0’. Oddly, the rest of the settings were ok. I haven’t tested it yet, but I think this would definitely be the reason I couldn’t debug unhandled exceptions

  2. David Srbecky says:

    I want to handle unhandled exceptions using my own managed program.

    How can I signal the event handle? I tried to interop to kernel32.dll SetEvent(IntPtr hEvent), but it does not seem to work.

    kernel32.dll TerminateProcess(IntPtr hProcess, uint uExitCode) fails too.

  3. Emmanuel Stapf says:

    Do you know what the value of 0x10 means? I got that in my 64 bits installation of the .NET Framework 2.0.

    Thanks,

    Manu

  4. @Emmanuel Stapf

    from http://eiffelsoftware.origo.ethz.ch/index.php/Dr_Watson

    0x10 = only for the .NET Framework version 2.0, the runtime presents the message box described above for processes that are interactive with the desktop. For processes that are not interactive, the runtime spawns the debugger listed in the DbgManagedDebugger registry key.

  5. I received some questions in the mailbag about what Debugger.Launch actually does. Debugger.Launch the…