Hey all,
I’m working on a set of filter drivers - registry callback, FS filter and WFP callout.
In all of these I dont create IRPs of my own and neither I call IoCompleteRequest.
I got a MULTIPLE_IRP_COMPLETE_REQUESTS bugcheck on windows 7 64bit after a long time running the drivers.
How can I determine if my drivers have anything to do with it?
Following is the bugcheck analysis:
MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: fffffa80bae82bd0, Address of the IRP
Arg2: 0000000000000eae
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
IRP_ADDRESS: fffffa80bae82bd0
FOLLOWUP_IP:
hidusb!HumCallUSB+2c1
fffff880`0cae23f5 3bde cmp ebx,esi
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x44
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff800038628c0 to fffff80003879bc0
STACK_TEXT:
fffff880035cb908 fffff800
038628c0 : 0000000000000044 fffffa80
bae82bd0 0000000000000eae 00000000
00000000 : nt!KeBugCheckEx
fffff880035cb910 fffff880
0cae23f5 : 0000000000000103 00000000
00000103 fffffa80bae82e00 fffffa80
b9f85400 : nt! ?? ::FNODOBFM::string'+0x413f2 fffff880
035cba00 fffff8800cae7768 : fffffa80
84eae438 0000000000000028 fffffa80
84eae060 00000000000007ff : hidusb!HumCallUSB+0x2c1 fffff880
035cbaa0 fffff8800cae06d6 : fffffa80
84eae060 0000000000000000 fffffa80
ba99d010 fffff80003a1f2d8 : hidusb!HumAbortPendingRequests+0x74 fffff880
035cbae0 fffff80003b70c93 : fffffa80
84eae060 0000000000000003 fffff800
03a1f2d8 fffffa80036ef660 : hidusb!HumResetWorkItem+0x92 fffff880
035cbb40 fffff80003883261 : fffff800
03a1f200 fffff80003b70c01 fffffa80
036ef600 fffff80003a1f2d8 : nt!IopProcessWorkItem+0x23 fffff880
035cbb70 fffff80003b1573a : 00000000
00000000 fffffa80036ef660 00000000
00000080 fffffa80036dc9e0 : nt!ExpWorkerThread+0x111 fffff880
035cbc00 fffff8000386a8e6 : fffff880
033d7180 fffffa80036ef660 fffff880
033e1fc0 0000000000000000 : nt!PspSystemThreadStartup+0x5a fffff880
035cbc40 0000000000000000 : fffff880
035cc000 fffff880035c6000 fffff880
035cb750 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: hidusb!HumCallUSB+2c1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: hidusb
IMAGE_NAME: hidusb.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a665
FAILURE_BUCKET_ID: X64_0x44_hidusb!HumCallUSB+2c1
BUCKET_ID: X64_0x44_hidusb!HumCallUSB+2c1
Followup: MachineOwner
Thank you very much,
Daniel