I have been emailed the output of a windbg session where the person who
ran it didn’t have the symbols, so the output is something like:
Connected to Windows Server 2008/Windows Vista 6002 x86 compatible
target at (Sat Sep 5 21:40:06.015 2009 (GMT-6)), ptr64 FALSE
…
*** Fatal System Error: 0x0000007e
(0xC0000005,0x00000180,0x805A04A4,0x805A01A0)
…
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be
wrong.
805a0568 8748d7ff 00000000 00000000 000f3000 0x180
805a057c 8748da93 00000007 805a0590 87499b18 xenpci+0x27ff
805a05a0 8748e468 8746cbcc 83828470 0000030f xenpci+0x2a93
805a05b4 874505f0 7c798ff8 00000005 83828470 xenpci+0x3468
805a05cc 8745050b 83828470 8746c900 83828470
Wdf01000!FxPkgPnp::PowerD0Starting+0x2d
805a0644 87451c97 00000316 00000000 83828470
Wdf01000!FxPkgPnp::PowerEnterNewState+0x169
xenpci is my driver, and I can infer that xenpci+0x3468 is probably my
EvtDeviceD0Entry or EvtDeviceD0EntryPostInterruptsEnabled routines, and
that the final crash is most likely a jump to a invalid vector (possibly
because of a buffer overflow or something) but the bit in the middle
could be anything.
Given the .pdb symbol files for my drivers, what is the fastest way to
find out what ‘xenpci+0x3486’ is? Is it a reasonable assumption that
xenpci+x is going to be the same if I booted windbg too, or could there
be some internal reordering (in which case there isn’t much I can do
anyway)?
Thanks
James
> 805a0568 8748d7ff 00000000 00000000 000f3000 0x180
805a057c 8748da93 00000007 805a0590 87499b18 xenpci+0x27ff
805a05a0 8748e468 8746cbcc 83828470 0000030f xenpci+0x2a93
805a05b4 874505f0 7c798ff8 00000005 83828470 xenpci+0x3468
Given the .pdb symbol files for my drivers, what is the fastest way to
find out what ‘xenpci+0x3486’ is? Is it a reasonable assumption that
xenpci+x is going to be the same if I booted windbg too, or could there
be some internal reordering (in which case there isn’t much I can do
anyway)?
Yes, this should work. In fact I think you should be able to literally do
something like:
kd -z xenpci.sys
kd> .lines
kd> u xenpci+0x3486
This doesn’t work when offsets are relative to a function which is not
contiguous due to optimizations (as described in the “Debugging
Performance-Optimized Code” topic in debuggers.chm), but in your case
offsets are relative to the driver base address, so everything should work.
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
Well, I’m not really sure, and I think they’d could be the same, assuming the same build and all, but either way, I don’t see what else there is to try, so I’d give it a a shot, and see what ‘ln’ told me.
Alternatively, you you could use dbg.exe (root of your windbg installation) for the same purpose.
Good luck,
mm
That should have read ‘dbh.exe.’
mm
>
That should have read ‘dbh.exe.’
That seems to give me results that make sense… thanks!
James