366.7 KB - Evernote

APCTEST - New thread K APC list empty: 1
APCTEST - New thread U APC pending: 0
APCTEST - New thread U APC list empty: 1
APCTEST - APC INT: 0 no APC int
*** No APC delivery trace afterwards, b/c no APC int.
APCTEST - SWAP CONTEXT trace
APCTEST - Current IRQL: 0x1b
APCTEST - Current thread: 0X84D689F0
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: 0X84F62D78
APCTEST - New thread K APC pending: 0
APCTEST - New thread K APC list empty: 1
APCTEST - New thread U APC pending: 0
APCTEST - New thread U APC list empty: 1
APCTEST - APC INT: 0
[...]
We know that:
• nt!KiInsertQueueApc is called when the IRQL is already DISPATCH, so the APC interrupt
cannot be serviced before we lower the IRQL to PASSIVE.
• We lower the IRQL to passive after having set the hooks, so we cannot miss the APC
interrupt
• The call to nt!SwapContext cannot have occurred while nt!KiInsertQueueApc was in the
process of queuing the APC, i. e. before it raised the APC interrupt, because we called
nt!KiInsertQueueApc at DISPATCH, so no context switch can occur inside it. Besides, even if
we did not set the IRQL at DISPATCH, nt!KeInsertQueueApc sets it to profile (0x1b) before
calling nt!KiInsertQueueApc.
The explanation may be that nt!KiInsertQueueApc found SpecialApcDisable set. When this happens,
the function does not raise the APC interrupt, although it sets KernelApcPending, which is the
situation in the trace above.
But who then set SpecialApcDisable? Possibly, the code handling an hardware interrupt which
occurred while the test was in progress. Such interrupts were not masked by the DISPATCH IRQL.
38