The information in this article applies to:
SUMMARYThe Windows NT debug symbols must be verified after starting the kernel debugger (I386kd.exe | Windbg.exe). The debugger may load and present a prompt, but if the symbols are incorrect, future debugging commands do not reference proper functions and variables, which leads to sporadic results. Listed below are a few red flags and a couple of methods to spot check validity of the symbols. MORE INFORMATIONThis article assumes that the kernel debugger is running and has loaded a Memory.dmp file or is connected to a remote machine. Commands presented are not fully documented and only excerpts from the output are shown. Article Contents
Loading the Kernel DebuggerA normal load of the kernel debugger displays one of the following prompts:kd> Uniprocessor SystemThe prompt shown below indicates that the symbol file for the Ntoskrnl.exe file is incorrect. Check to make sure that the appropriate multiprocessor or uniprocessor kernel and HAL are copied into the symbol tree. Example:
When the kernel debugger loads the Memory.dmp file, the Kernel Version
as well as the Processor Count is displayed in the first few lines. Confirm
that the processor count corresponds with the appropriate kernel and HAL.
Driver symbol information is displayed as either the symbols are loaded or
deferred.
Sample Load:
Note that the kernel debugger was "Unable to read image header for
Floppy.sys at fc820000 - status c0000001." This message is normal because
the particular driver header is not currently in memory.
Checking Creation Time with !driversUse the !drivers command to list the drivers currently loaded in memory. Make note of the dates and times of the drivers and whether or not they could be loaded. (The Code Size and Data Size columns in the following example are removed to fit the width of the article.)
Note the Creation Time of the file, which is the date the file is
compiled. This date is close to the Date\Time Stamp on the actual
file when viewing the Winnt\System32\Drivers subfolder using File
Manager.
If you subscribe to the Microsoft Developers Network (MSDN) or have the Windows NT Device Driver Kit (DDK), the Link.exe tool can be used to confirm that the Dbg file is the same file that was created when the driver was compiled. The "time date stamp" in the example below matches the "Create Time" of Netbios.sys in the output above. Use Link.exe to check the "time date stamp" of the Dbg file: LINK -dump -headers \symbols\sys\netbios.dbgMicrosoft (R) COFF Binary File Dumper Version 3.00.5270 Copyright (C) Microsoft Corp 1992-1995. All rights reserved. Dump of file Netbios.dbg 4944 signature2FAAE94F time date stamp Fri May 05 23:13:19 1995 8D0B checksum of image** Contents Deleted ** If the !drivers command produces any lines that look like the following, an important table in the dump is corrupt. Further analysis of the dump may not be possible.
Unassembling a FunctionThe symbol files enable the kernel debugger to reference functions and global variables by name. Spot check a couple of unassembled functions to make sure they look proper. Many functions are compiler optimized and do not necessarily conform to the examples below. Compiler optimized functions are identified by the FPO in parenthesis in the function name.Functions normally begin with either "push ebp" or "mov eax, fs[000000000]." Basic knowledge of machine language and experience will enable one to recognize these functions.
Good Symbols
The unassembly of the function should look similar to the text above;
however, the unassembly is subject to change. If the unassembly looks
proper, you can assume that the symbols have loaded properly for this
module.
The following unassembly begins with "jnz NT!_NTUnlockFile+0x22." Obviously, the beginning of a function would not start with a jump instruction code. Check the symbol tree once again. Bad Symbols
Service Pack SymbolsThere are times when it is difficult to match the symbols with a particular installation. At some point in time, a service could have been added that required copying files from the Windows NT Installation CD-ROM, which copied over files that were updated with a service pack. Be sure to reapply the service pack and any third-party support disks after changing system setup, which copies files from the Windows NT Installation CD-ROM. The symbols should be applied in the same order as the installation.ADDITIONAL INFORMATIONThe Kernel Debug How To series of the article can be found by searching on the keyword: debugref.Additional query words: prodnt debugref ntblue
Keywords : kbNTOS350 kbNTOS351 kbWinOS2000 kbDSupport |
Last Reviewed: January 21, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |