14

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
palm snow
  • 2,392
  • 4
  • 29
  • 49

2 Answers2

19

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.

Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
  • 3
    Stated 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
6

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Naveen
  • 4,092
  • 29
  • 31