APC debugging

NTDEV
1

Hi all,

I got KiDeliverApc in the stack and the driver waits forever for that APC delivery. I would like to find out the target of the APC and ideally the process that is supposed to get it. Here’s a clean stack:

nt!KiSwapContext
nt!KiSwapThread
nt!KeWaitForSingleObject
nt!KiSuspendThread
nt!KiDeliverApc
hal!HalpApcInterrupt

mydriver!SyscallDispatch

nt!IopfCallDriver
nt!IopSynchronousServiceTail
nt!IopXxxControlFile
nt!NtDeviceIoControlFile
nt!KiFastCallEntry
ntdll!KiFastSystemCallRet

And here’s the _KAPC_STATE for this thread:

0: kd> dt -b nt!_KTHREAD 8a316ca0
…
+0x034 ApcState : _KAPC_STATE
+0x000 ApcListHead :
[00] _LIST_ENTRY [0x8a316cd4 - 0x8a316cd4]
+0x000 Flink : 0x8a316cd4
+0x004 Blink : 0x8a316cd4
[01] [0x8a316cdc - 0x8a316cdc]
+0x000 Flink : 0x8a316cdc
+0x004 Blink : 0x8a316cdc
+0x010 Process : 0x8a30eaa8
+0x014 KernelApcInProgress : 0x1 ‘’
+0x015 KernelApcPending : 0 ‘’
+0x016 UserApcPending : 0 ‘’

My guess is that the thread is preempted for a kernel APC and I could disable it with KeEnterGuardedRegion. But before that, it would be great to find out the cause.

Regards,
Calin

2

That looks to me like the thread has been suspended for some reason (i.e.
someone called SuspendThread). You need to figure out who suspended it and
why they’re not resuming it, which can be tricky of course.

Any A/V products running on the system?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Calin Iaru” wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I got KiDeliverApc in the stack and the driver waits forever for that APC
> delivery. I would like to find out the target of the APC and ideally the
> process that is supposed to get it. Here’s a clean stack:
>
> nt!KiSwapContext
> nt!KiSwapThread
> nt!KeWaitForSingleObject
> nt!KiSuspendThread
> nt!KiDeliverApc
> hal!HalpApcInterrupt
>
> mydriver!SyscallDispatch
>
> nt!IopfCallDriver
> nt!IopSynchronousServiceTail
> nt!IopXxxControlFile
> nt!NtDeviceIoControlFile
> nt!KiFastCallEntry
> ntdll!KiFastSystemCallRet
>
>
> And here’s the _KAPC_STATE for this thread:
>
> 0: kd> dt -b nt!_KTHREAD 8a316ca0
> …
> +0x034 ApcState : _KAPC_STATE
> +0x000 ApcListHead :
> [00] _LIST_ENTRY [0x8a316cd4 - 0x8a316cd4]
> +0x000 Flink : 0x8a316cd4
> +0x004 Blink : 0x8a316cd4
> [01] [0x8a316cdc - 0x8a316cdc]
> +0x000 Flink : 0x8a316cdc
> +0x004 Blink : 0x8a316cdc
> +0x010 Process : 0x8a30eaa8
> +0x014 KernelApcInProgress : 0x1 ‘’
> +0x015 KernelApcPending : 0 ‘’
> +0x016 UserApcPending : 0 ‘’
>
> My guess is that the thread is preempted for a kernel APC and I could
> disable it with KeEnterGuardedRegion. But before that, it would be great
> to find out the cause.
>
> Regards,
> Calin
>
>
>
>

3

Hi Scott,

no, there’s no A/V. The application is ST. I will see what can be done next time. In the meantime, I pushed it into verifier with Enable IRQL.

Regards,
Calin

----- Original Message ----
From: Scott Noone
To: Windows System Software Devs Interest List
Sent: Tue, May 18, 2010 4:48:58 PM
Subject: Re:[ntdev] APC debugging

That looks to me like the thread has been suspended for some reason (i.e. someone called SuspendThread). You need to figure out who suspended it and why they’re not resuming it, which can be tricky of course.

Any A/V products running on the system?

-scott

– Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Calin Iaru” wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I got KiDeliverApc in the stack and the driver waits forever for that APC delivery. I would like to find out the target of the APC and ideally the process that is supposed to get it. Here’s a clean stack:
>
> nt!KiSwapContext
> nt!KiSwapThread
> nt!KeWaitForSingleObject
> nt!KiSuspendThread
> nt!KiDeliverApc
> hal!HalpApcInterrupt
>
> mydriver!SyscallDispatch
>
> nt!IopfCallDriver
> nt!IopSynchronousServiceTail
> nt!IopXxxControlFile
> nt!NtDeviceIoControlFile
> nt!KiFastCallEntry
> ntdll!KiFastSystemCallRet
>
>
> And here’s the _KAPC_STATE for this thread:
>
> 0: kd> dt -b nt!_KTHREAD 8a316ca0
> …
> +0x034 ApcState : _KAPC_STATE
> +0x000 ApcListHead :
> [00] _LIST_ENTRY [0x8a316cd4 - 0x8a316cd4]
> +0x000 Flink : 0x8a316cd4
> +0x004 Blink : 0x8a316cd4
> [01] [0x8a316cdc - 0x8a316cdc]
> +0x000 Flink : 0x8a316cdc
> +0x004 Blink : 0x8a316cdc
> +0x010 Process : 0x8a30eaa8
> +0x014 KernelApcInProgress : 0x1 ‘’
> +0x015 KernelApcPending : 0 ‘’
> +0x016 UserApcPending : 0 ‘’
>
> My guess is that the thread is preempted for a kernel APC and I could disable it with KeEnterGuardedRegion. But before that, it would be great to find out the cause.
>
> Regards,
> Calin
>
>
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Are you calling SuspendThread in your usermode application? Note that using this function is a sure mistake.

5

Hi,

I am doing debugging like this:
User Mode:
call DebugBreak()
Kernel Debugging:
the debugger wakes up
activate driver breakpoint
g
I will see if this happens again, tomorrow. Other than that, there’s nothing I can think of.

Calin

----- Original Message ----
From: “xxxxx@broadcom.com”
To: Windows System Software Devs Interest List
Sent: Tue, May 18, 2010 7:32:45 PM
Subject: RE:[ntdev] APC debugging

Are you calling SuspendThread in your usermode application? Note that using this function is a sure mistake.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer