Problem using EVENT object in KMDF filter driver

NTDEV
1

I have a KMDF filter driver with a function that uses an EVENT object to
create an IRP. The pertinent lines of code are:

KEVENT event;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildSynchronousFsdRequest(IRP_MJ_WRITE, DEVICE_OBJ, writeBuffer,
17, 0, &event, &iosb);

When I call this function from one location within my code it works
properly and returns a valid irp with values for the EVENT returned as:

&event = 0xac1d3a50
event = 0x40000

When I call it from another location, however, it does not work (the system
crashes when trying to create the irp) and returns:

&event = 0x838fa91c
event = 0xcd040000

In trying to resolve this problem I realize that I am very confused about
EVENT objects. For starters does the code “KEVENT event” simply create a
pointer to hold the address of an event that is created when
KeInitializeEvent(&event, NotificationEvent, FALSE) is called? Can “event”
be initialized to NULL? Should the code “KEVENT event” be moved into a
header file so that it is only executed once and not every time the
function is called?

What do the two values “event = 0x40000” and “event = 0xcd040000” mean and
where are these values defined?

Can you tell me why my function fails in the later case?

Randy

2

Why don’t you check the definition of KEVENT in the header file? And read the KeInitializeEvent documentation?
Why do you think printing ‘event’ will bring any meaningful output?

3

Randy Lewis wrote:

Can “event” be initialized to NULL? Should the code “KEVENT event”
be moved into a header file so that it is only executed once and not
every time the function is called?

Should you learn the C programming language first?

4

> Should you learn the C programming language first?

Don’t you even start it - otherwise the whole thing will, again, “progress” to discussing the perceived “horrors” of C language; we will be told how great our life would be if we could write drivers and entire OSes in C#; etc,etc,etc. We already have a thread like that on “today’s menu”,don’t we…

Anton Bassov

1 Like
5

Thank you Anton for taking a stand against posting useless derogatory comments on this forum, which is intended to provide helpful commentary and discussion.

Randy

6

Alex,

I did read the MSDN documentation on KeInitializeEvent and “Using EVENT Objects” but I am still confused about what an EVENT object really is (is it a structure?). Perhaps your suggestion to look at the header file will help. And I think printing “event” did provide useful information, although I don’t know the significance of the difference between the values of 0x40000 and 0xcd040000. I do know that when the value of “event” is 0x40000 the function works and when it is 0xcd040000 the function doesn’t work. Can somebody explain the significance of the 0xcd0 appended to the front?

Randy

7

> Thank you Anton for taking a stand against posting useless derogatory comments on this forum, >which is intended to provide helpful commentary and discussion.

As I can see, apart from being “at odds” with C language some posters are obviously having some “issues” with comprehension…

Anton Bassov

8

An event is a kernel object and more precisely a dispatcher object. A dispatcher object can be used with KeWaitForMutexObject or KeWaitForMultipleObjects for synchronization purpose.

Access to the structure (internal data) of an object is reserved to the system. Corruption of the internal data of an object will most probably lead to a bugcheck.

The structure definition is present in some WDK headers because the compiler needs these informations when dealing with these objects but these informations are not there for you or for me.

Like every dispatcher object, the very first member of the _KEVENT structure is a _DISPATCHER_HEADER structure. You can display the definition of these structures within WinDbg using the following commands:

dt nt!_KEVENT
dt nt!_DISPATCHER_HEADER

When you have the address of an event structure, for instance 0x838fa91c:

dt nt!_KEVENT 0x838fa91c
dt nt!_DISPATCHER_HEADER 0x838fa91c

The watch window of WinDbg is probably more helpful.

Have a look at the following page titled “Introduction to Kernel Dispatcher Objects”:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff548068(v=vs.85).aspx

9

OK, to save you some troubles:

KEVENT is a structure.
KeInitializeEvent simply initializes the structure.
There is no function to destroy a KEVENT; it’s not using any secondary storage.
The KEVENT should stay valid (stay in the block/function scope or be allocated in non-paged pool) while it may be used by kernel functions. It would be an error to create an IRP with an event on the stack, and then return from the function before the IRP is completed.

10

Abdel,
Thank you for the helpful comments. I did discover, thanks to Alex Grig’s recommendation to look at the definition of EVENT in the header file, that it is a structure. Then the meaning of the values 0x40000 and 0xcd040000 for “event” became clear. They show that the event Type = 0, the Signalling state = 0, the size = 4 and the mystery value of 0xcd is “Reserved1”. The Reserved1 value is not very informative since it is not defined. I also noticed in the documentation for KeInitializeEvent that the storage for the event object should be in non-paged memory. I moved the storage allocation to the devices FILTER_EXTENSION structure and now the memory address for the event and the returned internal values are the same for the both the succeeded and failed cases. So I don’t think the problem is with the EVENT. That seems to leave only the DEVICE_OBJECT that is passed to the IRP creation function as being a likely candidate for my problems. I’ll have to compare the all internal values for this object for both cases to see if there is some difference that is causing the failure.

Randy

11

What do you mean by “failure”? What are you trying to do with the IRP and KEVENT?

12

On May 22, 2016, at 7:58 PM, xxxxx@gmail.com wrote:

Thank you for the helpful comments. I did discover, thanks to Alex Grig’s recommendation to look at the definition of EVENT in the header file, that it is a structure.

KEVENT, not EVENT. There is one very important difference between scheduler objects in user mode and scheduler objects in kernel mode that you need to understand, and which should make some of this clear. In user mode, when you create an event, the space for the structure is allocated by someone else in memory that you do not control. You are given a handle, which system routines can decode in order to find the structure. That ensures the opacity of the structure — you can’t see the contents because you don’t know where they are. In addition, you have to remember to clean up later.

In kernel mode, the memory is always allocated and owned by the driver. Instead of “creating” event, you are “initializing” an event, which is setting up the memory that you provided. The structure should still be considered opaque — in my decades of kernel programming, I don’t think I have ever needed to look inside s KEVENT structure — but it’s memory that you control.

I also noticed in the documentation for KeInitializeEvent that the storage for the event object should be in non-paged memory. I moved the storage allocation to the devices FILTER_EXTENSION structure and now the memory address for the event and the returned internal values are the same for the both the succeeded and failed cases.

I don’t think you ever told us that something was failing, did you?
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

Post the output of !analyze -v, stop guessing

Sent from my Windows 10 phone

From: xxxxx@gmail.commailto:xxxxx
Sent: Sunday, May 22, 2016 7:59 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver

Abdel,
Thank you for the helpful comments. I did discover, thanks to Alex Grig’s recommendation to look at the definition of EVENT in the header file, that it is a structure. Then the meaning of the values 0x40000 and 0xcd040000 for “event” became clear. They show that the event Type = 0, the Signalling state = 0, the size = 4 and the mystery value of 0xcd is “Reserved1”. The Reserved1 value is not very informative since it is not defined. I also noticed in the documentation for KeInitializeEvent that the storage for the event object should be in non-paged memory. I moved the storage allocation to the devices FILTER_EXTENSION structure and now the memory address for the event and the returned internal values are the same for the both the succeeded and failed cases. So I don’t think the problem is with the EVENT. That seems to leave only the DEVICE_OBJECT that is passed to the IRP creation function as being a likely candidate for my problems. I’ll have to compare the all internal values for this object for both cases to see if there is some difference that is causing the failure.

Randy

—
NTDEV is sponsored by OSR

Visit the list online at: http:

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:></http:></mailto:xxxxx></mailto:xxxxx>

14

Sigh.

Peter
OSR
@OSRDrivers

15

I know from the crash dump analysis that there is a problem with memory usage. The function in question (IoBuildSynchronousFsdRequest(IRP_MJ_WRITE, DEVICE_OBJ, writeBuffer,
17, 0, &event, &iosb)) succeeds when IRQL = 0 and fails (crashes the system with IRQL_NOT_LESS_OR_EQUAL) when IRQL = 2. I assumed that memory for one of the inputs was getting paged out so I moved all of them into the FILTER_EXTENSION for my DEVICE_OBJECT. I expected that to resolve the problem but it didn’t.

