WinDbg and .NET - how to make it a default debugger

Maciej Tokarski

unread,

Jan 25, 2006, 10:53:34 AM1/25/06

to

Hello!

In the "old" unmanaged world you could setup WinDbg as a default debugger
with "WinDbg -I". WinDbg would be called and automatically attached to the
faulting process.
You could make a use of command line options of WinDbg and modify AeDebug
registry entry so to create dumpfiles automatically.
It wasn't necessary to start the application from WinDbg - so the solution
was somewhat transparent, and didn't involve any user's interaction.

In the managed world it doesn't work any more, but I still need reliable
WinDbg dumps, which I could analyze "postmortem" with sos extension.

Is it at all possible to set up .NET framework so that the windbg is brought
up instead of the dialog "An unhandled exception has occured in your
application... [Details],[Continue],[Quit]" for the RELEASE build?

Regards!
Macko

Oleg Starodumov

unread,

Jan 26, 2006, 4:32:53 AM1/26/06

to

> Is it at all possible to set up .NET framework so that the windbg is brought
> up instead of the dialog "An unhandled exception has occured in your
> application... [Details],[Continue],[Quit]" for the RELEASE build?
>

Yes, almost possible - at the application's startup, call SetUnhandledExceptionFilter(0)
via PInvoke (note that 0 is passed as the parameter (actually, IntPtr.Zero)).
It allows to debug the application with the unmanaged JIT debugger (which can
be WinDbg) when an unhandled exception is raised.

If the application uses WinForms, you should also add the following to the application's
configuration file:

"Almost possible" is because in some cases WinForms will still catch the exception
and show the dialog with error report (and thus will not allow to do normal
JIT debugging).

Also note that calling SetUnhandledExceptionFilter(0) will affect live managed debugging
(managed second chance exceptions will not be delivered to the managed debugger
if it is attached, so it makes sense to call SUEF only if there is no managed debugger
already attached).

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

Maciej Tokarski

unread,

Jan 26, 2006, 8:06:31 AM1/26/06

to

Hi,
thanks for the reply.
I found another solution, not sure yet whether it will do; it's been working
fine when throwing a test System.ApplicationException manually, now I'll
wait till the real exception is thrown.

I've put following items into the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"DbgManagedDebugger"="\"C:\\WinDbg\\windbg.exe\" -p %ld -e %ld -g"
"DbgJITDebugLaunchSetting"=dword:00000002

and added

<system.windows.forms jitDebugging="true" />

to the application.exe.config file.

We'll see. Do you think it should work or am I just dreaming away?
Regards!
Macko

Oleg Starodumov

unread,

Jan 26, 2006, 10:32:43 AM1/26/06

to

I think this approach should work too, if we simplify the command a bit:

DbgManagedDebugger="c:\windbg\windbg.exe -p %ld"

AFAIK, -e option should not be used, because the second parameter passed
by CLR to the JIT debugger is not an event handle but an appdomain id
(at least in CLR 1.x, I haven't checked how it works in 2.0).

(In general, I am usually trying to avoid CLR JIT debugging because of its dependency
on the value of DbgJITDebugLaunchSetting, which conflicts between applications
that want to use an external JIT debugger and others that rely on
AppDomain.UnhandledException event; but on your own machines you are always
in control, anyway).

Oleg