Re[2]: INVALID_WORK_QUEUE_ITEM Bsod in using FltQueueGenericWorkItem

Am I missing where you set pWorkItem to pFltWorkItem? If this is your
actual code, I don’t think your would ever call FltFreeGenericWorkItem
in the first place due to your checks.

Can you post the code which allocates the work item? From the crash
information, your worker routine has yet to be called which leads me to
believe it is being corrupted, or zero’d, prior to the worker routine
being invoked.

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 11:24:24 PM
Subject: RE:[ntfsd] INVALID_WORK_QUEUE_ITEM Bsod in using
FltQueueGenericWorkItem

>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
>fffff88001043ed0 488bc4 mov rax,rsp<br>&gt;<br>&gt;FAULTING_IP:<br>&gt;fltmgr!FltpProcessGenericWorkItem+0<br>&gt;fffff88001043ed0 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 <br>&gt;fffffa8001c51c88 fffff80002a335f8 fffff80002a335a0 : nt!KeBugCheckEx
>fffff88002f88bc0 fffff8000289b9d9 : fffff88001043ed0 <br>&gt;fffff88001043ed0 fffffa8000cd7b60 0000000000000000 : nt! ??
>::FNODOBFM::string'+0x47c8c<br>&gt;fffff88002f88c70 fffff80002b2d12a : 0000000000000000
>fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : <br>&gt;nt!ExpWorkerThread+0xe9<br>&gt;fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80
>fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : <br>&gt;nt!PspSystemThreadStartup+0x5a<br>&gt;fffff88002f88d40 0000000000000000 : 0000000000000000
>0000000000000000 0000000000000000 0000000000000000 : <br>&gt;nt!KxStartSystemThread+0x16<br>&gt;<br>&gt;<br>&gt;STACK_COMMAND: kb<br>&gt;<br>&gt;FOLLOWUP_IP:<br>&gt;fltmgr!FltpProcessGenericWorkItem+0<br>&gt;fffff88001043ed0 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 <br>&gt;fffffa8001c51c88 fffff80002a335f8 fffff80002a335a0 : nt!KeBugCheckEx
>01 fffff88002f88bc0 fffff8000289b9d9 : fffff88001043ed0 <br>&gt;fffff88001043ed0 fffffa8000cd7b60 0000000000000000 : nt! ??
>::FNODOBFM::string'+0x47c8c<br>&gt;02 fffff88002f88c70 fffff80002b2d12a : 0000000000000000
>fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : <br>&gt;nt!ExpWorkerThread+0xe9<br>&gt;03 fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80
>fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : <br>&gt;nt!PspSystemThreadStartup+0x5a<br>&gt;04 fffff88002f88d40 0000000000000000 : 0000000000000000
>0000000000000000 0000000000000000 00000000`00000000 :
>nt!KxStartSystemThread+0x16
>
>
>
>—
>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:>

This isn’t being called yet - the queue is corrupted. Your code to allocate and queue the work item is more interesting.

Your code below seems to be broken as well, despite not being invoked. Why do you have both the parameter work item and the local one?

If this is representative of your code, it sure looks like it’s a logic bug.

Tony

On Sep 12, 2016, at 10:24 PM, “xxxxx@gmail.com” wrote:
>
> 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
> fffff88001043ed0 488bc4 mov rax,rsp<br>&gt; <br>&gt; FAULTING_IP: <br>&gt; fltmgr!FltpProcessGenericWorkItem+0<br>&gt; fffff88001043ed0 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<br>&gt; fffff88002f88c70 fffff80002b2d12a : 0000000000000000 fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : nt!ExpWorkerThread+0xe9<br>&gt; fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80 fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : nt!PspSystemThreadStartup+0x5a<br>&gt; fffff88002f88d40 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KxStartSystemThread+0x16<br>&gt; <br>&gt; <br>&gt; STACK_COMMAND: kb<br>&gt; <br>&gt; FOLLOWUP_IP: <br>&gt; fltmgr!FltpProcessGenericWorkItem+0<br>&gt; fffff88001043ed0 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<br>&gt; 02 fffff88002f88c70 fffff80002b2d12a : 0000000000000000 fffffa8000cd7b60 0000000000000080 fffffa8000cc9040 : nt!ExpWorkerThread+0xe9<br>&gt; 03 fffff88002f88d00 fffff8000286cd86 : fffff80002a08e80 fffffa8000cd7b60 fffffa8000cd7040 0000000000000000 : nt!PspSystemThreadStartup+0x5a<br>&gt; 04 fffff88002f88d40 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : nt!KxStartSystemThread+0x16
>
>
>
> —
> 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:>