Scott Hanselman

How to turn off/disable the .NET JIT Debugging Dialog

August 24, '04 Comments [1] Posted in Bugs | Tools
Sponsored By

A day may come when you want to turn off the Debug dialog that appears when a .NET program has an unhandled exception.

Option 1: Registry key from Enabling JIT Debugging

For an application that includes managed code, the common language runtime will present a similar dialog to JIT-attach a debugger. The registry key that controls this option is called HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting.

  • If value = 0, prompt the user by means of a message box. The choices are:
    • Continue. This results in a stack dump and process termination.
    • Attach a debugger. In this case, the runtime spawns the debugger listed in the DbgManagedDebugger registry key. If none, control is returned, and the process is terminated.
  • If value = 1, simply return control. This results in a stack dump, after which the process is terminated.  (No more dialog)
  • If value = 2, spawn the debugger listed in the DbgManagedDebugger registry key.

Option 2: If you want to disable the JIT debug dialog, but still want an error dialog:

Visual Studio.NET|Tools|Options|Debugging|Just-In-Time and deselect "Common Language Runtime" and now you’ll get an OK/Cancel dialog instead of the select a Debugger Dialog.  Note: The registry entry from Option 1 above will need to be 0 for the dialog to show up.

Thanks to Eric Deslauriers of Corillian QA for these tips!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Thursday, October 21, 2004 11:36:05 AM UTC
I'm not sure that your option 2 is correct. Toggling the "Common Language Runtime" JIT debugging switch *sets* the aforementioned registry key value to 0 or 2, but it doesn't seem to replace that ugly JIT-debug dialog.

Unless I'm missing something, of course. Which is quite possible - I'm usually fighting the plumbing rather than being at one with it.

PS I owe you an apology about suggesting that INI file trick when debugging an ASP.NET app. I conveniently overlooked the fact that this trick doesn't work when the CLR is hosted by another process such as the ASP.NET worker process. Sorry!
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.