Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Extending vsjitdebugger

256 views
Skip to first unread message

adeb...@club-internet.fr

unread,
Oct 27, 2005, 11:17:38 AM10/27/05
to
Hello group,

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

Eugene Gershnik

unread,
Oct 27, 2005, 7:08:12 PM10/27/05
to


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


William DePalo [MVP VC++]

unread,
Oct 27, 2005, 8:22:44 PM10/27/05
to
<adeb...@club-internet.fr> wrote in message
news:1130426258.8...@z14g2000cwz.googlegroups.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


Oleg Starodumov

unread,
Oct 28, 2005, 5:02:21 AM10/28/05
to

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


adeb...@club-internet.fr

unread,
Oct 28, 2005, 8:24:22 AM10/28/05
to

Oleg Starodumov wrote:
> > 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?
> >
>
> Yes, it can be done:
>
> Register additional debugger:
> vs7jit /registerold "c:\dbgtools\windbg.exe" "WinDbg"
>
> Unregister additional debugger:
> vs7jit /unregisterold "c:\dbgtools\windbg.exe"

Thanks!
How have you find this?

Arnaud
MVP - VC

Oleg Starodumov

unread,
Oct 28, 2005, 9:01:17 AM10/28/05
to

> How have you find this?
>

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


0 new messages