JIT debugging - How to get the managed exception details?

Problem: managed application is crashing on startup with unhandled
exception - need to understand the exception

I've set windbg to be my JIT debugger for managed code
HKLM\Software\Microsoft\.NetFramework\DbgJITDebugL aunchSetting =
(DWORD)2
HKLM\Software\Microsoft\.NetFramework\DbgManagedDe bugger = (string)
c:\DebuggingTools\windbg.exe -p %ld

My test app throws new ApplicationException right from the main

WinDbg does attach to the process and break

So far - so good

Now I expect to be able to understand the exception type and location

!analyze -v is telling that the exception is 80000003 - break
instruction exception
Which is not what I expected - any idea why?

!sos.CurrenExceptionName is telling that: "This is not a managed
exception or not in KERNEL32!RaiseException"

How could I get the details of the ApplicationException?

Loy

When WinDbg have attached via .NET JIT debugging and with
such command line parameters, it will be in the context of the "break" thread,
not in the context of the thread that raised the exception. Therefore
you need to switch to the thread that raised the exception.
If the exception happens at application startup, it usually will be thread 0,
so you should do

to switch to that thread. (Otherwise, print call stacks of all threads to see which
one raised the exception). (Alternatve approach is to add -pv option to WinDbg
command line - it will cause non-invasive attach and thread 0 will usually be
the current one)

After you have switched to the right thread, you can use SOS e.g. to
print the managed call stack (!clrstack, etc.).

If you want to use !currentexceptionname, you need one more step -
lookup the exception context on the thread stack and use .cxr command
to switch to it. There are two most typical approaches to it:
http://blogs.msdn.com/jmstall/archiv...18/355697.aspx
http://www.debuginfo.com/articles/ea...shdumpanalysis
(in the second link, see at the end of the topic)

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

Thanks Oleg - It works!

1. I've added the -pv to the command line
2. Need to load sos.dll before !analyze - in order for analyze to
understand managed exceptions

A problem with .net framework 1.1 is that unhandled exception in thread
other than the main thread does not (always) crash the application

Loy

Oleg Starodumov wrote: