MANAGED DEBUGGING with WINDBG. Breaking on an Exception. Part 1

We can only break on exceptions when doing live debugging, but many of the commands explained here can be used when doing dump analysis, too.

·Exceptions we may get in .NET applications:

§CLR exception(0xe0434f4d).

§Stack Overflow exception (0x800703e9).

§Access Violation (0xc0000005).

§Integer divide-by-zero exception (0xc0000094).

§…

§Fatal Execution EngineError (<address of failure>). This normally indicates a bug in CLR or NT Heap corruption when doing P/Invoke with not big enough buffers. The address associated to this exception will tell us where in the code the issue happened.

The debugger will break by default when the process raises most of these exception types, but not on CLR exceptions, for instance.

In ASP.NET, if exceptions are raised in managed threads and they are unhandled, Global Error Handle catches them. But if they are raised in another thread like Timer or Finalizer threads, we will crash the process(it will be recycled).

·We can break onany CLR exception:

When our code raises a CLR exception, we see the following line in the debugger:

(1728.1f58): CLR exception – code e0434f4d (first chance)

Unmanaged world doesn’t know about specific CLR exception types, so all of them are raised with the same exception code: 0xe0434f4d.

As we’ve seen, WinDbg won’t break on any CLR exception by default, as they may be expected. We can break on all CLR exceptions with any of these commands:

KERNEL32!RaiseException raises the generic CLR exception (0xe0434f4d) to the unmanaged world, but the specific exception we are getting is the one that mscorwks!RaiseTheExceptionInternalOnly raises. We can inspect that specific exception as any other .NET object: