I’m having a problem with the !idt command under windbg under Windows
2003 x64 - when I try it says “Can’t read kernel symbols.”.
I googled and found that someone reported the exact same problem in
2004, and the response from Microsoft was “We’ll fix it for Longhorn,
and are looking into fixing the public symbols for w2k3 which are
available through the Internet Symbol Server.”.
Either it hasn’t been fixed or I’m doing something wrong… all the
other symbols appear to be working fine though. Would Windows download
updated symbols from the internet if they existed, or would it never
re-check once it thought it had everything?
Is there another way to dump the IDT?
Thanks
James
I just tried in on a partial CHK of Win7 x86_64 and it works; I don’t recall it ever not working on any platform that I’ve run it on, but I seriously doubt that I’ve tried on 2003 x64.
2: kd> !idt
Dumping IDT:
00: fffff80001876900 nt!KiDivideErrorFault
01: fffff80001876a00 nt!KiDebugTrapOrFault
02: fffff80001876bc0 nt!KiNmiInterruptStart Stack = 0xFFFFF88002067FC0
.
.
.
This is just my opinion, but in the case of any windbg that (let’s assume for the moment) had issues on only one ‘old’ platform , I would say that the chances of it getting fixed are damn close to zero.
You can dump it quite simply by using ‘dt,’ but it’s kind of messy because the address isn’t linear in memory:
r irdtr
idtr=fffff880020685c0
dt nt!_KIDTENTRY64 0xfffff880020685c0
2: kd> dt nt!_KIDTENTRY64 0xfffff880020685c0
+0x000 OffsetLow : 0x6900
+0x002 Selector : 0x10
+0x004 IstIndex : 0y000
+0x004 Reserved0 : 0y00000 (0)
+0x004 Type : 0y01110 (0xe)
+0x004 Dpl : 0y00
+0x004 Present : 0y1
+0x006 OffsetMiddle : 0x187
+0x008 OffsetHigh : 0xfffff800
+0x00c Reserved1 : 0
+0x000 Alignment : 0x1878e00`00106900
kd> dt nt!_KIDTENTRY64 OffsetHigh OffsetMiddle OffsetLow 0xfffff880020685c0
+0x000 OffsetLow : 0x6900
+0x006 OffsetMiddle : 0x187
+0x008 OffsetHigh : 0xfffff800
There is no doubt some way to combine the results in to something that resembles ‘0xfffff80001876900’ (in this case), but I don’t know how; when I encounter problems like these, I almost always write an extension, as I find easier to do than to figure out how one can do it using windbg’s bizzaro syntax, which my fingers can’t seem to type in most cases anyway.
You can prefix the options to ‘dt’ with ‘-a ,’ where is the number of idt entries your wish to dump:
2: kd> dt -a2 nt!_KIDTENTRY64 OffsetHigh OffsetMiddle OffsetLow 0xfffff880020685c0
[0] @ fffff880020685c0
---------------------------------------------
+0x000 OffsetLow : 0x6900
+0x006 OffsetMiddle : 0x187
+0x008 OffsetHigh : 0xfffff800
[1] @ fffff880020685d0
---------------------------------------------
+0x000 OffsetLow : 0x6a00
+0x006 OffsetMiddle : 0x187
+0x008 OffsetHigh : 0xfffff800
Good luck,
mm
I forgot - you lost me on the ‘windows download’ part? Do you mean will symbol server update your symbols automatically? Or are you downloading them from the windbg site? Other?
mm
>
I forgot - you lost me on the ‘windows download’ part? Do you mean
will
symbol server update your symbols automatically? Or are you
downloading them
from the windbg site? Other?
I mean, suppose I ran windbg yesterday and it downloaded the symbol file
ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
updated the ntoskrnl.pdb file on their symbols web site. When I run
windbg today does it check the symbols web site to see if there is an
updated version of ntoskrnl.pdb?
Thanks
James
The debugger should just prefer the local cache if it has a match, without going out to check against the symbol server for an updated version of the same binary. (This is a good thing for performance reasons as you don’t want to be sitting there waiting on http round trips for every single module each time you debug something, for example.)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Sunday, November 22, 2009 11:38 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] !idt doesn’t work on x64 Windows
I forgot - you lost me on the ‘windows download’ part? Do you mean
will
symbol server update your symbols automatically? Or are you
downloading them
from the windbg site? Other?
I mean, suppose I ran windbg yesterday and it downloaded the symbol file
ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
updated the ntoskrnl.pdb file on their symbols web site. When I run
windbg today does it check the symbols web site to see if there is an
updated version of ntoskrnl.pdb?
Thanks
James
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>I’m having a problem with the !idt command under windbg under Windows
2003 x64 - when I try it says “Can’t read kernel symbols.”.
This works fine on my local workstation, which is XP x64 so basically the
same thing as Server 2003 x64. Two things I can think of:
- Make sure you’re using the “correct” !idt, there’s an old crufty one in a
one of the other extensions. So, try:
!kdexts.idt
And see if that makes a difference.
- You can try the symbol lookup debugging options and see if you can figure
out what it’s looking for and can’t find:
.show_sym_failures /s /t
.show_read_failures /v
That might dump something interesting in the debugger that will give folks
something to work with.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“James Harper” wrote in message
news:xxxxx@ntdev…
I’m having a problem with the !idt command under windbg under Windows
2003 x64 - when I try it says “Can’t read kernel symbols.”.
I googled and found that someone reported the exact same problem in
2004, and the response from Microsoft was “We’ll fix it for Longhorn,
and are looking into fixing the public symbols for w2k3 which are
available through the Internet Symbol Server.”.
Either it hasn’t been fixed or I’m doing something wrong… all the
other symbols appear to be working fine though. Would Windows download
updated symbols from the internet if they existed, or would it never
re-check once it thought it had everything?
Is there another way to dump the IDT?
Thanks
James
James Harper wrote:
I mean, suppose I ran windbg yesterday and it downloaded the symbol file
ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
updated the ntoskrnl.pdb file on their symbols web site. When I run
windbg today does it check the symbols web site to see if there is an
updated version of ntoskrnl.pdb?
Step back and think about this for a moment. PDB files cannot change
asynchronously. A PDB file is created when the associated executable is
compiled. Both are produced by the same build process. Thus, the only
way that ntoskrnl.pdb would need to be “updated” is if you had installed
a new version of ntoskrnl.exe. In that case, the checksum of
ntoskrnl.exe will change. The symbol files in your local cache are
marked with the executable’s checksum, so the search will fail, and it
will go download a new PDB.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Thus, the only way that ntoskrnl.pdb would need to be “updated” is if you
had installed
a new version of ntoskrnl.exe.
There is an exception to this. Occasionally the symbols on the public server
get updated to add type information that wasn’t there before (usually in
response to a bug report of a broken extension with public PDBs). In that
case the checksums still match and the only way to get the new PDB is to
delete your existing cache entry and fetch a new one from the server.
Doesn’t happen very often, but when it does .reload /o /f comes in handy.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> James Harper wrote:
>> I mean, suppose I ran windbg yesterday and it downloaded the symbol file
>> ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
>> updated the ntoskrnl.pdb file on their symbols web site. When I run
>> windbg today does it check the symbols web site to see if there is an
>> updated version of ntoskrnl.pdb?
>>
>
> Step back and think about this for a moment. PDB files cannot change
> asynchronously. A PDB file is created when the associated executable is
> compiled. Both are produced by the same build process. Thus, the only
> way that ntoskrnl.pdb would need to be “updated” is if you had installed
> a new version of ntoskrnl.exe. In that case, the checksum of
> ntoskrnl.exe will change. The symbol files in your local cache are
> marked with the executable’s checksum, so the search will fail, and it
> will go download a new PDB.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
If you do wish to force a recopy of the pdbs, btw, .reload /f /o will do the trick. This is generally only useful if the download got truncated in a strange way (e.g. no Content-Length on the HTTP connection + early disconnect).
-----Original Message-----
From: Tim Roberts
Sent: Monday, November 23, 2009 10:00
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] !idt doesn’t work on x64 Windows
James Harper wrote:
> I mean, suppose I ran windbg yesterday and it downloaded the symbol file
> ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
> updated the ntoskrnl.pdb file on their symbols web site. When I run
> windbg today does it check the symbols web site to see if there is an
> updated version of ntoskrnl.pdb?
>
Step back and think about this for a moment. PDB files cannot change
asynchronously. A PDB file is created when the associated executable is
compiled. Both are produced by the same build process. Thus, the only
way that ntoskrnl.pdb would need to be “updated” is if you had installed
a new version of ntoskrnl.exe. In that case, the checksum of
ntoskrnl.exe will change. The symbol files in your local cache are
marked with the executable’s checksum, so the search will fail, and it
will go download a new PDB.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>… PDB files cannot change
> asynchronously. A PDB file is created when the associated executable is
> compiled. Both are produced by the same build process. Thus, the only
> way that ntoskrnl.pdb would need to be “updated” is if you had installed
> a new version of ntoskrnl.exe
Unless those pdb files on the MS server are re-released
(stripped of private symbols or whatever).
The “hash” in executables that is used to match the pdb, is not a file
checksum -
in the sense that you can modify both pdb and executable, and the pdb
still will match.
–pa
>ntoskrnl.pdb into my c:\websymbols directory, then overnight Microsoft
updated the ntoskrnl.pdb file on their symbols web site.
This is not important. The new PDB is for the new EXE, and you have not replaced the EXE yet.
windbg today does it check the symbols web site to see if there is an
updated version of ntoskrnl.pdb?
This is only important if you have updated the EXE, and, to solve this, use MS’s symbol server to auto download the new PDB.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>
> ntoskrnl.pdb into my c:\websymbols directory, then overnight
Microsoft
> updated the ntoskrnl.pdb file on their symbols web site.
This is not important. The new PDB is for the new EXE, and you have
not
replaced the EXE yet.
In November 2004, Jason Shay from Microsoft posted on this list (someone
else reported the same problem):
“Thanks for the report; a case of public symbols not having enough type
info. We’ll fix it for Longhorn, and are looking into fixing the public
symbols for w2k3 which are available through the Internet Symbol
Server.”
What’s your interpretation of that? Mine is that the symbols are broken
and Microsoft were considering releasing an update for W2K3. Do you
think they would release a new exe as well just for a symbol update???
James
If the symbols were updated on the sym server, a new exe would not have been released. They would have updated the existing symbol file to contain the info so that it would work with the released bits as is
d
-----Original Message-----
From: James Harper
Sent: Friday, November 27, 2009 2:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] !idt doesn’t work on x64 Windows
>
> > ntoskrnl.pdb into my c:\websymbols directory, then overnight
Microsoft
> > updated the ntoskrnl.pdb file on their symbols web site.
>
> This is not important. The new PDB is for the new EXE, and you have
not
> replaced the EXE yet.
>
In November 2004, Jason Shay from Microsoft posted on this list (someone
else reported the same problem):
“Thanks for the report; a case of public symbols not having enough type
info. We’ll fix it for Longhorn, and are looking into fixing the public
symbols for w2k3 which are available through the Internet Symbol
Server.”
What’s your interpretation of that? Mine is that the symbols are broken
and Microsoft were considering releasing an update for W2K3. Do you
think they would release a new exe as well just for a symbol update???
James
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer