The .dbg (debug) files created with the 32-bit NT toolset are in the Portable Executable (PE) file format. They contain sections with COFF, FPO, and in some cases Codeview information. The Visual C++ integrated debugger can read .dbg files in this format, but it ignores the COFF symbol sections and looks only for Codeview information.
The Visual C++ integrated debugger can also use .dbg files as long as they are made from a binary containing Codeview format debugging output. These are useful for debugging when the source code is not available. Even without the source, .dbg files allow you to set breakpoints on functions, watch variables, and see the functions in the callstack. They are also required for OLE RPC debugging.
Tip When working with symbols from a .dbg file, you must use the fully decorated names. For example, to set a breakpoint on a call to the Windows sndPlaySound function, you would specify _sndPlaySoundA@8 as the location.
The earlier, 16-bit version of the Visual C++ .dbg file format was constrained by the 64K limit for a .com file. The symbolic information was therefore inserted into a separate .dbg file, which had only Codeview information in it. The .dbg files could also be generated by running CVPACK on an .exe file using the /strip option.
For 32-bit .EXEs, Visual C++ reads the format used in the Windows NT .dbg files (supplied for use with its system .dll files). These .dbg files are in the Portable Executable (PE) file format and contain sections with COFF, FPO, and in some cases Codeview symbolic information. The Visual C++ debugger reads .dbg files in this format only. Furthermore, it only uses the Codeview information, ignoring the other symbol sections.
It is possible to strip debug information from a PE file and store it in a .dbg file for use by debuggers. For this to work, the debugger needs to know whether to find the debug information in a separate file or not and whether the information has been stripped from the file or not. One method would be for the debugger to search through the executable file looking for debug information. However, to save the debugger from having to search the file, a file characteristic field (IMAGE_FILE_DEBUG_STRIPPED) indicates that the file has been stripped. Debuggers can look for this field in the PE file header to quickly determine if the debug information is present in the file.
To generate a .dbg file in this format, you can use REBASE.EXE, which is provided with the Win32 SDK. Please see the Win32 SDK documentation for more details.
During the Windows NT retail builds, debug symbols are stripped from the system binaries and drivers and stored in separate .dbg files. This is done because the Windows NT kernel debugger can use these .dbg files and provide debugging symbols even for optimized drivers. Remember, however, that the Visual C++ integrated debugger is not designed to debug protected mode kernel code.
The Windows NT symbol files can be found in a debug subdirectory of the \SUPPORT directory on the Windows NT retail compact disc. These files must be copied from the compact disc to your hard drive. For user mode debugging on the target debugger machine, .dbg symbols must be present in the Windows NT \<winnt>\SYMBOLS directory of the target system (<winnt> is the directory where Windows NT is installed). The Visual C++ setup program installs an "NT System Symbols Setup" icon in your program group. You can use it to automatically copy the .dbg files from your Windows NT compact disc to the correct directory structure on your hard drive.
For kernel debugging, place .dbg files into a symbols tree underneath the directory specified by the _NT_SYMBOL_PATH environment variable (for example, C:\DEBUG\SYMBOLS). Kernel debugging is possible with a minimal set of symbols consisting of symbols for all the drivers (*.sys) in the SYMBOLS\SYS directory, and symbols for NTOSKRNL.EXE and HAL.DLL in the SYMBOLS\EXE and SYMBOLS\DLL directories, respectively.
For more information, refer to the discussion regarding kernel debugging in the Windows NT DDK Programmer's Guide.