Debugging .NET based Windows Error Reports (WER)

The last hope: Windows Error Reports

The “Windows Error Report” (WER) is automatically generated by Windows and can be seen in the Eventlog. In most cases, you might see some other - debugging friendlier - event logs. If there is a event log from with the source “.NET Runtime”, then use this first. Windows Error Reports are at first a bit strange to read.

Small, but important hint: I strongly recommend that you should use some logging libraries inside your application as well.

If you still don’t have a clue where your application breaks or those other event logs are missing the WER can be used to see where the exception is thrown in your .NET application.

Windows Error Report for .NET Apps

A typical Windows Error Report could look like this:

Fault bucket 129047406839, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0

Problem signature:
P1: BreakStuff.App.exe
P2: 1.0.0.0
P3: 56eb2416
P4: BreakStuff.App
P5: 1.0.0.0
P6: 56eb2416
P7: 5
P8: a
P9: FatalError
P10: 

Attached files:
C:\Users\Robert\AppData\Local\Temp\WERE708.tmp.WERInternalMetadata.xml
C:\Users\Robert\AppData\Local\Temp\WERF4B5.tmp.appcompat.txt
C:\ProgramData\Microsoft\Windows\WER\Temp\WERF4D5.tmp.dmp
C:\Users\Robert\AppData\Local\Temp\WERF65D.tmp.WERDataCollectionFailure.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_BreakStuff.App.e_1952fbbdf8ecceaa6e9af5c44339210849f4774_b2bbc455_cab_7634f669\memory.hdmp
WERGenerationLog.txt

Each P holds some exception location information:

P1: “BreakStuff.App.exe” = App name or host process e.g. your.exe or Outlook.exe for a .NET addin.

P2: “1.0.0.0” = Version of the executabe

P3: “56eb2416” = Timestamp of the executable

P4: “BreakStuff.App” = Faulting assembly and module name

P5: “1.0.0.0” = Version of the faulting module

P6: “56eb2416” = Timestamp of the faulting module

P7: “5” = MethodDef – MethodDef token for the faulting method, after stripping off the high byte. This is the faulting method in your code. Super important!

P8: “a” = IL offset - in hex, in combination with P7 will it show you the exact position of the exception in your method.

P9: “FatalError” = Exception type

P1-P3 should be easy to understand and nothing new to you. If you have a bigger application P4 might lead to the correct namespace/assembly.

Most important to find the real source is P7 & P8 - I will show you how to read it.

P7: Finding the MethodDef token with ILDASM.exe

P7 tells you in which method the exception occurred. The number shown in P7 is the method token, which is the IL representation of your actual method in code. To see the real method name we need a tool.

As far as I know you could try to use WinDbg, but I was too stupid to use it correctly - ildasm.exe does also work for our use case. To get the method token you need “ildasm.exe”, which is included in the .NET SDK, which is part of the Windows SDK.

On a Windows 10 machine, with the SDK installed, you can use this version:

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ildasm.exe

For ILDASM it is not important if the actual .NET app is using .NET 4.6 or any other version.

“ildasm.exe” itself is not a beauty, but works. Now open your assembly from P4 with this tool.

To see the tokens, press CTRL + M and search for P7.

In my case I see this:

Method #2 (06000005) 
-------------------------------------------------------
	MethodName: ButtonBase_OnClick (06000005)
	Flags     : [Private] [HideBySig] [ReuseSlot]  (00000081)
	RVA       : 0x0000208c
	ImplFlags : [IL] [Managed]  (00000000)
	CallCnvntn: [DEFAULT]
	hasThis 
	ReturnType: Void
	2 Arguments
		Argument #1:  Object
		Argument #2:  Class System.Windows.RoutedEventArgs
	2 Parameters
		(1) ParamToken : (08000001) Name : sender flags: [none] (00000000)
		(2) ParamToken : (08000002) Name : e flags: [none] (00000000)

Take a look at the method description: 0600000 5 - the 0600000 is the high byte (whatever that means… - just search for the number, I bet you will find something.)

BigBasti helped me in the comments to describe the high byte: Big numbers which need more than one byte to store the value have high bytes (most significant bytes) and low bytes (least significant bytes) - you need to know this to make sure you load the sequence of bytes in the correct order. - Thanks!

Ok - now we know the actual method. The exception occurs in the ButtonBase_OnClick method!

P8: Finding the exact position of the faulting code with ILSpy

Now we need to look at the methods IL. You can use ILSpy or any other .NET decompiler (ildasm is not very comfortable, we only used it to get the method name). If you choosed ILSpy make sure you switch from the C# view to IL view and go to the faulting method:

// Method begins at RVA 0x208c
// Code size 11 (0xb)
.maxstack 8

IL_0000: ldstr "I'm dead!"
IL_0005: call void [mscorlib]System.Environment::FailFast(string)
IL_000a: ret
} // end of method MainWindow::ButtonBase_OnClick

As you might remember - P8 pointed to “a”, which is the IL_000a instruction.

Mission accomplished: Exception source found! Yay!

Big picture

I never thought I had to read the internal IL, but we had one weird case where no log files were generated and we used this trick to get to the source of the exception.

My breaking Sample Code on GitHub

Hope this helps!