Updated symbols for Windows XP SP3

[Indu]

On May 6, 2008, I updated my target machine to Windows XP SP3. However, after
doing so I found out that the kernel symbols available from Microsoft's
symbol server do not match SP3 kernel components. Does anyone know when
updated symbols (corresponding to Windows XP SP3) will be available on the
symbol server? The sooner the better.

Thanks,
-Indu

[Jeffrey Tan[MSFT]]

Hi Indu,

What is version of your ntoskrnl.exe? I just got a WinXP SP3 machine for
testing and I can get the symbol file for the ntoskrnl.exe in local kernel
debugger:

lkd> .sympath
Symbol search path is:
SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols

lkd> !lmi nt
Loaded Module Info: [nt]
Module: ntoskrnl
Base Address: 804d7000
Image Name: ntoskrnl.exe
Machine Type: 332 (I386)
Time Stamp: 48025eab Mon Apr 14 03:27:39 2008
Size: 216680
CheckSum: 2247c2
Characteristics: 10e perf
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 25, 72a7c, 72a7c RSDS - GUID:
{47A5AC97-343A-4A7A-BF14-EFD9E9933772}
Age: 2, Pdb: ntoskrnl.pdb
CLSID 4, 72a78, 72a78 [Data not mapped]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\localsymbols\ntoskrnl.pdb\47A5AC97343A4A7ABF14EFD9E99337722\ntoskrnl.pdb
Load Report: public symbols , not source indexed

c:\localsymbols\ntoskrnl.pdb\47A5AC97343A4A7ABF14EFD9E99337722\ntoskrnl.pdb

lkd> lmvm nt
start end module name
804d7000 806ed680 nt (pdb symbols)
c:\localsymbols\ntoskrnl.pdb\47A5AC97343A4A7ABF14EFD9E99337722\ntoskrnl.pdb
Loaded symbol image file: ntoskrnl.exe
Image path: ntoskrnl.exe
Image name: ntoskrnl.exe
Timestamp: Mon Apr 14 03:27:39 2008 (48025EAB)
CheckSum: 002247C2
ImageSize: 00216680
File version: 5.1.2600.5512
Product version: 5.1.2600.5512
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft? Windows? Operating System
InternalName: ntoskrnl.exe
OriginalFilename: ntoskrnl.exe
ProductVersion: 5.1.2600.5512
FileVersion: 5.1.2600.5512 (xpsp.080413-2111)
FileDescription: NT Kernel & System
LegalCopyright: ? Microsoft Corporation. All rights reserved.

Additionally, can you use "!sym noisy" and "ld nt" commands and paste the
debugger symbol loading details here for analysis? Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[RossettoeCioccolato]

Jeffrey,

I get the same output that you do from !lmi. But when I try "!process 0 0"
I get the following error:

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_LIST_ENTRY ***
*** ***
*************************************************************************
Unable to read _LIST_ENTRY @ 8088a358

Regards,

George.

[Jeffrey Tan[MSFT]]

Hi George,

Thanks for your feedback.

Oh, yes, I can reproduce this problem on my WinXP SP3 machine.
Additionally, I got empty output with command "dt nt!*" while getting
correct output with "x nt!*". So I assume the type information is stripped
from the ntoskrnl.exe.

I will try to get some information for this issue and get back to you ASAP.
Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

=========================================

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

[Indu]

Hi Jeffrey,

Thank you for your response. I was out of town and had not checked your
reply before. Since you have been able to reproduce the problem, I will wait
for a resolution.

Thanks,
-Indu

[Jeffrey Tan[MSFT]]

Hi Indu,

Thanks for your feedback.

The windbg has fixed this issue. It now contains the type for ntoskrnl.exe.
You may go to your local cache folder and delete the old ntoskrnl.pdb file
and try to load it from the symbol server again.

Based on my testing, "!process 0 0" command works correct now.

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

[Indu]

Hi Jeffrey,
Yes, that fixes it. Thank you for your help.
-Indu

[P.]

Hi Jeffrey

I'm having a similar problem with Vista x64 SP1:

