INVALID_WORK_QUEUE_ITEM Bsod in using FltQueueGenericWorkItem

NTFSD
1

Hi,
I want to log file activities related with particular process.
I am using FltQueueGenericWorkItem for communicating with user mode in File pre-create,
FltQueueGenericWorkItem(
pWorkItem,
pFltTargetInstance,
QueueLogMessages,
DelayedWorkQueue,
pLogActivity
);
and in QueueLogMessages routine using FltSendMessage to communicating with
user mode but always getting BSOD with INVALID_WORK_QUEUE_ITEM.
Is there any better way of using thread pool in driver. I am new to file system development.

2

How are you allocating your workitem?

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 9/12/2016 8:25:49 AM
Subject: [ntfsd] INVALID_WORK_QUEUE_ITEM Bsod in using
FltQueueGenericWorkItem

>Hi,
> I want to log file activities related with particular process.
>I am using FltQueueGenericWorkItem for communicating with user mode in
>File pre-create,
> FltQueueGenericWorkItem(
> pWorkItem,
> pFltTargetInstance,
> QueueLogMessages,
> DelayedWorkQueue,
> pLogActivity
> );
>and in QueueLogMessages routine using FltSendMessage to communicating
>with
>user mode but always getting BSOD with INVALID_WORK_QUEUE_ITEM.
>Is there any better way of using thread pool in driver. I am new to
>file system development.
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

3

Hi Peter,
I am using FltAllocateGenericWorkItem for allocating work item.
Thanks

Babaloo

4

I’m assuming you reviewed the documentation on this bug check: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559300(v=vs.85).aspx

There is a LIST_ENTRY in the generic work item that is being corrupted. This could be due to an actual memory scribble over the list entry, or it could be due to you calling FltFreeGenericWorkItem prematurely - are you calling it in your work routine?

Have you run with verifier enabled on your driver? Do you have the “!analyze -v” output to share with us?

Tony
OSR

5

Hi Tony,
I do reviewed,
https://msdn.microsoft.com/en-us/library/windows/hardware/ff559300(v=vs.85).aspx

and I have called FltFreeGenericWorkItem in work routine only.

Below is my worker routine:

void
QueueLogMessages(
__in PFLT_GENERIC_WORKITEM pFltWorkItem,
__in PVOID pFltObject,
__in PVOID pvContext
)
{
LARGE_INTEGER Timeout;
ULONG ulReplyLength = 0;
PLOGACTIVITY pLogActivity = NULL;
PFLT_GENERIC_WORKITEM pWorkItem = NULL;
NTSTATUS ntStatus = STATUS_UNSUCCESSFUL;
USER_MODE_LOGACT_REPLY ServiceReply = {0};

if (PASSIVE_LEVEL != KeGetCurrentIrql())
{
return;
}

ulReplyLength = sizeof(ServiceReply);

pLogActivity = (PLOGACTIVITY) pvContext;
Timeout.QuadPart = DEFAULT_WAIT_TIME_OUT;

if ( (NULL == pFltObject) ||
(NULL == pFltWorkItem)
)
{
if (NULL != pWorkItem)
{
FltFreeGenericWorkItem(pWorkItem);
pWorkItem = NULL;
}
return;
}

ntStatus = FltSendMessage(
g_DrvObj.Filter,
&g_ScDrvPort_ProcLogs.ClientPort,
pLogActivity,
sizeof(LOGACTIVITY),
&ServiceReply,
&ulReplyLength,
&Timeout
);

if (NULL != pWorkItem)
{
FltFreeGenericWorkItem(pWorkItem);
pWorkItem = NULL;
}
}

Crash Dump Analysis:

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

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it’s flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: fffffa8001c51c88, The address of the queue entry whose flink/blink field is NULL
Arg2: fffff80002a335f8, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: fffff80002a335a0, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: fffff88001043ed0, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:

VIRTUAL_MACHINE: VirtualBox

SYSTEM_VERSION: 1.2

BIOS_DATE: 12/01/2006

BASEBOARD_PRODUCT: VirtualBox

BASEBOARD_VERSION: 1.2

BUGCHECK_P1: fffffa8001c51c88

BUGCHECK_P2: fffff80002a335f8

BUGCHECK_P3: fffff80002a335a0

BUGCHECK_P4: fffff88001043ed0

WORKER_ROUTINE:
fltmgr!FltpProcessGenericWorkItem+0
fffff880`01043ed0 488bc4 mov rax,rsp

FAULTING_IP:
fltmgr!FltpProcessGenericWorkItem+0
fffff880`01043ed0 488bc4 mov rax,rsp

WORK_ITEM: fffffa8001c51c88

CPU_COUNT: 1

CPU_MHZ: b4d

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

LAST_CONTROL_TRANSFER: from fffff8000290f27a to fffff8000288e840

STACK_TEXT:
fffff88002f88bb8 fffff8000290f27a : 0000000000000096 fffffa8001c51c88 fffff80002a335f8 fffff80002a335a0 : nt!KeBugCheckEx
fffff88002f88bc0 fffff8000289b9d9 : fffff88001043ed0 fffff88001043ed0 fffffa8000cd7b60 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x47c8c fffff88002f88c70 fffff80002b2d12a : 0000000000000000 fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : nt!ExpWorkerThread+0xe9 fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80 fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : nt!PspSystemThreadStartup+0x5a fffff88002f88d40 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
fltmgr!FltpProcessGenericWorkItem+0
fffff880`01043ed0 488bc4 mov rax,rsp

SYMBOL_NAME: fltmgr!FltpProcessGenericWorkItem+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: fltmgr

IMAGE_NAME: fltmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc11f

IMAGE_VERSION: 6.1.7600.16385

FAILURE_BUCKET_ID: X64_0x96_fltmgr!FltpProcessGenericWorkItem+0

BUCKET_ID: X64_0x96_fltmgr!FltpProcessGenericWorkItem+0

PRIMARY_PROBLEM_CLASS: X64_0x96_fltmgr!FltpProcessGenericWorkItem+0

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0x96_fltmgr!fltpprocessgenericworkitem+0

FAILURE_ID_HASH: {cec5adfb-98db-50ac-c6be-c8330fb3b04b}

Followup: MachineOwner

kd> kv

Child-SP RetAddr : Args to Child : Call Site

00 fffff88002f88bb8 fffff8000290f27a : 0000000000000096 fffffa8001c51c88 fffff80002a335f8 fffff80002a335a0 : nt!KeBugCheckEx
01 fffff88002f88bc0 fffff8000289b9d9 : fffff88001043ed0 fffff88001043ed0 fffffa8000cd7b60 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x47c8c 02 fffff88002f88c70 fffff80002b2d12a : 0000000000000000 fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : nt!ExpWorkerThread+0xe9 03 fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80 fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : nt!PspSystemThreadStartup+0x5a 04 fffff88002f88d40 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : nt!KxStartSystemThread+0x16

6

Enable Driver Verifier on your driver as well as FltMgr.sys and see if you get a better crash that is easier to debug.

-scott
OSR
@OSRDrivers