366.7 KB - Evernote

We are now going to analyze a trace captured with it. It begins with the APC being initialized, then the
first captured event we see is the call to SwapContext:
APCTEST - Thr: 0X851D2030; APC initialized: 0X850F7A9C
APCTEST - SWAP CONTEXT trace
APCTEST - Current IRQL: 0x1b
APCTEST - Current thread: 0X851D2030
APCTEST - Current thread K APC pending: 1
APCTEST - Current thread K APC list empty: 0
APCTEST - Current thread U APC pending: 0
APCTEST - Current thread U APC list empty: 1
APCTEST - New thread: 0X84CBB460
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: 1
The SwapContext trace shows the IRQL at which the function runs (0x1b), then some data on the
current thread (the one about to be suspended). First of all we see that this thread is indeed the
same one which initialized the APC (0X851D2030), then we see that the KernelApcPending flag for it
is set to 1 and that its kernel APC list is not empty (this is shown by the 0, i. e. false, value on the
corresponding line).
Then we see that the new thread (0X84CBB460), has KernelApcPending clear, an empty kernel APC
list and the same goes for the user APC data. This tells us that this thread has no APC to deliver.
Finally, the line labeled “APC INT” shows the status of the APC interrupt flag at the time of the trace: it
is set, meaning that the APC interrupt resulting from nt!KeInsertQueueApc is pending.
After the swap context we see a call to nt!KiDeliverApc traced:
APCTEST - DELIVER APC trace
APCTEST - Current IRQL: 0x1
APCTEST - Caller address: 0X81BB42F7
APCTEST - Trap frame: 00000000
APCTEST - Reserved: 00000000
APCTEST - PreviousMode: 0
APCTEST - Thread: 0X84CBB460
APCTEST - Thread K APC pending: 0
APCTEST - Thread K APC list empty: 1
APCTEST - Thread U APC pending: 0
APCTEST - Thread U APC list empty: 1
12