Whenever my application throws an unhandled exception, I would like WinDbg to catch that exception on my debugging machine rather than Dr. Watson, etc. How can this be configured?
2 Answers
Run windbg -I
to install it at the default post mortem debugger.
As Kurt points out below WinDbg comes in both 32 and 64 bit versions. Executing windbg -I
sets up the post mortem debugger for the processes corresponding to the bitness of the debugger.
You can install both versions of WinDbg side-by-side if you need to have both the 32 and 64 bit versions available.
From the help file:
-I[S]
Installs WinDbg as the postmortem debugger. For details, see Enabling Postmortem Debugging. After this action is attempted, a success or failure message is displayed. If S is included, this procedure is done silently if it is successful; only failure messages are displayed. The -I parameter must not be used with any other parameters. This command will not actually start WinDbg, although a WinDbg window may appear for a moment.

- 114,645
- 34
- 221
- 317
-
3Stated that registration was successful, yet starting the crashing process again still results in the Visual Studio Just-In-Time windows showing up with only Visual Studio debuggers available. :( Oh well. – SilverbackNet Jun 12 '13 at 21:40
-
2@SilverbackNet: Windbg comes in 32-bit and 64-bit flavors. If you run the 32-bit version with the `-I` parameter, it sets itself as the default debugger for 32-bit processes. If you run the 64-bit version, it sets itself as the default debugger for 64-bit processes. So if you're still seeing the Visual Studio debugger selection window, it may be that you haven't run the right bitness flavor of windbg with `-I`. See [this MSDN article](https://msdn.microsoft.com/en-us/library/windows/hardware/ff542967). – Kurt Hutchinson Oct 15 '15 at 04:03
-
And I remember some recent post in [windbg] that clarified which bitness overrides which one (but not vice versa). – Thomas Weller Oct 19 '15 at 08:38
-
One question here is when we configure Windbg as postmortem for service, windgb opens in session 0, which is hard to debug or create dump – user3664223 May 24 '22 at 18:17
Here is a registry file for setting WinDbg as the managed debugger and native debugger:
Windows Registry Editor Version 5.00
;This reg file installs just-in-time debuggers to capture a dump of all process
;crashes for the machine.
;
;Assumes 32-bit debugger is cdb.exe and is installed to C:\debuggers\x86\.
;Assumes 64-bit debugger is cdb.exe and is installed to C:\debuggers\x64\.
;
;Assumes crash dumps can be written to C:\crash_dumps\.
;Make sure all users have write access to this directory.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"DbgManagedDebugger"="\"c:\\debuggers\\x64\\windbg.exe\" -pv -p %ld "
"DbgJITDebugLaunchSetting"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"="\"c:\\debuggers\\x64\\windbg.exe\" -pv -p %ld "
"Auto"="1"
;The following keys are only used on 64-bit versions of Windows (note Wow6432Node).
;They can be safely created with no side-effects on 32-bit versions of Windows.
;Alternatively, you can delete the remainder of this file if you’re running a
;32-bit version of Windows.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"="\"c:\\debuggers\\x86\\windbg.exe\" -pv -p %ld "
"Auto"="1"
Automatically Capturing a Dump When a Process Crashes is a writeup about this from the CLR team.

- 30,738
- 21
- 105
- 131

- 4,092
- 29
- 31