The following is the latest minidump output:

Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\052316-27234-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10586 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 10586.306.x86fre.th2_release_sec.160422-1850
Machine Name:
Kernel base = 0x8221b000 PsLoadedModuleList = 0x82421138
Debug session time: Mon May 23 09:41:45.815 2016 (UTC - 5:00)
System Uptime: 0 days 0:15:04.814
Loading Kernel Symbols
…
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {4, 2, 0, 8229d5ab}

Unable to load image \SystemRoot\System32\drivers\filter.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for filter.sys
*** ERROR: Module load completed but symbols could not be loaded for filter.sys
Probably caused by : filter.sys ( filter+3b00 )

Followup: MachineOwner

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 8229d5ab, address which referenced memory

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING: 10586.306.x86fre.th2_release_sec.160422-1850

SYSTEM_MANUFACTURER: TOSHIBA

SYSTEM_PRODUCT_NAME: Satellite A205

SYSTEM_VERSION: PSAF3U-0P900V

BIOS_VENDOR: Phoenix Technologies LTD

BIOS_VERSION: 1.70

BIOS_DATE: 11/06/2007

BASEBOARD_MANUFACTURER: Intel Corporation

BASEBOARD_PRODUCT: SANTA ROSA CRB

BASEBOARD_VERSION: Not Applicable

DUMP_TYPE: 2

BUGCHECK_P1: 4

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: ffffffff8229d5ab

READ_ADDRESS: 82444174: Unable to get MiVisibleState
00000004

CURRENT_IRQL: 2

FAULTING_IP:
nt!IopQueueThreadIrp+3b
8229d5ab 397804 cmp dword ptr [eax+4],edi

CPU_COUNT: 2

CPU_MHZ: 63c

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: f

CPU_STEPPING: d

CPU_MICROCODE: 6,f,d,0 (F,M,S,R) SIG: A4’00000000 (cache) A4’00000000 (init)

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

ANALYSIS_SESSION_HOST: DESKTOP-R0HPEF9

ANALYSIS_SESSION_TIME: 05-23-2016 11:03:36.0635

ANALYSIS_VERSION: 10.0.10586.567 x86fre

TRAP_FRAME: 838f65a8 – (.trap 0xffffffff838f65a8)
ErrCode = 00000000
eax=00000000 ebx=82456888 ecx=b1089de0 edx=82456900 esi=b1089df0 edi=82456814
eip=8229d5ab esp=838f661c ebp=838f662c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!IopQueueThreadIrp+0x3b:
8229d5ab 397804 cmp dword ptr [eax+4],edi ds:0023:00000004=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 82344e1a to 82332f0c

STACK_TEXT:
838f6500 82344e1a 0000000a 00000004 00000002 nt!KiBugCheck2
838f6500 8229d5ab 0000000a 00000004 00000002 nt!KiTrap0E+0x1ca
838f662c 8253303e 960a290c 960a28b0 838f6668 nt!IopQueueThreadIrp+0x3b
838f663c 82532fff 00000004 960a28b0 976c6504 nt!IopBuildSynchronousFsdRequest+0x34
838f6668 b5033b00 00000004 960a28b0 976c6504 nt!IoBuildSynchronousFsdRequest+0x23
WARNING: Stack unwind information not available. Following frames may be wrong.
838f66c0 b5034d34 000000f0 69e4e7d0 00000041 filter+0x3b00
838f66e0 b50316a9 b825f2e9 00000010 69e4e7d0 filter+0x4d34
838f6718 8680afc5 69e4e7d0 69f4e0c8 838f673c filter+0x16a9
838f6778 8680ab47 b350a198 96199ef0 ccdf0650 Wdf01000!FxRequestBase::CompleteSubmitted+0x1e5 [d:\th\minkernel\wdf\framework\shared\core\fxrequestbase.cpp @ 523]
838f6790 82311410 96199ef0 00df0650 011b1828 Wdf01000!FxIoTarget::_RequestCompletionRoutine+0xa7 [d:\th\minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 2448]
838f67b4 82299590 96199ef0 ccdf0650 b350a198 nt!IopUnloadSafeCompletion+0x3c
838f6818 86e110e2 96004f78 9618a608 00000010 nt!IopfCompleteRequest+0x240
838f6848 86e18ee9 00000011 00000000 96002edf HIDCLASS!HidpDistributeInterruptReport+0xdc
838f6884 82299590 00000000 96002db8 9618a608 HIDCLASS!HidpInterruptReadComplete+0x6b2d
838f68e8 8ee10868 8b8a3028 ccdab010 8b8a3bf0 nt!IopfCompleteRequest+0x240
838f6aac 8ee0ec64 ccdab010 8b8a3bf0 8ee0cc02 USBPORT!USBPORT_Core_iCompleteDoneTransfer+0x858
838f6ae0 8ee0ba4b 8b8a3bf0 30600802 8b8a3028 USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x204
838f6b1c 8ee0b89f 8b8a3028 8b8a3bf0 30600802 USBPORT!USBPORT_Core_UsbIocDpc_Worker+0x17b
838f6b68 8228c4f9 8b8a3bfc 8b8a3bf0 00000000 USBPORT!USBPORT_Xdpc_Worker_IocDpc+0x1df
838f6c20 8228c140 838f6c68 00000000 b115cb40 nt!KiExecuteAllDpcs+0x209
838f6d44 8234608c 00000000 00000000 00000000 nt!KiRetireDpcList+0xe0
838f6d48 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x38

