Re: JIT debugging - How to get the managed exception details?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance




!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?


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

~0 s

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/archive/2005/01/18/355697.aspx
http://www.debuginfo.com/articles/easywindbg2.html#crashdumpanalysis
(in the second link, see at the end of the topic)

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







.



Relevant Pages

  • Re: proposal: reswitch
    ... in a few TCL scripts (and end up using a variable kludge to ... > I personally don't care about a loop-ability of switch. ... But reserving a new exception code ... too hard to fit that stuff into my new idea for optimisation". ...
    (comp.lang.tcl)
  • Re: test if a string is a valid number?
    ... Generally, you watch for the use of switch to decode and realize that in most cases, ... virtual methods and subclasses are a better solution. ... you use virtual methods, you only have to change the definition site. ... exception type so I could issue a meaningful error message. ...
    (microsoft.public.vc.mfc)
  • Re: x86 exception handling and stack demand
    ... that allocates stack frames from a heap. ... to a big conventional stack in those few cases where the modest allocation ... and have running exception handlers for the language. ... In these cases, the entire state is stored in a CONTEXT structure, which is passed to all the exception handlers, all of which may change it at will. ...
    (microsoft.public.win32.programmer.kernel)
  • malloc() causes an Access Violation when compiling with the /MT switch
    ... Multithreaded Debug CRT) but as soon as I change it to the /MT switch ... causes an Access Violation exception ... The first few calls to mallocare allocating very small memory blocks, ...
    (microsoft.public.dotnet.languages.vc)
  • malloc() causes an Access Violation when compiling with the /MT switch
    ... Multithreaded Debug CRT) but as soon as I change it to the /MT switch ... causes an Access Violation exception ... The first few calls to mallocare allocating very small memory blocks, ...
    (microsoft.public.vc.language)