Microsoft KB Archive/148660

= How to Verify Windows Debug Symbols =

Article ID: 148660

Article Last Modified on 2/22/2007

-

APPLIES TO


 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Professional Edition
 * Microsoft Windows 2000 Datacenter Server
 * Microsoft Windows NT Workstation 3.5
 * Microsoft Windows NT Workstation 3.51
 * Microsoft Windows NT Server 3.5
 * Microsoft Windows NT Server 3.51

-



This article was previously published under Q148660





SUMMARY
The Windows 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 INFORMATION
This 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 Debugger
 * Checking Creation Time with !drivers
 * Using Link.exe to Check Creation Time
 * Unassembling a Function
 * Service Pack Symbols

Loading the Kernel Debugger
A normal load of the kernel debugger displays one of the following prompts:

kd> Uniprocessor System

0: kd> Multiprocessor System

The 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: Symbol search path is: C:\symbols kd: crash dump initialized [c:\dump\memory.dmp] could not determine the current processor, using zero Kernel Version 1057 Free loaded @ 0x80100000 Bugcheck 0000001e : c0000005 80151d5b 00000000 00000001 16kd> 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.
 * Contents Deleted ***

Sample Load: Symbol search path is: C:\symbols kd: crash dump initialized [c:\dump\memory.dmp] Kernel Version 1057 Free loaded @ 0x80100000 Bugcheck 0000001e : c0000005 80151d5b 00000000 00000001 re-loading all kernel symbols KD: unloading symbols for "ntoskrnl.exe" KD: deferring symbol load for "ntoskrnl.exe" at 80100000 KD: Loaded (2248) fpo entries for image (ntoskrnl.exe) KD: "ntoskrnl.exe" loaded 4074 symbols (80100000-801bbb80) KD: loaded symbols for "ntoskrnl.exe" KD: deferring symbol load for "atapi.sys" at fc810000 KD: deferring symbol load for "diskdump.sys" at fc800000 KD: deferring symbol load for "hal.dll" at 80400000 KD: deferring symbol load for "atapi.sys" at 80010000 KD: deferring symbol load for "SCSIPORT.SYS" at 80013000 KD: deferring symbol load for "Atdisk.sys" at 80001000 KD: deferring symbol load for "Scsidisk.sys" at 8001b000 KD: deferring symbol load for "Fastfat.sys" at 80372000 Unable to read image header for Floppy.SYS at fc820000 - status c0000001 KD: deferring symbol load for "srv.sys" at fc9e0000 KD: deferring symbol load for "ntdll.dll" at 77f80000 finished re-loading all kernel symbols NT!_PspUnhandledExceptionInSystemThread+0x18: 80131ff8 b801000000      mov     eax,0x1 kd> 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.
 * Contents Deleted ***

