Prev: IOCTL_DISK_DELETE_DRIVE_LAYOUT
Next: How to debug Explorer crash on logoff
From: rotor cli on 21 Sep 2009 05:58
1: kd> kL
ChildEBP RetAddr
a5a2ac64 80502d26 nt!KiSwapContext+0x2f
a5a2ac70 804faf20 nt!KiSwapThread+0x8a
a5a2ac98 805a4d6c nt!KeWaitForSingleObject+0x1c2
a5a2ad48 8054086c nt!NtReplyWaitReceivePortEx+0x3dc
a5a2ad48 7c91eb94 nt!KiFastCallEntry+0xfc
00a0fe18 7c91e399 ntdll!KiFastSystemCallRet
00a0fe1c 77e56703 ntdll!NtReplyWaitReceivePortEx+0xc
00a0ff80 77e56c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4
00a0ff88 77e56a3b RPCRT4!RecvLotsaCallsWrapper+0xd
00a0ffa8 77e56c0a RPCRT4!BaseCachedThreadRoutine+0×79
00a0ffb4 7c80b683 RPCRT4!ThreadStartRoutine+0×1a
00a0ffec 00000000 kernel32!BaseThreadStart+0×37

In system calls, if (for example as above call stack)
NtReplyWaitReceivePortEx calls ntdll!KiFastSystemCall (offset
SharedUserData!SystemCallStub (7ffe0300)), then why can't we see it in
the call stack chain?
From: Jochen Kalmbach [MVP] on 21 Sep 2009 06:29
Hi rotor!

> ChildEBP RetAddr
> a5a2ac64 80502d26 nt!KiSwapContext+0x2f
> a5a2ac70 804faf20 nt!KiSwapThread+0x8a
> a5a2ac98 805a4d6c nt!KeWaitForSingleObject+0x1c2
> a5a2ad48 8054086c nt!NtReplyWaitReceivePortEx+0x3dc
> a5a2ad48 7c91eb94 nt!KiFastCallEntry+0xfc
> 00a0fe18 7c91e399 ntdll!KiFastSystemCallRet
> 00a0fe1c 77e56703 ntdll!NtReplyWaitReceivePortEx+0xc
> 00a0ff80 77e56c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4
> 00a0ff88 77e56a3b RPCRT4!RecvLotsaCallsWrapper+0xd
> 00a0ffa8 77e56c0a RPCRT4!BaseCachedThreadRoutine+0�79
> 00a0ffb4 7c80b683 RPCRT4!ThreadStartRoutine+0�1a
> 00a0ffec 00000000 kernel32!BaseThreadStart+0�37
>
> In system calls, if (for example as above call stack)
> NtReplyWaitReceivePortEx calls ntdll!KiFastSystemCall (offset
> SharedUserData!SystemCallStub (7ffe0300)), then why can't we see it in
> the call stack chain?

What callstack do you expect?
This is a RPC worker-thread; an waits for data... so you really see the
complete callstack ;)

Greetings
Jochen
From: rotor cli on 21 Sep 2009 14:47
On 21 Eylül, 13:29, "Jochen Kalmbach [MVP]" <nospam-
Jochen.Kalmb...(a)holzma.de> wrote:
> Hi rotor!
>
>
>
> > ChildEBP RetAddr
> > a5a2ac64 80502d26 nt!KiSwapContext+0x2f
> > a5a2ac70 804faf20 nt!KiSwapThread+0x8a
> > a5a2ac98 805a4d6c nt!KeWaitForSingleObject+0x1c2
> > a5a2ad48 8054086c nt!NtReplyWaitReceivePortEx+0x3dc
> > a5a2ad48 7c91eb94 nt!KiFastCallEntry+0xfc
> > 00a0fe18 7c91e399 ntdll!KiFastSystemCallRet
> > 00a0fe1c 77e56703 ntdll!NtReplyWaitReceivePortEx+0xc
> > 00a0ff80 77e56c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4
> > 00a0ff88 77e56a3b RPCRT4!RecvLotsaCallsWrapper+0xd
> > 00a0ffa8 77e56c0a RPCRT4!BaseCachedThreadRoutine+0×79
> > 00a0ffb4 7c80b683 RPCRT4!ThreadStartRoutine+0×1a
> > 00a0ffec 00000000 kernel32!BaseThreadStart+0×37
>
> > In system calls, if (for example as above call stack)
> > NtReplyWaitReceivePortEx calls ntdll!KiFastSystemCall (offset
> > SharedUserData!SystemCallStub (7ffe0300)), then why can't we see it in
> > the call stack chain?
>
> What callstack do you expect?
> This is a RPC worker-thread; an waits for data... so you really see the
> complete callstack ;)
>
> Greetings
>    Jochen

