help with bug-check KERNEL_APC_PENDING_DURING_EXIT in a mini-filter

NTFSD
1

I have a mini-filter driver, which seems to cause this bug-check when I keep
it running for a while. The bug-check does not happen when its not running
(so obviously it is due to my driver).

The bug check is due a kernel mode APC still pending on a thread that was
exiting (due to call to NtTerminateProcess as in the stack below).

From the bug check Arg1(8a3a1304) and looking around nt!PspExitThread where
KeBugCheckEx was called, I was able to get that APC object as below:

1: kd> dt nt!_KAPC 8a3a1304-0xc
+0x000 Type : 18
+0x002 Size : 48
+0x004 Spare0 : 0
+0x008 Thread : 0x89ec8508 _KTHREAD
+0x00c ApcListEntry : _LIST_ENTRY [0x8a3a1304 - 0x8a3a1304]
+0x014 KernelRoutine : 0x805d104e void nt!PsExitSpecialApc+0
+0x018 RundownRoutine : 0x805f177e void nt!ExFreeCallBack+0
+0x01c NormalRoutine : 0x805d107a void nt!PspExitNormalApc+0
+0x020 NormalContext : (null)
+0x024 SystemArgument1 : 0x8a3a12f8
+0x028 SystemArgument2 : (null)
+0x02c ApcStateIndex : 0 ''
+0x02d ApcMode : 0 ''
+0x02e Inserted : 0 ''

From this info, can anyone suggest the probable cause of this bug-check due
to a mini-filter driver?

I had a feeling that this bugcheck is related to improper returning of
FLT_PREOP_CALLBACK_STATUS(or POST OP_CALLBACK STATUS).

I have done a several review of my pre-op and post-op routines and nothing
sticks out.

Thanks
Chandra

1: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

KERNEL_APC_PENDING_DURING_EXIT (20)
The key data item is the thread's APC disable count.
If this is non-zero, then this is the source of the problem.
The APC disable count is decremented each time a driver calls
KeEnterCriticalRegion, KeInitializeMutex, or FsRtlEnterFileSystem. The APC
disable count is incremented each time a driver calls KeLeaveCriticalRegion,
KeReleaseMutex, or FsRtlExitFileSystem. Since these calls should always be
in
pairs, this value should be zero when a thread exits. A negative value
indicates that a driver has disabled APC calls without re-enabling them. A
positive value indicates that the reverse is true.
If you ever see this error, be very suspicious of all drivers installed on
the
machine -- especially unusual or non-standard drivers. Third party file
system redirectors are especially suspicious since they do not generally
receive the heavy duty testing that NTFS, FAT, RDR, etc receive.
This current IRQL should also be 0. If it is not, that a driver's
cancelation routine can cause this bugcheck by returning at an elevated
IRQL. Always attempt to note what you were doing/closing at the
time of the crash, and note all of the installed drivers at the time of
the crash. This symptom is usually a severe bug in a third party
driver.
Arguments:
Arg1: 8a3a1304, The address of the APC found pending during exit.
Arg2: ffffffff, The thread's APC disable count
Arg3: 00000000, The current IRQL
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x20_KAPC_NEGATIVE

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: imapi.exe

LAST_CONTROL_TRANSFER: from 804f8cb1 to 8052a834

STACK_TEXT:
a7f75824 804f8cb1 00000003 a7f75b80 00000000
nt!RtlpBreakWithStatusInstruction
a7f75870 804f989c 00000003 8a3a1304 89ec8508 nt!KiBugCheckDebugBreak+0x19
a7f75c50 804f9deb 00000020 8a3a1304 ffffffff nt!KeBugCheck2+0x574
a7f75c70 805d0fc9 00000020 8a3a1304 ffffffff nt!KeBugCheckEx+0x1b
a7f75d08 805d1150 00000000 89ec8508 00000000 nt!PspExitThread+0x65d
a7f75d28 805d132b 89ec8508 00000000 a7f75d64
nt!PspTerminateThreadByPointer+0x52
a7f75d54 8054086c 00000000 00000000 0093ff64 nt!NtTerminateProcess+0x105
a7f75d54 7c90eb94 00000000 00000000 0093ff64 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0093ff64 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!PspExitThread+65d
805d0fc9 e896c8f2ff call nt!KeTerminateThread (804fd864)

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!PspExitThread+65d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e53f9d

FAILURE_BUCKET_ID: 0x20_KAPC_NEGATIVE_nt!PspExitThread+65d

BUCKET_ID: 0x20_KAPC_NEGATIVE_nt!PspExitThread+65d

Followup: MachineOwner

2

This bug check has nothing to do with the APC you found. It has to do
with the fact that something has failed to call KeLeaveCriticalRegion
(or the FsRtl version that is a #define to it - FsRtlExitFileSystem.)
The problem is that the free build of the OS only reports this at the
time the thread terminates - there is nothing available at that point to
ease debugging this particular problem (it could have happened 3 days
prior.) If you run the checked OS image, it will do this check on each
system call (which doesn’t help for system work threads, but works well
for user mode threads.)

Does your code call KeEnterCriticalRegion anywhere? If so, you have an
exit condition that failed to call KeLeaveCriticalRegion.

Tony

OSR

3

Thanks Tony for the reply.

Yes, I am using KeEnter/LeaveCriticalRegion for acquiring and releasing an
ERESOURCE and there is a case I found where call to KeLeaveCriticalRegion
was skipped.

After making this fix I am not seeing this bug check after leaving the
system up for hours now. Earlier it used to show in about 10-20 minutes.

Chandra

On Sun, Sep 28, 2008 at 12:30 AM, Tony Mason wrote:

> This bug check has nothing to do with the APC you found. It has to do
> with the fact that something has failed to call KeLeaveCriticalRegion (or
> the FsRtl version that is a #define to it ? FsRtlExitFileSystem.) The
> problem is that the free build of the OS only reports this at the time the
> thread terminates ? there is nothing available at that point to ease
> debugging this particular problem (it could have happened 3 days prior.) If
> you run the checked OS image, it will do this check on each system call
> (which doesn’t help for system work threads, but works well for user mode
> threads.)
>
>
>
> Does your code call KeEnterCriticalRegion anywhere? If so, you have an exit
> condition that failed to call KeLeaveCriticalRegion.
>
>
>
> Tony
>
> OSR
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>