Microsoft (R) Windows Debugger Version 6.9.0003.113 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [\\Server\Archive\3b.1.f.dmp]
Kernel Complete Dump File: Full address space is available

Symbol search path is:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2008 Kernel Version 6001 (Service Pack 1) MP (2 procs) Free
x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6001.18000.amd64fre.longhorn_rtm.080118-1840
Kernel base = 0xfffff800`0281a000 PsLoadedModuleList = 0xfffff800`029dfdb0
Debug session time: Fri May 30 15:41:11.086 2008 (GMT-7)
System Uptime: 0 days 0:00:45.836
Loading Kernel Symbols
......................................................................................................................................................
Loading User Symbols
.........................................................................................................
Loading unloaded module list
...................

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff80002ad2e50, fffffa6006b18d20, 0}

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
Probably caused by : ntkrnlmp.exe ( nt!CmpGetNameControlBlock+108 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002ad2e50, Address of the exception record for the exception
that caused the bugcheck
Arg3: fffffa6006b18d20, Address of the context record for the exception that
caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!CmpGetNameControlBlock+108
fffff800`02ad2e50 443b3e cmp r15d,dword ptr [rsi]

CONTEXT: fffffa6006b18d20 -- (.cxr 0xfffffa6006b18d20)
rax=fffff88000021000 rbx=0000000000000000 rcx=fffff88000022dd0
rdx=0000000004c6fe36 rsi=0000400000000000 rdi=00000000000001dd
rip=fffff80002ad2e50 rsp=fffffa6006b19580 rbp=fffff88000021000
r8=000000000000000d r9=000000000000007d r10=000000000000004c
r11=fffff88009dee81c r12=0000000000000026 r13=0000000000001dd0
r14=fffffa6006b19618 r15=0000000070c3d314
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010206
nt!CmpGetNameControlBlock+0x108:
fffff800`02ad2e50 443b3e cmp r15d,dword ptr [rsi]
ds:002b:00004000`00000000=????????
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: explorer.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80002ad2080 to fffff80002ad2e50

STACK_TEXT:
fffffa60`06b19580 fffff800`02ad2080 : 00000000`00000001 00000000`00001dd0
00000000`00001dd0 00000000`00000000 : nt!CmpGetNameControlBlock+0x108
fffffa60`06b195e0 fffff800`02ae0198 : fffff880`009ac010 00000000`00ec1850
fffff880`009ac010 00000000`00002160 : nt!CmpCreateKeyControlBlock+0x220
fffffa60`06b19670 fffff800`02af067e : 00000000`00000040 fffff800`00000000
fffffa80`08866010 fffffa60`06b19c01 : nt!CmpParseKey+0xd08
fffffa60`06b19910 fffff800`02af4884 : 00000000`00000694 fffffa80`06c43b01
00000000`00000040 fffffa80`039ae080 : nt!ObpLookupObjectName+0x2ce
fffffa60`06b19a20 fffff800`02ada86f : 00000000`00020019 00000000`00020000
00000000`00000001 00000000`00000000 : nt!ObOpenObjectByName+0x2f4
fffffa60`06b19af0 fffff800`0286ee33 : 00000000`067eede8 fffffa60`00020019
00000000`067eec60 00000000`00000000 : nt!CmOpenKey+0x25d
fffffa60`06b19c20 00000000`76e05b9a : 000007fe`fefe96fe 00000000`c0000034
00000000`00000000 7ec4cc8d`00000001 : nt!KiSystemServiceCopyEnd+0x13
00000000`067eec18 000007fe`fefe96fe : 00000000`c0000034 00000000`00000000
7ec4cc8d`00000001 00000003`00000020 : ntdll!NtOpenKey+0xa
00000000`067eec20 000007fe`fefe98c4 : 00000000`00000694 00000000`067eed38
00000000`00000000 00000000`00020019 : ADVAPI32!LocalBaseRegOpenKey+0x153
00000000`067eece0 000007fe`fefe9921 : 00000000`00000000 00000000`00000000
000007fe`fe0a31b4 00000000`00000001 : ADVAPI32!RegOpenKeyExInternalW+0x1f2
00000000`067eed70 000007fe`fe0311e1 : 00000000`00000000 00000000`040264b0
000007fe`fe0a31b4 00000000`067eeee8 : ADVAPI32!RegOpenKeyExW+0x19
00000000`067eedb0 000007fe`fe039651 : 00000000`0607bfc0 00000000`067ef2e8
00000000`0607bfc0 00000000`00000026 :
ole32!CComCat::IsClassOfCategoriesEx+0x171
00000000`067ef290 000007fe`f9232b49 : 00000000`067ef5d8 00000000`00000000
00000000`76ed64e0 00000000`76d02af4 :
ole32!CEnumClassesOfCategories::Next+0xc1
00000000`067ef540 000007fe`f9232dae : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`04097000 : BROWSEUI!_EnumerateGuids+0x8b
00000000`067ef590 000007fe`f9232cfd : 00000000`00000000 00000000`04045ac0
00000000`0607bfc0 00000000`02f89b18 :
BROWSEUI!SHWriteImplementingClassesOfCategory+0x76
00000000`067ef5d0 000007fe`f9232c98 : 00000000`040045d0 00000000`00000000
00000000`00000000 00000000`00000000 :
BROWSEUI!_WriteClassesOfCategories+0x4a
00000000`067ef600 000007fe`f923286b : 00000000`040045d0 00000000`00000938
00000000`00000003 00000000`0000000b :
BROWSEUI!CComCatCacheTask::InternalResumeRT+0x28
00000000`067ef640 000007fe`f923afd3 : 00000000`040b5330 00000000`02f16a20
00000000`00000000 00000000`00000000 : BROWSEUI!CRunnableTask::Run+0xd0
00000000`067ef670 000007fe`f923b213 : 00000000`02f15210 00000000`02f15200
00000000`00000000 00000000`00000000 :
BROWSEUI!CShellTaskThread::ThreadProc+0x2c7
00000000`067ef750 000007fe`fd75fc63 : 00000000`02f15210 00000000`00000000
00000000`0044d560 00000000`0044d560 :
BROWSEUI!CShellTaskThread::s_ThreadProc+0x33
00000000`067ef780 00000000`76dc5a73 : 00000000`0409c340 00000000`0409c340
000007fe`f8707080 000007ff`fff9a000 : SHLWAPI!ExecuteWorkItemThreadProc+0xf
00000000`067ef7b0 00000000`76e01220 : 00000000`0042fac0 00000000`02fb7a98
00000000`003e1188 00000000`0044d560 : ntdll!RtlpTpWorkCallback+0xf0
00000000`067ef860 00000000`76be495d : 00000000`0042fac0 00000001`00010002
00000000`0042fac0 00000000`0409c340 : ntdll!TppWorkerThread+0x3d6
00000000`067efae0 00000000`76de8791 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`067efb10 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

FOLLOWUP_IP:
nt!CmpGetNameControlBlock+108
fffff800`02ad2e50 443b3e cmp r15d,dword ptr [rsi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!CmpGetNameControlBlock+108

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 479192b7

STACK_COMMAND: .cxr 0xfffffa6006b18d20 ; kb

FAILURE_BUCKET_ID: X64_0x3B_nt!CmpGetNameControlBlock+108

BUCKET_ID: X64_0x3B_nt!CmpGetNameControlBlock+108

Followup: MachineOwner
---------

1: kd> !lmi nt
Loaded Module Info: [nt]
Module: ntkrnlmp
Base Address: fffff8000281a000
Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)
Time Stamp: 479192b7 Fri Jan 18 22:03:35 2008
Size: 518000
CheckSum: 485fc7
Characteristics: 22 perf

Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 12e91c, 12df1c RSDS - GUID:
{AAFD50F8-1F4A-41F3-A99C-ECBB18945C1F}
Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 12e918, 12df18 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\nt\ntkrnlmp.pdb\AAFD50F81F4A41F3A99CECBB18945C1F2\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\symbols\nt\ntkrnlmp.pdb\AAFD50F81F4A41F3A99CECBB18945C1F2\ntkrnlmp.pdb
1: kd> !lmi kernel32
Loaded Module Info: [kernel32]
Module: kernel32
Base Address: 0000000076bc0000
Image Name: kernel32.dll
Machine Type: 34404 (X64)
Time Stamp: 4791ada5 Fri Jan 18 23:58:29 2008
Size: 12b000
CheckSum: 130b1b
Characteristics: 2022 perf

Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, bbecc, bb2cc RSDS - GUID:
{B711C92D-F84F-44F3-89CA-44A27E40E066}
Age: 2, Pdb: kernel32.pdb
CLSID 4, bbec8, bb2c8 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\ke\kernel32.pdb\B711C92DF84F44F389CA44A27E40E0662\kernel32.pdb

Load Report: public symbols , not source indexed

c:\symbols\ke\kernel32.pdb\B711C92DF84F44F389CA44A27E40E0662\kernel32.pdb
1: kd> dt nt! *
Symbol nt! not found.
1: kd> x nt! *
fffff800`028553c0 nt!MiSyncSystemPdes = <no type information>
fffff800`02b9cca0 nt!ObpStopRTStackTrace = <no type information>
fffff800`02a62e00 nt!RtlSetOwnerSecurityDescriptor = <no type information>
fffff800`02ccefc0 nt!PnpInitializeLegacyBusInformationTable = <no type
information>
fffff800`02aba0c8 nt!AlpcpDeleteBlob = <no type information>
fffff800`02b932a0 nt!TmpNamespaceEnumerate = <no type information>
fffff800`02ce1630 nt!IopStoreArcInformation = <no type information>
fffff800`02bc9b50 nt!CmpUpdateParentForEachSon = <no type information>
fffff800`02ab6178 nt!PsReferenceImpersonationToken = <no type information>
fffff800`028afd00 nt! ?? ::FNODOBFM::`string' = <no type information>
fffff800`02c16930 nt!GetSortData = <no type information>
fffff800`02bbbd40 nt!WmipGetDevicePDO = <no type information>
fffff800`02867528 nt!KiSetPriorityThread = <no type information>
fffff800`02b78650 nt!CmpQueueLazyCommitWorker = <no type information>
fffff800`02870cd0 nt!KiInterruptDispatchNoEOI = <no type information>
fffff800`0285c848 nt!RtlFindLastBackwardRunClear = <no type information>
fffff800`02953910 nt!_newclmap = <no type information>
fffff800`02992420 nt!_lc_codepage = <no type information>
fffff800`02905610 nt!PopQueueBatteryStatusTimeout = <no type information>
fffff800`02b9ad60 nt!ExpGetSystemFirmwareTableInformation = <no type
information>
fffff800`02bdd6f0 nt!CmpDoReDoDeleteValue = <no type information>
fffff800`0286c440 nt!ZwRenameTransactionManager = <no type information>
...

[Jeffrey Tan[MSFT]]

Hi,

Yes, I have asked our lab to setup a virtual machine for Vista x64 SP1. By
performing local kernel debugging, I can reproduce this problem:

lkd> .symfix c:\localsymbols
DBGHELP: Symbol Search Path:
SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
lkd> .reload
Connected to Windows Server 2008 6001 x64 target, ptr64 TRUE
Loading Kernel Symbols
...........................................................................
................................................
Loading User Symbols
......................................................................
Loading unloaded module list
...
..

lkd> lmvm nt
start end module name

fffff800`0165b000 fffff800`01b73000 nt (pdb symbols)
c:\localsymbols\ntkrnlmp.pdb\AAFD50F81F4A41F3A99CECBB18945C1F2\ntkrnlmp.pdb
Loaded symbol image file: ntkrnlmp.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
Timestamp: Fri Jan 18 22:03:35 2008 (479192B7)
CheckSum: 00485FC7
ImageSize: 00518000
File version: 6.0.6001.18000
Product version: 6.0.6001.18000

File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft? Windows? Operating System

InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.0.6001.18000
FileVersion: 6.0.6001.18000 (longhorn_rtm.080118-1840)

FileDescription: NT Kernel & System

LegalCopyright: ? Microsoft Corporation. All rights reserved.
lkd> dt nt!*
[empty output]

I will forward this issue to the windbg symbol server team. I will get back
to you whenever I got any update. Thanks.

[Avi Cohen Stuart]

Jeffrey,

I also noted that in stream.sys with SP2 dt stream!* produced a lot of
interesting output which is
missing in SP3 for both normal and check/debugged variants. The pdb file is
smalled in SP3

Regards,

Avi Cohen Stuart.

""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message
news:669MdaHx...@TK2MSFTNGHUB02.phx.gbl...

[slothman]

Have they also done so for ntkrnlmp.exe? I'm getting the exact same problem
(nt!_LIST_ENTRY) missing under WinDbg 6.9.0003.113 AMD64 running under
Windows Server 2003 Standard x64 Edition Build 3790 (Service Pack 2)
debugging a dump from Windows Server 2003 Kernel Version 3790 (Service Pack
2.2851) MP (8 procs) Free x64. After completely wiping out my local cache of
symbols and reloading from the symbol server, I get:

3: kd> !process 0 7

**** NT ACTIVE PROCESS DUMP ****
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_LIST_ENTRY ***
*** ***
*************************************************************************

Unable to read _LIST_ENTRY @ fffff800011d1e10
3: kd> !lmi nt
Loaded Module Info: [nt]
Module: ntkrnlmp
Base Address: fffff80001000000

Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)

Time Stamp: 4588a2d2 Tue Dec 19 18:41:22 2006
Size: 48d000
CheckSum: 457442
Characteristics: 22 perf

Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 15d08c, 15c68c RSDS - GUID:
{CD040370-904F-4CB6-9F87-2BA1D200AD86}
Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 15d088, 15c688 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

[Pat Styles [MSFT]]

Hello.

What happens when you roll back to the 6.8 debugger?

.pat styles [microsoft]

[Pat Styles [MSFT]]

Hello.

What happens when you roll back to the 6.8 version of the debugger?

.pat styles [microsoft}

[slothman]

"Pat Styles [MSFT]" wrote:
> Hello.
>
> What happens when you roll back to the 6.8 version of the debugger?
>

> ..pat styles [microsoft}

Installed 6.8.4, blew away my symbol cache, and loaded the crash dump again.
Same problem: Unable to read _LIST_ENTRY @ fffff800011d1e10.

[Jeffrey Tan[MSFT]]

Hi,

Sorry for letting you wait.

By further discussing with the symbols and windbg team, they confirmed that
the symbol file for "nt" on Microsoft public symbol server actually
contains the type information. However, the "dt nt!*" command does not show
them. However, if we issue the "dt nt!_eprocess" command, we can see it
content:

lkd> dt nt!*
lkd> dt nt!_eprocess
nt!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x0c0 ProcessLock : _EX_PUSH_LOCK
+0x0c8 CreateTime : _LARGE_INTEGER
+0x0d0 ExitTime : _LARGE_INTEGER
+0x0d8 RundownProtect : _EX_RUNDOWN_REF
+0x0e0 UniqueProcessId : Ptr64 Void
+0x0e8 ActiveProcessLinks : _LIST_ENTRY
+0x0f8 QuotaUsage : [3] Uint8B
+0x110 QuotaPeak : [3] Uint8B
+0x128 CommitCharge : Uint8B
+0x130 PeakVirtualSize : Uint8B
+0x138 VirtualSize : Uint8B
+0x140 SessionProcessLinks : _LIST_ENTRY
+0x150 DebugPort : Ptr64 Void
+0x158 ExceptionPortData : Ptr64 Void
+0x158 ExceptionPortValue : Uint8B
+0x158 ExceptionPortState : Pos 0, 3 Bits
+0x160 ObjectTable : Ptr64 _HANDLE_TABLE
+0x168 Token : _EX_FAST_REF
+0x170 WorkingSetPage : Uint8B
+0x178 AddressCreationLock : _EX_PUSH_LOCK
+0x180 RotateInProgress : Ptr64 _ETHREAD
+0x188 ForkInProgress : Ptr64 _ETHREAD
+0x190 HardwareTrigger : Uint8B
+0x198 PhysicalVadRoot : Ptr64 _MM_AVL_TABLE
....

That's why the "!process 0 0" command still works well. The debugger team
has filed this "dt module!*" issue and will fix it in next release. Anyway,
the x64 Vista SP1 symbol is ok.

Another problem here is the warnings about the lack of symbols for
"kernel32!pNlsUserInfo". kernel32 has never contained symbols for
pNlsUserInfo in the public symbols - the warning has been triggered by a
change in the debuggers. We have reported this issue to "!analyze" team. I
think they will help to suppress this warning in future. Anyway, the output
by "!analyze -v" should be correct.

Thank you for reporting this.

[Pat Styles [MSFT]]

Hello.

Jeffrey Tan's posts on this thread explain the problem quite well.

.pat styles [microsoft]

[slothman]

""Jeffrey Tan[MSFT]"" wrote:
> By further discussing with the symbols and windbg team, they confirmed that
> the symbol file for "nt" on Microsoft public symbol server actually
> contains the type information. However, the "dt nt!*" command does not show
> them. However, if we issue the "dt nt!_eprocess" command, we can see it
> content:
>
> lkd> dt nt!*
> lkd> dt nt!_eprocess

Has the same scrutiny been applied to the PDBs for multiprocessor kernels?

Using WinDbg 6.9.0003.113 AMD64 after clearing out the symbol cache:

3: kd> dt nt!_eprocess

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: nt!_eprocess ***
*** ***
*************************************************************************
Symbol nt!_eprocess not found.
3: kd> !process 0 0

**** NT ACTIVE PROCESS DUMP ****

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: nt!_LIST_ENTRY ***
*** ***
*************************************************************************

Unable to read _LIST_ENTRY @ fffff800011d1e10
3: kd> !lmi nt

Loaded Module Info: [nt]
Module: ntkrnlmp

Base Address: fffff80001000000

Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)

Time Stamp: 4588a2d2 Tue Dec 19 18:41:22 2006
Size: 48d000
CheckSum: 457442

Characteristics: 22 perf
Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 15d08c, 15c68c RSDS - GUID:
{CD040370-904F-4CB6-9F87-2BA1D200AD86}

Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 15d088, 15c688 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

[Jeffrey Tan[MSFT]]

Sure, I am using the multiprocessor kernel in local kernel debugging for
test. See below:

lkd> vertarget
Windows Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6001.18000.amd64fre.longhorn_rtm.080118-1840

Kernel base = 0xfffff800`0165b000 PsLoadedModuleList = 0xfffff800`01820db0
Debug session time: Wed Jun 4 19:18:27.510 2008 (GMT-7)
System Uptime: 2 days 21:05:15.480

lkd> !cpuid
CP F/M/S Manufacturer MHz
0 6,15,8 GenuineIntel 1862
1 6,15,8 GenuineIntel 1863

lkd> !lmi nt

Loaded Module Info: [nt]
Module: ntkrnlmp

Base Address: fffff8000165b000

Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)

Time Stamp: 479192b7 Fri Jan 18 22:03:35 2008
Size: 518000
CheckSum: 485fc7

Characteristics: 22 perf
Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 12e91c, 12df1c RSDS - GUID:
{AAFD50F8-1F4A-41F3-A99C-ECBB18945C1F}

Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 12e918, 12df18 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\localsymbols\ntkrnlmp.pdb\AAFD50F81F4A41F3A99CECBB18945C1F2\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\localsymbols\ntkrnlmp.pdb\AAFD50F81F4A41F3A99CECBB18945C1F2\ntkrnlmp.pdb

lkd> dt nt!_eprocess
nt!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x0c0 ProcessLock : _EX_PUSH_LOCK
+0x0c8 CreateTime : _LARGE_INTEGER
+0x0d0 ExitTime : _LARGE_INTEGER
+0x0d8 RundownProtect : _EX_RUNDOWN_REF
+0x0e0 UniqueProcessId : Ptr64 Void
+0x0e8 ActiveProcessLinks : _LIST_ENTRY
+0x0f8 QuotaUsage : [3] Uint8B
+0x110 QuotaPeak : [3] Uint8B
+0x128 CommitCharge : Uint8B
+0x130 PeakVirtualSize : Uint8B
+0x138 VirtualSize : Uint8B
+0x140 SessionProcessLinks : _LIST_ENTRY

...

Thanks.

[slothman]

I'm getting different results on Windows Server 2003:

3: kd> vertarget

Windows Server 2003 Kernel Version 3790 (Service Pack 2.2851) MP (8 procs)
Free x64

Product: Server, suite: TerminalServer SingleUserTS ComputeServer
Built by: 3790.dnsrv.061219-1400
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d5100
Debug session time: Tue Jun 3 08:15:55.985 2008 (GMT-7)
System Uptime: 0 days 1:15:34.343
3: kd> !cpuid

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***

*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
CP F/M/S Manufacturer MHz
0 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
1 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
2 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
3 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
4 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
5 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
6 6,15,11 GenuineIntel 3000
[nt!_KPRCB message again]
7 6,15,11 GenuineIntel 3000
3: kd> !lmi nt

Loaded Module Info: [nt]
Module: ntkrnlmp

Base Address: fffff80001000000

Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)

Time Stamp: 4588a2d2 Tue Dec 19 18:41:22 2006
Size: 48d000
CheckSum: 457442

Characteristics: 22 perf
Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 15d08c, 15c68c RSDS - GUID:
{CD040370-904F-4CB6-9F87-2BA1D200AD86}

Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 15d088, 15c688 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\symbols\ntkrnlmp.pdb\CD040370904F4CB69F872BA1D200AD862\ntkrnlmp.pdb

[Jeffrey Tan[MSFT]]

Oh, sorry, I mistake you as using Vista x64. I have setup another WIn2003
x64 SP2 machine for testing. However, I still can get the type information:

lkd> !lmi nt

Loaded Module Info: [nt]
Module: ntkrnlmp
Base Address: fffff80001000000
Image Name: ntkrnlmp.exe
Machine Type: 34404 (X64)

Time Stamp: 460280f7 Thu Mar 22 21:13:27 2007
Size: 491000
CheckSum: 45f050

Characteristics: 22 perf
Debug Data Dirs: Type Size VA Pointer

CODEVIEW 25, 15dd74, 15d374 RSDS - GUID:
{08F4D00C-3B5A-4B34-B2D3-AE8402F92780}
Age: 2, Pdb: ntkrnlmp.pdb
CLSID 4, 15dd70, 15d370 [Data not mapped]

Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol server.

c:\localsymbols\ntkrnlmp.pdb\08F4D00C3B5A4B34B2D3AE8402F927802\ntkrnlmp.pdb

Load Report: public symbols , not source indexed

c:\localsymbols\ntkrnlmp.pdb\08F4D00C3B5A4B34B2D3AE8402F927802\ntkrnlmp.pdb

lkd> vertarget
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free
x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070321-2337
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d4140
Debug session time: Fri Jun 6 10:33:55.019 2008 (GMT+8)
System Uptime: 0 days 0:21:18.828

lkd> !cpuid
CP F/M/S Manufacturer MHz
0 15,6,8 GenuineIntel 3001
1 15,6,8 GenuineIntel 3009
2 15,6,8 GenuineIntel 2998
3 15,6,8 GenuineIntel 3101

lkd> dt nt!_eprocess
+0x000 Pcb : _KPROCESS
+0x0b8 ProcessLock : _EX_PUSH_LOCK
+0x0c0 CreateTime : _LARGE_INTEGER
+0x0c8 ExitTime : _LARGE_INTEGER
+0x0d0 RundownProtect : _EX_RUNDOWN_REF
+0x0d8 UniqueProcessId : Ptr64 Void
+0x0e0 ActiveProcessLinks : _LIST_ENTRY
+0x0f0 QuotaUsage : [3] Uint8B
+0x108 QuotaPeak : [3] Uint8B
+0x120 CommitCharge : Uint8B
...

Do you use the RTM version of Win2003 x64 SP2? In your "Vertarget" output,
it states "Service Pack 2.2851" while I got "Service Pack 2". Also, your
kernel is built in 061219(2006, 12, 19), while my RTM kernel is built
070321(2007, 03, 21). So, maybe you are using beta or RC version of the
Win2003 SP2? I think that's why your kernel image symbol file does not have
type information.