366.7 KB - Evernote

This trace shows that the now current thread is indeed the same that nt!SwapContext was about to
resume before, and confirms once more that this thread has no pending APCs of any kind.
Thus, we can see that this APC interrupt really is a spurious one: it occurred because it was pending,
but occurred in the wrong thread, so it is useless. It is also harmless, because nt!KiDeliverApc returns
without causing any more trouble.
The remainder of the trace shows that nt!SwapContext is called to resume the original thread, which
still has its pending APCs, then, even though there is no outstanding APC interrupt, nt!KiDeliverApc
gets called and finally delivers our APC. This is confirmed by the fact that we see the trace from the
kernel routine:
APCTEST - SWAP CONTEXT trace
APCTEST - Current IRQL: 0x1b
APCTEST - Current thread: 0X84CBB460
APCTEST - Current thread K APC pending: 0
APCTEST - Current thread K APC list empty: 1
APCTEST - Current thread U APC pending: 0
APCTEST - Current thread U APC list empty: 1
APCTEST - New thread: 0X851D2030
APCTEST - New thread K APC pending: 1
APCTEST - New thread K APC list empty: 0
APCTEST - New thread U APC pending: 0
APCTEST - New thread U APC list empty: 1
APCTEST - APC INT: 0
APCTEST - DELIVER APC trace
APCTEST - Current IRQL: 0x1
APCTEST - Caller address: 0X81BB42F7
APCTEST - Trap frame: 00000000
APCTEST - Reserved: 00000000
APCTEST - PreviousMode: 0
APCTEST - Thread: 0X851D2030
APCTEST - Thread K APC pending: 1
APCTEST - Thread K APC list empty: 0
APCTEST - Thread U APC pending: 0
APCTEST - Thread U APC list empty: 1
APCTEST - KERNEL ROUTINE trace
APCTEST - Thread: 0X851D2030
APCTEST - Thread K APC pending: 0
APCTEST - Thread K APC list empty: 1
APCTEST - Thread U APC pending: 0
13