Analyze the inner exception using Windbg when “TypeInitializationException was unhandled” exception was thrown

At first time I got this error in my error handling mechanism (Nbug) and was surprised how to get number of line in source code for exception in Windbg. Let’s take a look at a simple console application which throw the exception of this type.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication5
    static class testClass
        // here constructor
        static  testClass()
            throw new Exception("test");


        static public void printInfo()
            System.Diagnostics.Trace.WriteLine("test Info");

    class Program
        static void Main(string[] args)


If we run application in debug mode from Visual Studio it crashes and all information needed for debug is present as shown below


Stack trace of inner exception point to a place of the code where exception was thrown


In my case the stack trace of inner exception is:

at ConsoleApplication5.testClass..cctor() in c:\users\kot\documents\visual studio 2015\Projects\ConsoleApplication5\ConsoleApplication5\Program.cs:line 14


For release mode it also shows us info about place in the code where error was occurred as shown below


And of course our error handling code has to give us info about what happened. But what we can to do if we have unhandled exception in our error reporting mechanism (in my case it was Nbug)?

In this situation we can use user mode dump generated by the system to analyze exception info. By default, dump files are not created. To allow this please take a look at this instruction –

First of all we need to ensure that symbols info is correctly loaded (please google how to configure it in windbg). To check that symbols works correct type in Windbg:

0:000> !sym noisy
noisy mode - symbol prompts on
0:000> .reload /f

Here is 2 important lines we need to see:

DBGENG:  C:\Users\kot\Documents\Visual Studio 2015\Projects\ConsoleApplication5\ConsoleApplication5\bin\Release\ConsoleApplication5.exe – Mapped image memory

DBGHELP: ConsoleApplication5 – private symbols & lines
c:\users\kot\documents\visual studio 2015\Projects\ConsoleApplication5\ConsoleApplication5\obj\Release\ConsoleApplication5.pdb

Where ConsoleApplication5.exe is our bogus application.

Open use mode dump file in Windbg (File / Open crash dump).

Load sos extension (shipped with .NET framework) by command

.loadby sos clr

Type !threads to get available threads in our application. You will see something like this


Where 02fc4800 is address of exception which we use using !PrintException command:

!PrintException /d 02fc4800

You can see something like this


Offsets 0x2 and 0x6 are not very informative about lines of code where exception was occurred. I found here – that I should set “Debug info” to full.  I did that. For Visual Studio 2015 you need to go to Project properties / Build, click on “Advanced” button and select for Debug Info full value as shown below


Closed Windbg and rebuilt solution. Ran our bogus application again so new user mode dump file will was created. Reloaded our user mode dump and repeated actions described above. And it didn’t work again. !clrstack showed source code lines but !Printexception didn’t.

The workaround is described by Brian Rasmussen here – So, here is algorithm with example:

Type !threads command and get address of exception


Get info about exception using !PrintException 34361f6d. Get info about line of code using !U with value of IP register from stack trace. In my case:

!U 015B0456

And below is result


Do the same thing with inner exception.


!PrintException /d 03223158

!U 015B04A8

And here is it!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s