STACK_COMMAND: kb

THREAD_SHA1_HASH_MOD_FUNC: b8d8e046d0f8e705d8162191d3afe8490b0a5364

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 69ed62acbd531ec5a3f80a5f65472a573b2e50e3

THREAD_SHA1_HASH_MOD: d0c8ebc4d3397884f0e77cd9d47f839605e0c795

FOLLOWUP_IP:
filter+3b00
b5033b00 8b15e07503b5 mov edx,dword ptr [filter+0x75e0 (b50375e0)]

FAULT_INSTR_CODE: 75e0158b

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: filter+3b00

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 57431600

BUCKET_ID_FUNC_OFFSET: 3b00

FAILURE_BUCKET_ID: AV_filter!Unknown_Function

BUCKET_ID: AV_filter!Unknown_Function

PRIMARY_PROBLEM_CLASS: AV_filter!Unknown_Function

TARGET_TIME: 2016-05-23T14:41:45.000Z

OSBUILD: 10586

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 784

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x86

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2016-04-22 23:03:31

BUILDDATESTAMP_STR: 160422-1850

BUILDLAB_STR: th2_release_sec

BUILDOSVER_STR: 10.0.10586.306.x86fre.th2_release_sec.160422-1850

ANALYSIS_SESSION_ELAPSED_TIME: 32e5

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_filter!unknown_function

FAILURE_ID_HASH: {f9f66cdc-c963-a425-c4cd-4e80361036a9}

Followup: MachineOwner

16

You can’t call IoBuildSynchronousFsdRequest at DISPATCH_LEVEL, the docs clearly say so. A completion routine can run at IRQL <= DISPATCH_LEVEL. You will want to use IoBuildAsynchronousFsdRequest or just roll your own IRP and format it yourself.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, May 23, 2016 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver

I know from the crash dump analysis that there is a problem with memory usage. The function in question (IoBuildSynchronousFsdRequest(IRP_MJ_WRITE, DEVICE_OBJ, writeBuffer, 17, 0, &event, &iosb)) succeeds when IRQL = 0 and fails (crashes the system with IRQL_NOT_LESS_OR_EQUAL) when IRQL = 2. I assumed that memory for one of the inputs was getting paged out so I moved all of them into the FILTER_EXTENSION for my DEVICE_OBJECT. I expected that to resolve the problem but it didn’t.

The following is the latest minidump output:

Microsoft (R) Windows Debugger Version 10.0.10586.567 X86 Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\052316-27234-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 10586 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 10586.306.x86fre.th2_release_sec.160422-1850
Machine Name:
Kernel base = 0x8221b000 PsLoadedModuleList = 0x82421138 Debug session time: Mon May 23 09:41:45.815 2016 (UTC - 5:00) System Uptime: 0 days 0:15:04.814 Loading Kernel Symbols …
…
…
Loading User Symbols
Loading unloaded module list
…
Bugcheck Analysis



Use !analyze -v to get detailed debugging information.

BugCheck A, {4, 2, 0, 8229d5ab}

