It has been a while since I did any significant development for the Windows platform, either using the Win32 API or any of the tools. Once upon a time (about six years ago) I used to port utilities from HP-UX to Windows, and write Windows installers. These days, whenever I have to look at any Windows code, I tend to gingerly prod at it using Bloodshed Dev C++, or the SharpDevelop IDE.
Recently I was trying to work out why the Mugshot client was crashing, and needed to look at the debugging tools available. Disclaimer – I’m no expert here, this post just represents “some stuff I’ve learned lately”.
When an application crashes on Windows XP, sometimes you get an error along the lines of “there was a problem with xxx and it needs to close”. Something like this:
If you click for more information, you can then get more technical details:
Unfortunately, you can’t cut-and-paste the contents of the details window into a text file.
When the error dialog is on the screen – before you close it – if you look in C:\Documents and Settings\<your user>\Local Settings\Temp you should find two files – a xxxx_appcompat.txt file (which will be named in the Error Report Contents window… 9982_appcompat.txt in the example above), and a yyyyyyy.dmp file. I don’t know what the pattern is for naming these – the numbers seem to differ, and I can’t see that they have any relation to e.g. the PID, so I assume they are random. The two files seem to get deleted when you close the dialog, so if you want to try to get more debug information, copy and paste them somewhere else.
The appcompat file contains some information about the libraries that were loaded to support the running process. The .dmp file seems to be similar to a core file on UNIX – a dump of the process.
There are several ways to look at the dump file:
- dumpchk: this is available by default in Windows XP. If you run dumpchk <dmp-file>, it will print out some more information about the loaded modules and threads. Basic, but may be useful.
- windbg: this is available as part of the free Debugging Tools for Windows package from Microsoft. It is a graphical tool that you can use to open the .dmp file. If there is any useful information in the dump, you can enter .excr in the debugger and it will take you to the exception; !analyze -show will show you the error; and lm will list out the loaded modules.
- kd: this is the command-line equivalent of windbg. Run it with -z <dmp-file> to get into the debugger.
That’s a really brief summary. Check out the MS Knowledge Base article on debugging for more details.
Oooh Bloodshed DevC++, that rings a bell…
Sam’s little brother has aspirations of being a games programmer, so I did a quick Google a while back for free C/C++ IDEs and DevC++ looked the best, so I sent it to him.
I assume the fact that you’ve used it means my random choice was a decent one?!
It works – I like it. You can download the Microsoft “Express” versions of Visual Studio, too. The MS compilers are actually free as well, but that doesn’t help with the IDE side of things. I’ve been using Bloodshed DevC++ since I got cut off from my source of commercial MS IDEs (i.e. since I left my previous organisation), and it does the job nicely.
As a program developer, I do find the tool can generate too many false negatives. With a recent development, we discussed there was a problem with Manifest file although Microsoft debugging tool suggested it was something else