The Windows Scenario That You May Run into with Your Applications

Windows 2000 and its service packs are built with the VC 5 compiler and linker. Windows XP is built with the VC 7 compiler and linker. However, because VC 7 did not ship before Windows XP, the 32-bit builds of Windows XP used a VC 7 compiler switch (in this case, /Zvc6) and linker option (in this case, /debugtype:vc6) to create PDB files that have the VC 6 format.

For Windows 2000 and its service packs, the VC 5 linker also left some additional debugging information in the image. The Windows build process strips this data out of the image and saves it in a separate file with a .DBG extension. This considerably reduces the file size, which decreases file load times and thus increases system performance.

The VC 6 and VC 7 linker puts all of the debugging information into the PDB file, thus eliminating the need to create a DBG file.

Windows 2000 binaries each have two symbol files: a .DBG and a .PDB file. Binaries for Windows XP and beyond only have a .PDB file since all of the information is inclusive.

You may want or need to follow the same symbol process that Windows used in order to make sure all of the symbols of your different version applications match.

As John Robbins points out in his book, you should "build all builds, including release builds, with full debugging symbols." Another important point he makes is that Q/A or test must use debug and release builds for testing. He proposes that the test team alternates between debug and release builds, depending where you are in your shipping cycle. After the release candidate (RC) milestone, he notes, you should be testing release builds exclusively.

The best way to get everyone in your company to use the correct symbols is to centralize all of the symbols using a symbol server or symbol store. It is so valuable that Microsoft keeps a live symbol server for Windows and other products at this site: http://msdl.microsoft.com/download/symbols. You may want to consider doing this for your customers. Again, check this site for details on how to access Microsoft's symbol server or set one up for yourself: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx.

This appendix does not even scratch the surface of the symbol/ debugging iceberg, but I hope you will see the relevance to the build team and now have the references to help you research the topic further.