It’s an unfortunate and inevitable fact that while developing software sometimes your software will Crash. This also happens, sometimes, hopefully very infrequently, in production code. Each time this happens Windows stores some information about each crash in the Windows Event Log, along with a multitude of other event information it logs.

In this article I’m going to explain two event log entry types which encode crashes, and how to read them. Then I’ll also introduce some tools that take the drudgery out of converting this information into symbol, filename and line number.

The Windows Event Log

The Windows event log can be viewed using Microsoft’s Event Viewer. Just type “Event Viewer” in the start menu search box and press return. That should start it. Crash information is stored in the sub category “Application” under “Windows Logs”. The two event sources that describe crashes are Windows Error Reporting and Application Error.

The image above shows a Windows Error Reporting event has been selected. The human readable form is shown below in the General tab. Although I say human readable, it really is unintelligible gibberish. None of the fields are identified and you have nothing to work with. The details tab isn’t any better – the raw data is present in text or XML form. Here’s the XML for the crash shown above.

1001400x80000000000000260507Applicationhydra20237877290865679411APPCRASHNot available0testDeliberateCrash.exe1.0.0.15e419525testDeliberateCrash.exe1.0.0.15e419525c0000005000017b2C:\Users\stephen\AppData\Local\Temp\WERC24C.tmp.WERInternalMetadata.xmlC:\Users\stephen\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_testDeliberateCr_c31b903842d94a84d4621dceaac377462674f7a_eb589596_139ec4bd0c3d360b2-4d7f-11ea-83d3-001e4fdb3956054756af49aec84f97c15f03794ffd605

There’s quite a bit of data in here, the purpose of each field implied, not stated. Towards the end is some information related to minidumps, but if you go searching for it, the minidump will no longer be present.

The format for Application Error crashes is different.

Windows Error Reporting

The event log data for a Windows Error Reporting event contains many fields that we don’t need if we’re just investigating a crash address. Each event starts with an tag and ends with an tag.

We need to correctly identify the event. Inside the event is a tag which contains a tag with an attribute “Provider Name” set to “Windows Error Reporting”.

Once the event is identified we need to find the tag inside the event. The contains 14 tags. These tags are present:

• 1. Timestamp.


• 2. Unknown.


• 3. Information. This will typically be APPCRASH.


• 4. Information Status.


• 5. Unknown.


• 6. Crashing executable.


• 7. Executable version.


• 8. Executable timestamp.


• 9. Crashing DLL. This will be the same as 6 if the crash is in the .exe.


• 10. DLL version. This will be the same as 7 if the crash is in the .exe.


• 11. DLL timestamp. This will be the same as 8 if the crash is in the .exe.


• 12. Exception code.


• 13. Fault offset.


• 14. Class. This may or may not be present



Of these tags we’re interested in tags 9, 12 and 13.

If we want to version the crashing DLL we also need tags 10 and 11.

Application Error

The event log data for an Application Error event contains many fields that we don’t need if we’re just investigating a crash address. Each event starts with an tag and ends with an tag.

We need to correctly identify the event. Inside the event is a tag which contains a tag with an attribute “Provider Name” set to “Application Error”.

Once the event is identified we need to find the tag inside the event. The contains at least 12 tags, some of which may not be present, or which may be empty. These tags are present:



• 1. Crashing executable.


• 2. Executable version.


• 3. Executable timestamp.


• 4. Crashing DLL. This will be the same as 1 if the crash is in the .exe.


• 5. DLL version. This will be the same as 2 if the crash is in the .exe.


• 6. DLL timestamp. This will be the same as 3 if the crash is in the .exe.


• 7. Exception code.


• 8. Fault offset.


• 9. Process id.


• 10. Application start timestamp.


• 11. Application path.


• 12. Module path.



Of these tags we’re interested in tags 7, 8 and 12.

If we want to version the crashing DLL we also need tags 5 and 6. If 12 isn’t available, use 4.

Removing the drudgery

The previous two sections have described which fields to extract data from. If you’re doing this manually this is tedious and error prone. You have to select the correct values from the correct fields and then use another application to turn them into a symbol, filename and line number. Our tools DbgHelpBrowser and MapFileBrowser are designed to take a crash offset inside a DLL and turn it into a human readable symbol, filename and line number. But that still requires you to do the hard work of fishing the correct data out of the XML dump.

Now there is a better way, we’ve added an extra option to these tools that allows you to paste the entire XML data from a crash event and the tool then extracts the data it needs to show you the symbol, filename and line number.

DbgHelpBrowser

Load the crashing exe (or DLL) into DbgHelpBrowser. This will cause the symbols to be loaded for the DLL (assuming symbols have been created and can be found). We’re not covering versioning the DLL as most likely you will have your own methods for this.

Choose the option Find Symbol from Event Viewer XML crash log… on the Query menu. The Event Viewer Crash Data dialog is displayed.




Paste the XML data into the dialog and click OK.




The main display will select the appropriate symbol in the main grid and display the relevant symbol, filename, line number and source code in the source code viewer below.




MapFileBrowser

Load the MAP file for the crashing exe (or DLL) into MapFileBrowser. We’re not covering versioning the DLL as most likely you will have your own methods for this.

Choose the option Find Symbol from Event Viewer XML crash log… on the Query menu. The Event Viewer Crash Data dialog is displayed.




Paste the XML data into the dialog and click OK.




The main display will select the appropriate symbol in the main grid and display the relevant symbol, filename, line number and source code in the source code viewer below.




Conclusion

Windows Event Logs can be hard to read and error prone to use. However when paired with suitable tools you can quickly and easily turn event log crashes into useful symbol, filename and line number information to inform your debugging efforts.