when i make a break at nt!kifastcallentry function .after it fired, I use the “dd esp” command to look up the stack ,but it showed invalid address ,below is the detail:
kd> dd esp
82932000 ??? ??? ??? ???
82932010 ??? ??? ??? ???
82932020 ??? ??? ??? ???
82932030 ??? ??? ??? ???
82932040 ??? ??? ??? ???
82932050 ??? ??? ??? ???
the address 82932000 is the value of esp register.So many question mark?!
I can think of a number of reasons:
(1) Stack overflow. That’s what I ALWAYS suspect first when I see it is a page boundary. In that case, try to look backwards (0x82931FFF0 for example)
(2) Someone loaded a bogus value into the stack pointer (“mov esp, 0x82932000” or “pop esp”)
(3) any of the other random ways of loading the stack pointer
(4) inpage error (that’s a long shot)
I’ve seen various manifestations of these over the years, but (1) is the big winner normally.
Tony
OSR
as far as i can remember (aka xpsp3 days) and a small check in win10
now when you break on KiFastCallEntry esp always used to be
SYSENTER_ESP_MSR or the value from rdmsr 175 and that address
couldn’t be displayed in windbg
if you step down a few instructions down you can see the real esp is
set from TSS->Esp0 and only then you could display esp
since i couldnt fathom why it is so and couldn’t locate any tidbits in
the multi colored corners of internet i left it as some idiosyncrazy
of windbg
here is a win 10 check esp @ nt!KiFastCallEntry
a better explanation should probably exist hope fully some one can chime in
kd> .printf “%y\n” , @eip
nt!KiFastCallEntry (819893a0)
kd> .printf “%y\n” , @esp
83003000
kd> rdmsr 175
msr[175] = 00000000`83003000
kd> dd esp l4
83003000 ??? ??? ??? ???
kd> dx Debugger.State.PseudoRegisters.Kernel.pcr->TSS->Esp0
Debugger.State.PseudoRegisters.Kernel.pcr->TSS->Esp0 : 0xa5a90dd0
kd> dt nt!_KPCR TSS->Esp0 @$pcr
+0x040 TSS :
+0x004 Esp0 : 0xa5a90dd0
kd> dd poi(0030:00000040)+4 l4
80973004 a5a90dd0 00000010 00000000 00000000
kd> u @eip la
nt!KiFastCallEntry:
819893a0 b923000000 mov ecx,23h
819893a5 6a30 push 30h
819893a7 0fa1 pop fs
819893a9 8ed9 mov ds,cx
819893ab 8ec1 mov es,cx
819893ad 33c9 xor ecx,ecx
819893af 8ee9 mov gs,cx
819893b1 648b0d40000000 mov ecx,dword ptr fs:[40h]
819893b8 8b6104 mov esp,dword ptr [ecx+4] <---- esp will
be all question mark until this line is executed ( the construct is
same in xpsp3 onwards till win10 )
819893bb 6a23 push 23h
On 8/7/16, Tony Mason wrote:
>
>
> I can think of a number of reasons:
>
> (1) Stack overflow. That’s what I ALWAYS suspect first when I see it is a
> page boundary. In that case, try to look backwards (0x82931FFF0 for
> example)
> (2) Someone loaded a bogus value into the stack pointer (“mov esp,
> 0x82932000” or “pop esp”)
> (3) any of the other random ways of loading the stack pointer
> (4) inpage error (that’s a long shot)
>
> I’ve seen various manifestations of these over the years, but (1) is the big
> winner normally.
>
> Tony
> OSR
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
> drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:
></http:></http:>
just back from vacation and getting caught up…
Stacks grow down.
When you’re in this routine you’re at the top of the stack and looking at
the guard page (WinDbg shows question marks to indicate an invalid page). No
one should ever access this address, only addresses lower in memory as
things are pushed on the stack.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@windbg…
when i make a break at nt!kifastcallentry function .after it fired, I use
the “dd esp” command to look up the stack ,but it showed invalid address
,below is the detail:
kd> dd esp
82932000 ??? ??? ??? ???
82932010 ??? ??? ??? ???
82932020 ??? ??? ??? ???
82932030 ??? ??? ??? ???
82932040 ??? ??? ??? ???
82932050 ??? ??? ??? ???
the address 82932000 is the value of esp register.So many question mark?!