Here are some general steps to help you:
First, you must change the settings of your compiler so that it creates PDB files, even for releases. Later versions of the Visual C ++ compiler do this by default, but in many versions of Visual C ++ you have to do it yourself. Create the program database files, and then save an archive of these files along with each assembly of your application. It is very important that each assembly of your applications has its own set of PDBs. You cannot just reuse the same ones that you did with assembly 10, for example, to examine the dumps generated by assembly 15. You will have a ton of PDB in the life of your project, so be prepared for this.
Then you will need to determine the exact version of your application that generated the dump file. If you create your own MiniDumps (for example, by calling MiniDumpWriteDump () ), perhaps the easiest way to do this is simply to make the filename part of MiniDump the full version number of your application. To do this, you will need a reasonable version numbering scheme. In my store, we increase the number of assemblies on all branches each time a car object creates an assembly.
Now that you have received the dump file from the client, you know the exact version of the application that created the dump, and you have found the PDB files for this assembly.
Now you need to go through the history of version control and find the source code for this exact version of the software. The best way to do this is to apply “tags” to your branches every time you build. Set the tag value to the exact version number, and it is easy to find in the history.
You are almost ready to run WinDbg / Visual C ++:
- Get the complete source tree for this version of your application. Put it in a separate place on your hard drive, say
c:\app_build_1.0.100 for application version 1.0 build # 100. - Get the binaries for this exact version of your application and put them somewhere on your hard drive. The easiest way is to simply install this version of the application to receive binary files.
- Place the PDB files in the same place as the binary files in step 2.
You now have two options for viewing the dump file. You can use Visual Studio or WinDbg. Using Visual Studio is simpler, but WinDbg is much more powerful. In most cases, the functionality in Visual Studio will be sufficient.
To use Visual Studio, all you have to do is open a dump file, for example, a project. After opening the "run" dump file ( F5 by default), and if all the paths are set correctly, you will get the right to the code that crashed, give you a call stack, etc.
To use WinDbg, you need to jump over a couple of hoops:
- Launch WinDbg
- Open the dump file. ( Ctrl + D by default)
- Tell WinDbg to get the correct MicroSoft character files. Enter
.symfix . This may take several minutes, as it will pull a ton of things from the Internet. - Tell WinDbg where the characters are (PDB files). Enter
.sympath+ c:\pdblocation , replacing everything where you put the PDB files for the path name. Make sure you get a plus sign where there are no spaces between the .sympath and the + sign, otherwise you will click step 3. - Tell WinDbg where the source code is. Enter
.srcpath c:\app_build_1.0.100 , replacing the path where you received the code from the source control for this software version. - Tell WinDbg to analyze the dump file. Type
!analyze -v
After a few minutes, if everything is configured correctly, WinDbg will return you to the place of your failure. At the moment, you have a million possibilities for deepening into the space of your application memory, the state of critical sections, windows, etc. But this is beyond the scope of this publication.
Good luck