Checking Creation Time with !drivers
Use 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.) kd> !drivers Base      Code Size Data Size  Driver Name        Creation Time 80100000                      Ntoskrnl.exe   Fri May 26 18:18:36 1995 80400000                           Hal.dll   Thu May 11 13:54:18 1995 80010000                         Atapi.sys   Tue May 23 21:01:41 1995 80013000                      Scsiport.sys   Fri May 05 23:11:06 1995 80001000                        Atdisk.sys   Fri May 05 23:10:40 1995 8001b000                      Scsidisk.sys   Fri May 05 23:11:01 1995 80372000                       Fastfat.sys   Mon May 22 23:57:13 1995 fc820000                        Floppy.sys   Header Paged Out fc830000                      Scsicdrm.sys   Wed May 10 21:57:03 1995 fc840000                        Fs_Rec.sys   Header Paged Out fc850000                          Null.sys   Header Paged Out fc860000                          Beep.sys   Header Paged Out fc870000                      I8042prt.sys   Fri May 05 23:10:42 1995 fc880000                      Mouclass.sys   Fri May 05 23:10:45 1995 fc890000                      Kbdclass.sys   Fri May 05 23:10:44 1995 fc8b0000                      Videoprt.sys   Fri May 05 23:10:05 1995 fc8a0000                            S3.sys   Fri May 19 21:18:06 1995 fc8c0000                           Vga.sys   Fri May 05 23:10:10 1995 fc8d0000                          Msfs.sys   Fri May 05 23:11:57 1995 fc8e0000                          Npfs.sys   Fri May 05 23:11:40 1995 fc900000                          Ndis.sys   Mon May 22 20:23:18 1995 fc8f0000                         El59x.sys   Fri Feb 10 16:18:09 1995 fc940000                           Tdi.sys   Fri May 05 23:13:09 1995 fc920000                           Nbf.sys   Mon May 08 15:00:47 1995 fc950000                       Netbios.sys   Fri May 05 23:13:19 1995 fc960000                       Parport.sys   Header Paged Out fc970000                      Parallel.sys   Header Paged Out fc980000                        Serial.sys   Fri May 05 23:11:20 1995 fc990000                           Afd.sys   Header Paged Out fc9a0000                           Rdr.sys   Wed May 17 17:18:16 1995 fc9e0000                           Srv.sys   Wed May 24 21:56:59 1995 TOTAL:  1ab460 (1709 kb)  3b7c0 ( 237 kb) (    0 kb     0 kb) kd> 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 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.dbg

Microsoft (R) COFF Binary File Dumper Version 3.00.5270

Copyright (C) Microsoft Corp 1992-1995. All rights reserved.

Dump of file Netbios.dbg

4944 signature

0 flags

14C machine (i386)

306 characteristics

2FAAE94F time date stamp Fri May 05 23:13:19 1995

8D0B checksum of image

10000 base of image

70A0 size 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.

Unable to read DosHeader at 0583002a - status 00000000

Unable to read DosHeader at 0587002a - status 00000000

Unable to read DosHeader at 0588002a - status 00000000

Unable to read DosHeader at 058a002a - status 00000000

Unable to read DosHeader at 058c002a - status 00000000

Unassembling a Function
The 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.
 * List loaded modules

x *!
 * List symbols for a particular module (for example, Ntoskrnl.exe).

x nt!*
 * Select a function to unassemble that is not compiler optimized.

u NT!_NtUnlockFile

Good Symbols
kd> u NT!_NtUnlockFile u NT!_NtUnlockFile NT!_NtUnlockFile: 80156bd8 64a100000000    mov     eax,fs:[00000000] 80156bde 55              push    ebp 80156bdf 8bec            mov     ebp,esp 80156be1 6aff            push    0xff 80156be3 68200d1080      push    0x80100d20 80156be8 68304f1380      push    0x80134f30 80156bed 50              push    eax 80156bee 64892500000000  mov     fs:[00000000],esp kd> 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
kd> u NT!_NTUnlockFile u NT!_NTUnlockFile NT!_NtUnlockFile: 801574a4 7520            jnz     NT!_NtUnlockFile+0x22 (801574c6) 801574a6 6a00            push    0x0 801574a8 8d45dc          lea     eax,[ebp-0x24] 801574ab 50              push    eax 801574ac 53              push    ebx 801574ad ff356c361480    push    dword ptr [NT!_CcNoDelay+0x4 (8014366c)] 801574b3 6a01            push    0x1 801574b5 ff7508          push    dword ptr [ebp+0x8]

Service Pack Symbols
There 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 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 Installation CD-ROM. The symbols should be applied in the same order as the installation.

ADDITIONAL INFORMATION
To find the Kernel Debug How To series of the articles, search on the keyword: debugref.

Windbg 2.0.x Symbol Techniques

In debugger version 2.0.x and greater of the Microsoft Debuggers there are additional symbol verification steps that can be used. For more information, refer to the following Microsoft Web site:

Drivers Development Kit

Additional query words: prodnt debugref ntblue

Keywords: kbinfo KB148660

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.