0012fdf8 7c90d85c 7c8023ed 00000000 0012fe2c ntdll!KiFastSystemCallRet
0012fdfc 7c8023ed 00000000 0012fe2c 0012ff54 ntdll!NtDelayExecution
+0xc
0012fe54 7c802451 0036ee80 00000000 0012ff54 kernel32!SleepEx+0x61
0012fe64 004308a9 0036ee80 a0f63080 01c63442 kernel32!Sleep+0xf
0012ff54 00432342 00000001 003336e8 003337c8 DeadLockDemo!wmain+0xd9
[c:\tests\deadlockdemo\deadlockdemo.cpp @ 154]
0012ffb8 004320fd 0012fff0 7c816d4f a0f63080 DeadLockDemo!
__tmainCRTStartup+0x232
[f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c @ 318]
0012ffc0 7c816d4f a0f63080 01c63442 7ffdd000 DeadLockDemo!
wmainCRTStartup+0xd
[f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c @ 187]
0012fff0 00000000 0042e5aa 00000000 78746341 kernel32!BaseProcessStart
+0x23

I expect to see ntdll!KiFastSystemCall before ntdll!
KiFastSystemCallRet.
I am asking about that. Thanks.
From: Pavel A. on 21 Sep 2009 14:55

"rotor cli" <rotorcli(a)gmail.com> wrote in message
news:9f4448ea-245d-4319-bfcb-d3c63cf9368d(a)d34g2000vbm.googlegroups.com...
> 1: kd> kL
> ChildEBP RetAddr
> a5a2ac64 80502d26 nt!KiSwapContext+0x2f
> a5a2ac70 804faf20 nt!KiSwapThread+0x8a
> a5a2ac98 805a4d6c nt!KeWaitForSingleObject+0x1c2
> a5a2ad48 8054086c nt!NtReplyWaitReceivePortEx+0x3dc
> a5a2ad48 7c91eb94 nt!KiFastCallEntry+0xfc
> 00a0fe18 7c91e399 ntdll!KiFastSystemCallRet
> 00a0fe1c 77e56703 ntdll!NtReplyWaitReceivePortEx+0xc
> 00a0ff80 77e56c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4
> 00a0ff88 77e56a3b RPCRT4!RecvLotsaCallsWrapper+0xd
> 00a0ffa8 77e56c0a RPCRT4!BaseCachedThreadRoutine+0�79
> 00a0ffb4 7c80b683 RPCRT4!ThreadStartRoutine+0�1a
> 00a0ffec 00000000 kernel32!BaseThreadStart+0�37
>
> In system calls, if (for example as above call stack)
> NtReplyWaitReceivePortEx calls ntdll!KiFastSystemCall (offset
> SharedUserData!SystemCallStub (7ffe0300)), then why can't we see it in
> the call stack chain?

That's because what is pushed onto the stack is the return address
and not the call address. KiFastSystemCallRet apparently is the address
where these kernel calls return.

--pa


From: rotor cli on 21 Sep 2009 16:00
On 21 Eylül, 21:55, "Pavel A." <pave...(a)12fastmail34.fm> wrote:
> "rotor cli" <rotor...(a)gmail.com> wrote in message
>
> news:9f4448ea-245d-4319-bfcb-d3c63cf9368d(a)d34g2000vbm.googlegroups.com...
>
>
>
> > 1: kd> kL
> > ChildEBP RetAddr
> > a5a2ac64 80502d26 nt!KiSwapContext+0x2f
> > a5a2ac70 804faf20 nt!KiSwapThread+0x8a
> > a5a2ac98 805a4d6c nt!KeWaitForSingleObject+0x1c2
> > a5a2ad48 8054086c nt!NtReplyWaitReceivePortEx+0x3dc
> > a5a2ad48 7c91eb94 nt!KiFastCallEntry+0xfc
> > 00a0fe18 7c91e399 ntdll!KiFastSystemCallRet
> > 00a0fe1c 77e56703 ntdll!NtReplyWaitReceivePortEx+0xc
> > 00a0ff80 77e56c22 RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0xf4
> > 00a0ff88 77e56a3b RPCRT4!RecvLotsaCallsWrapper+0xd
> > 00a0ffa8 77e56c0a RPCRT4!BaseCachedThreadRoutine+0×79
> > 00a0ffb4 7c80b683 RPCRT4!ThreadStartRoutine+0×1a
> > 00a0ffec 00000000 kernel32!BaseThreadStart+0×37
>
> > In system calls, if (for example as above call stack)
> > NtReplyWaitReceivePortEx calls ntdll!KiFastSystemCall (offset
> > SharedUserData!SystemCallStub (7ffe0300)), then why can't we see it in
> > the call stack chain?
>
> That's because what is pushed onto the stack is the return address
> and not the call address.  KiFastSystemCallRet apparently is the address
> where these kernel calls return.
>
> --pa

Yes I searched and found that:
0:001> u poi(0x7ffe0300)
ntdll!KiFastSystemCall:
7c82ed50 8bd4 mov edx,esp
7c82ed52 0f34 sysenter
ntdll!KiFastSystemCallRet:
7c82ed54 c3 ret

This is intersting. So the last ret indicates calling ntdll!
KiFastSystemCallRet. And windbg sees that and it doesn't show
KiFastSystemCall. Right?
I have never seen such a thing . Can you please give me some more
information about how it is so? Is it related to sysenter?

 |  Next  |  Last
Pages: 1 2
Prev: IOCTL_DISK_DELETE_DRIVE_LAYOUT
Next: How to debug Explorer crash on logoff