Unable to load image \SystemRoot\System32\drivers\filter.sys, Win32 error 0n2
WARNING: Unable to verify timestamp for filter.sys
 ERROR: Module load completed but symbols could not be loaded for filter.sys Probably caused by : filter.sys ( filter+3b00 )

Followup: MachineOwner
---------

0: kd> !analyze -v
Bugcheck Analysis



IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 8229d5ab, address which referenced memory

Debugging Details:
------------------

DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING: 10586.306.x86fre.th2_release_sec.160422-1850

SYSTEM_MANUFACTURER: TOSHIBA

SYSTEM_PRODUCT_NAME: Satellite A205

SYSTEM_VERSION: PSAF3U-0P900V

BIOS_VENDOR: Phoenix Technologies LTD

BIOS_VERSION: 1.70

BIOS_DATE: 11/06/2007

BASEBOARD_MANUFACTURER: Intel Corporation

BASEBOARD_PRODUCT: SANTA ROSA CRB

BASEBOARD_VERSION: Not Applicable

DUMP_TYPE: 2

BUGCHECK_P1: 4

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: ffffffff8229d5ab

READ_ADDRESS: 82444174: Unable to get MiVisibleState
00000004

CURRENT_IRQL: 2

FAULTING_IP:
nt!IopQueueThreadIrp+3b
8229d5ab 397804 cmp dword ptr [eax+4],edi

CPU_COUNT: 2

CPU_MHZ: 63c

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: f

CPU_STEPPING: d

CPU_MICROCODE: 6,f,d,0 (F,M,S,R) SIG: A4’00000000 (cache) A4’00000000 (init)

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

ANALYSIS_SESSION_HOST: DESKTOP-R0HPEF9

ANALYSIS_SESSION_TIME: 05-23-2016 11:03:36.0635

ANALYSIS_VERSION: 10.0.10586.567 x86fre

TRAP_FRAME: 838f65a8 – (.trap 0xffffffff838f65a8) ErrCode = 00000000
eax=00000000 ebx=82456888 ecx=b1089de0 edx=82456900 esi=b1089df0 edi=82456814
eip=8229d5ab esp=838f661c ebp=838f662c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!IopQueueThreadIrp+0x3b:
8229d5ab 397804 cmp dword ptr [eax+4],edi ds:0023:00000004=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 82344e1a to 82332f0c

STACK_TEXT:
838f6500 82344e1a 0000000a 00000004 00000002 nt!KiBugCheck2
838f6500 8229d5ab 0000000a 00000004 00000002 nt!KiTrap0E+0x1ca 838f662c 8253303e 960a290c 960a28b0 838f6668 nt!IopQueueThreadIrp+0x3b 838f663c 82532fff 00000004 960a28b0 976c6504 nt!IopBuildSynchronousFsdRequest+0x34
838f6668 b5033b00 00000004 960a28b0 976c6504 nt!IoBuildSynchronousFsdRequest+0x23
WARNING: Stack unwind information not available. Following frames may be wrong.
838f66c0 b5034d34 000000f0 69e4e7d0 00000041 filter+0x3b00
838f66e0 b50316a9 b825f2e9 00000010 69e4e7d0 filter+0x4d34
838f6718 8680afc5 69e4e7d0 69f4e0c8 838f673c filter+0x16a9
838f6778 8680ab47 b350a198 96199ef0 ccdf0650 Wdf01000!FxRequestBase::CompleteSubmitted+0x1e5 [d:\th\minkernel\wdf\framework\shared\core\fxrequestbase.cpp @ 523]
838f6790 82311410 96199ef0 00df0650 011b1828 Wdf01000!FxIoTarget::_RequestCompletionRoutine+0xa7 [d:\th\minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 2448]
838f67b4 82299590 96199ef0 ccdf0650 b350a198 nt!IopUnloadSafeCompletion+0x3c
838f6818 86e110e2 96004f78 9618a608 00000010 nt!IopfCompleteRequest+0x240
838f6848 86e18ee9 00000011 00000000 96002edf HIDCLASS!HidpDistributeInterruptReport+0xdc
838f6884 82299590 00000000 96002db8 9618a608 HIDCLASS!HidpInterruptReadComplete+0x6b2d
838f68e8 8ee10868 8b8a3028 ccdab010 8b8a3bf0 nt!IopfCompleteRequest+0x240 838f6aac 8ee0ec64 ccdab010 8b8a3bf0 8ee0cc02 USBPORT!USBPORT_Core_iCompleteDoneTransfer+0x858
838f6ae0 8ee0ba4b 8b8a3bf0 30600802 8b8a3028 USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x204
838f6b1c 8ee0b89f 8b8a3028 8b8a3bf0 30600802 USBPORT!USBPORT_Core_UsbIocDpc_Worker+0x17b
838f6b68 8228c4f9 8b8a3bfc 8b8a3bf0 00000000 USBPORT!USBPORT_Xdpc_Worker_IocDpc+0x1df
838f6c20 8228c140 838f6c68 00000000 b115cb40 nt!KiExecuteAllDpcs+0x209
838f6d44 8234608c 00000000 00000000 00000000 nt!KiRetireDpcList+0xe0
838f6d48 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x38

