We’ve all experienced an application crash. But have you ever been in one of those situations where one of your applications crash and there’s nothing in your logs to indicate why? There’s no error message, no stack trace, nothing but a sudden halt of activity in the log file. While this situation can leave even the most experienced operators feeling lost and helpless, with a little bit of sleuthing, you may be able to find the smoking gun Windows tries to preserve for you when you have an application crash. There’s a couple places on the system you should check:
- The Application Event Log
- Windows Error Reporting
The Application Event Log
When an application you support and/or develop mysteriously crashes, the first place you should look is in the computer’s Application Event Log. You can access the Event Viewer MMC by typing “eventvwr” in the Start Menu’s search box or by going to your Administrative Tools menu.
In the Event Viewer MMC, under the “Windows Logs” node, select the Application log and begin searching through the log for the approximate time your application crashed. Hopefully the last log message had a timestamp in it to give you a hint about what time to search for.
If an unhandled exception brought down your application – which is typically the case when an application unexpectedly crashes without logging the reason why – you should see an entry in the Application Event log stating just that. And if it was an unhandled exception in managed code (i.e. .NET), you should even be blessed with a stack trace in the event log entry. Often times this is enough information to piece together the reason for the application crash, or at least to give developers a clue about what situation they may need to handle in terms of additional logging, more graceful error handling, etc.
Windows Error Reporting
Sometimes the Application Event Log isn’t enough. Or if the cause of the application crash occurred in unmanaged code, the message in the Application Event Log might not be very helpful. Don’t despair, there are still a few other places you can check for clues:
- %LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue
- C:\ProgramData\Microsoft\Windows\WER\ReportQueue
- <the application’s working directory>
These locations will depend on the computer’s Windows Error Reporting settings, and depend on the application itself. But many times in the event of an application crash you can find useful nuggets of information in these folders, sometimes even memory crash dumps depending on your settings and the nature of the crash. Of course analyzing a memory dump can be much more involved than reading an exception stack trace, but sometimes these crash dumps can help you and/or your development team quickly hone in on the source of a problem.
For more information on configuring Windows Error Reporting, please see:
So the next time you experience a mysterious application crash and your application’s log file is eerily silent, check these places on the system and you may find the smoking gun.
