Figuring out exactly why an application has crashed can be tricky.  Especially if you don’t see any useful error messages.  And while Windows 7 does its best, the most you’re likely to see – much, much later – is a message suggesting that you upgrade to a new version.

Prolific freeware developer Nir Sofer has just released a new tool which can help, however, in WinCrashView. And although it’s targeted at developers and other expert users, anyone may be able to gain some useful crash troubleshooting clues from the data this program has to offer.

Launch WinCrashView and you should immediately see a list of your recent 32-bit application crashes in the upper pane. (It’s empty?  Click Options > Show Internal Exceptions. Or, if you use disk cleaning tools, keep in mind that these may delete the crash files, so the program will have nothing to analyse; stop running your disk cleaner for a while, just until you’ve had a chance to examine the files in more detail.)

Select a crash relating to the application you’re worried about, click View > HTML Report, and you’ll see the core information: the crash time and date, application name and version, and so on. The most interesting option here will probably be the exception code and description.  Enter these (separately) at Google, along with your application name, to look for similar crash reports.

The next section, “strings in the stack”, will offer clues as to what your processes were doing when the crash occurred. Some of the strings will be meaningless, but others may list file names, web URLs, email addresses and more. Think about how these might relate to what you were doing when the program crashed.  If, say, there’s a network file name on the stack, then could your application have problems accessing network shares?

Next up you’ll find a couple of attempts to identify the call stack, essentially a list of the DLLs and other executables which were involved in what was going on at crash time. And you also get the CPU registers, perhaps with pointers to functions which were running when the application crashed; a module displaying the DLLs that were loaded at the time; a section which details all your running threads and what they were doing; and there’s even more stack data to finish.

If you’re a PC novice, then, WinCrashView can at least make it easy to find out the basic details about recent crashes. More experienced users might be able to identify possible causes from the stack data.  But the program works best for anyone who regularly has to troubleshoot crashes on other people’s PCs.

In particular, there’s no need to try and remember what crash data is available for the version of Windows you’re using, or how to to find it; just run WinCrashReport from a USB flash drive and it’ll deliver the same detailed report on every edition of Windows from 2000 upwards.  The only significant issue right now is that while the program can run on 64-bit Windows, it can only analyse the crashes of 32-bit apps. The author says this may change in future, though, and Nir Sofer is so very prolific that we probably won’t be kept waiting for too long.