Depending on my needs and what I am working on, I prefer to use either
Visual Studio, either WinDbg as a debugger.
However, I don't know how to have both cooperate gracefully for
post-mortem debugging (ie, unhandled exception debugger setting in
\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\AeDebug).
Ideally, I would like to extend vsjitdebugger (the Visual Studio
post-mortem debugging "debugger chooser") so that WiDbg appears on the
list of available debuggers. Does anyone know if this can be done, and
how?
Thanks in advance,
Arnaud
MVP - VC
HKLM\SOFTWARE\Microsoft\VisualStudio\Debugger\JIT
looks promising. Probably adding your component there and implementing bunch
of interfaces is all you need.
--
Eugene
http://www.gershnik.com
In his book "Debugging Applications for MS .Net and MS Windows"
(ISBN:0-7356-1536-5) John Robbins provides code to a "Debugger Chooser"
application. He sets the AeDebug key to point to it. At exception time, it
displays a dialog listing available debuggers and then calls CreateProcess()
to launch the chosen one. He mentions two little nits:
1) He had to make sure that handles were inherited by the spawned debugger
in all cases
2) He had to set the value of the AeDebug key to VSJIT.EXE before launching
Visual Studio's debugger
Apparently the VS debugger on startup checks the registry and if it is not
the JIT debugger it may exit prematurely.
Regards,
Will
Yes, it can be done:
Register additional debugger:
vs7jit /registerold "c:\dbgtools\windbg.exe" "WinDbg"
Unregister additional debugger:
vs7jit /unregisterold "c:\dbgtools\windbg.exe"
Quotation marks are required.
Before you register an additional debugger, review and optionally save the contents of
HKLM\Software\Microsoft\Machine Debug Manager\JITDebugging\Engines
(though usually if something goes wrong it is enough to lookup the GUID that describes
the "additional" debugger and delete it).
Note that this approach is a bit limited - Vs7jit does not allow to specify command line
options for additional debuggers (or may be I simply don't know how to do it), and
the debugger is always started with "-p %ld -e %ld" on the command line. For WinDbg,
it means that it will not restart the exception (no -g option), and you will have to:
- switch to the thread that raised the unhandled exception
- do 'kb' to see kernel32!UnhandledExceptionFilter on the call stack
- determine the exception context (passed in a parameter to UnhandledExceptionFilter)
and .cxr to it
Oleg
Arnaud
MVP - VC
It was discussed a couple of times in vsnet.debugging newsgroup, e.g.:
http://groups.google.com/group/microsoft.public.vsnet.debugging/browse_frm/thread/3678c5acc3944055
Oleg