STACK_COMMAND: kb

THREAD_SHA1_HASH_MOD_FUNC: b8d8e046d0f8e705d8162191d3afe8490b0a5364

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 69ed62acbd531ec5a3f80a5f65472a573b2e50e3

THREAD_SHA1_HASH_MOD: d0c8ebc4d3397884f0e77cd9d47f839605e0c795

FOLLOWUP_IP:
filter+3b00
b5033b00 8b15e07503b5 mov edx,dword ptr [filter+0x75e0 (b50375e0)]

FAULT_INSTR_CODE: 75e0158b

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: filter+3b00

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: filter

IMAGE_NAME: filter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 57431600

BUCKET_ID_FUNC_OFFSET: 3b00

FAILURE_BUCKET_ID: AV_filter!Unknown_Function

BUCKET_ID: AV_filter!Unknown_Function

PRIMARY_PROBLEM_CLASS: AV_filter!Unknown_Function

TARGET_TIME: 2016-05-23T14:41:45.000Z

OSBUILD: 10586

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 784

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x86

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS Personal

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2016-04-22 23:03:31

BUILDDATESTAMP_STR: 160422-1850

BUILDLAB_STR: th2_release_sec

BUILDOSVER_STR: 10.0.10586.306.x86fre.th2_release_sec.160422-1850

ANALYSIS_SESSION_ELAPSED_TIME: 32e5

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_filter!unknown_function

FAILURE_ID_HASH: {f9f66cdc-c963-a425-c4cd-4e80361036a9}

Followup: MachineOwner
---------

—
NTDEV is sponsored by OSR

Visit the list online at: http:

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:></http:>

17

Oh Duh! I’ve been looking at everything but the obvious. Thanks for pointing that out. This is the first time I’ve encountered a problem with IRQL so I haven’t developed the habit of checking that entry in the documentation.

Randy

18

Doron,

I see that IoBuildAsynchronousFsdRequest is also limited to IRQL <= ACP_LEVEL. Since I’m at DISPATCH_LEVEL I guess I’ll have to “roll my own” IRP. But won’t I still run into problems with IRQL when I try to use the IRP? Can I temporarily lower the IRQL to ACP_LEVEL using KeLowerIrql (I think not but I’m asking anyway)?

Randy

19

No, you can’t lower irql that way. You can either
a) roll your own irp with IoAllocateIrp, IoGetNextIrpStackLocation, etc. Or use the WDF routines to allocate and format the WDFREQUEST
b) queue a WDFWORKITEM from the completion routine and use IoBuildXxx from there

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, May 23, 2016 10:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver

Doron,

I see that IoBuildAsynchronousFsdRequest is also limited to IRQL <= ACP_LEVEL. Since I’m at DISPATCH_LEVEL I guess I’ll have to “roll my own” IRP. But won’t I still run into problems with IRQL when I try to use the IRP? Can I temporarily lower the IRQL to ACP_LEVEL using KeLowerIrql (I think not but I’m asking anyway)?

Randy

—
NTDEV is sponsored by OSR

Visit the list online at: http:

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:></http:>

20

Statement of the week (or,probably, even of the entire month)…

Anton Bassov