I've been noticing that on my server quite frequently I get managed exceptions bubbling up to the Dr. Watson and/or the Visual Studio Just In Time Debugging dialog on the desktop. Now this being a server machine I'm not happy about this happening of course because it clutters the desktop the next time I actually log on to the server with Remote Desktop and am greeted with 20 of these dialogs littered over the desktop as well as taking valuable memory on this already overloaded server.

What's strange about this is that these are managed exceptions which apparently are coming from the system, rather than from any of my ASO.NET applications.

The dialog comes in two flavors - the above shows when the Just-in Time debugging feature in Visual Studio is turned off in Tools | Options | Debugging | Just-in Time Debugging.:

Anyway, why should this dialog be anything of note? Well, if you've ever had an error in your ASP.NET applications you probably know what errors that aren't handled look like, right? You get a yellow screen of death which is displayed in the browser. Now we all have error handlers in our applications so this should never happen either, right? <s> All of my applications have an Application_Error handler with a generic routine to capture any non-handled exceptions, log them, send email confirmations so I'm generally aware of failures occurring on the site. That's all as it should be for my application (as far as I can tell at least).

But my point is this: any application ASP.NET errors typically don't throw up  Just In Time Debugging dialogs. They manifest immediately and are echo'd back into the HTTP stream with some sort response. So what is throwing up these exceptions?

Notice the System.ArgumentException which is clearly an error coming from the .NET runtime. Unfortunately these errors usually occur when no one's watching so it's hard to see where they are actually coming from and debugging into them is not an option because typically by the time I find them the process has long terminated. I've had no luck trying to trace these errors down further - there appears to be nothing in the event log to the effect of these errors.

I have a few other .NET applications running on the server such as West Wind Web Monitor which runs as a service, but a failure like this would presumably crash the service and that's not the case. Not in W3wp.exe anyway.

So question is - what the heck is throwing up these errors and why isn't there a little more information available? I can find nothing in the event log, or elsewhere and I would think that any error in my own code would be handled by the Application_Error handler. As would any plain .NET request processing, so that seems to point at something much lower level...

Any ideas on where to find info on these crashes? Anybody else seen this and any idea on what could be causing these?

Turning off the Dialog

Ideally I don't really need to know about these errors that apparently are coming from ASP.NET internally. They are very rare but they do leave a mess on the desktop if I don't check the machine for a month or so. They also leave a rundll process behind which although small is using up resources on this already low powered machine.

Apparently you can turn off the settings. After some searching around once again Scott Hanselman found the answer long ago:

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.

I've set the value to 1 now and I haven't seen the dialog pop up in the last week or so, which I think took care of the issue, but I'll have to wait a little longer to see.