Handling I/O Request for the PDO

NTDEV
1

Hi all:

I am trying to forward the I/O Request from the PDO to the PDO root in the next driver herarchy:

usbser
|
PDO created by FDO
|
FDO
|
PDO Root

But it crashes when i implement the code:
Fisrt I add the next function before I create the PDO child created by FDO:

  • WdfPdoInitAllowForwardingRequestToParent()
    And later, after I create the child PDO, i create a queue where i add a IRP_MJ_INTERNAL_DEIVCE_CONTROL event handler with next sintax to forward the IRP:

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{

WDFDEVICE device, parentDevice;
WDF_REQUEST_FORWARD_OPTIONS forwardOptions;
NTSTATUS status;

KdPrint( ("EvtIoInternalDeviceControlEntry Entered"));

device = WdfIoQueueGetDevice(WdfRequestGetIoQueue(Request));
parentDevice = WdfPdoGetParent(device);

WDF_REQUEST_FORWARD_OPTIONS_INIT(&forwardOptions);
status = WdfRequestForwardToParentDeviceIoQueue(
Request,
WdfDeviceGetDefaultQueue(parentDevice),
&forwardOptions
);
if (!NT_SUCCESS(status)) {
WdfRequestComplete(
Request,
status
);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);

}

Everything goes right with the compilation and when i install the driver, but
when i attach the device and it ask for the usbser.sys it crashes with the next analyze:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 00000000, The handle value passed in.
Arg3: 00001003, Reserved.
Arg4: 8a8b4950, Reserved.

Debugging Details:

BUGCHECK_STR: 0x10D_5

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

LOCK_ADDRESS: 805614e0 -- (!locks 805614e0)

Resource @ nt!PiEngineLock (0x805614e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805614e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from f1be8f9e to 80537672

STACK_TEXT:
f79065b4 f1be8f9e 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1b
f79065d0 f1bbcf0f 8a8b4950 00000005 00000000 Wdf01000!FxVerifierBugCheck+0x24
f79065f8 9dd7d71d 8a8b4a18 765d4470 00000000 Wdf01000!imp_WdfRequestForwardToParentDeviceIoQueue+0x26
WARNING: Stack unwind information not available. Following frames may be wrong.
f7906610 9dd7d633 765d4470 00000000 f790662c dynambus+0x171d
f7906638 f1bd7072 78eb1fe8 765d4470 8821860c dynambus+0x1633
f790665c f1bd8432 78eb1fe8 765d4470 8821860c Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f790668c f1bda9ac 765d4470 89a2bb88 8714e010 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x37f
f79066a8 f1bdba36 8714e000 00000000 874cd010 Wdf01000!FxIoQueue::DispatchEvents+0x3be
f79066c8 f1bdd824 89a2bb88 86b90b68 0000003c Wdf01000!FxIoQueue::QueueRequest+0x1ec
f79066ec f1bcca3f 86b90b68 f7906714 f1c8665e Wdf01000!FxPkgIo::Dispatch+0x27d
f79066f8 f1c8665e 8714ab48 86b90b68 79471ea0 Wdf01000!FxDevice::Dispatch+0x7f
f7906714 804e13c9 8714ab48 880c6368 f7906794 USBlyzer+0x165e
f7906724 f1bbe0da 8709d2d8 8709d3cc 00000000 nt!IopfCallDriver+0x31
f790673c 9f4a8d5d 8709e7e0 89cb1db8 86b8e158 Wdf01000!imp_WdfRequestSend+0x254
f7906754 9f4a8c7b 7634e240 79471ea0 f7906794 low_usb+0xd5d
f79067c4 f1bd7072 78f62d20 7634e240 8821860c low_usb+0xc7b
f79067e8 f1bd8432 78f62d20 7634e240 8821860c Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f7906818 f1bda9ac 7634e240 89cb1db8 8709d2d8 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x37f
f7906834 f1bdba36 8709d200 00000000 86c4ca68 Wdf01000!FxIoQueue::DispatchEvents+0x3be
f7906854 f1bdd824 89cb1db8 87275470 8814b950 Wdf01000!FxIoQueue::QueueRequest+0x1ec
f7906878 f1bcca3f 86b90b68 f79068c0 804e13c9 Wdf01000!FxPkgIo::Dispatch+0x27d
f7906884 804e13c9 86b8a480 86b90b68 86b90b68 Wdf01000!FxDevice::Dispatch+0x7f
f7906894 a6957d71 87275470 8821860c 88c926d4 nt!IopfCallDriver+0x31
f79068c0 a695432f 872753b8 8821860c 87275470 usbser!CallUSBD+0x77
f79068e4 a6958333 872753b8 86bb11f0 872753b8 usbser!GetDeviceDescriptor+0x63
f7906910 a6957410 872753b8 86bb11f0 00000000 usbser!StartDevice+0x111
f7906930 804e13c9 872753b8 86bb11f0 f1bf5a08 usbser!UsbSer_PnP+0x1ec
f7906940 f1bf5ebe 00000008 870acd30 00000106 nt!IopfCallDriver+0x31
f7906960 f1bf6517 f7906990 f1bf6484 870acd30 Wdf01000!FxPkgFdo::PnpSendStartDeviceDownTheStackOverload+0x258
f7906968 f1bf6484 870acd30 870acdd8 870acd30 Wdf01000!FxPkgPnp::PnpEventInitStarting+0xd
f7906990 f1bf6db2 00000106 870acdd8 870acd30 Wdf01000!FxPkgPnp::PnpEnterNewState+0x104
f79069b4 f1bf747a f79069cc 883dc470 870acd30 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x149
f79069d8 f1bf040b 00000002 00000000 f7906a08 Wdf01000!FxPkgPnp::PnpProcessEvent+0x13e
f79069e8 f1befe02 870acd30 f7906a10 86bb11f0 Wdf01000!FxPkgPnp::_PnpStartDevice+0x1e
f7906a08 f1bcca3f 86bb11f0 f7906a30 f1bccc63 Wdf01000!FxPkgPnp::Dispatch+0x207
f7906a14 f1bccc63 870f1170 86bb11f0 86bb13a4 Wdf01000!FxDevice::Dispatch+0x7f
f7906a30 804e13c9 870f1170 86bb11f0 f7906aac Wdf01000!FxDevice::DispatchWithLock+0x7b
f7906a40 8059716a f7906aac 8714ab48 00000000 nt!IopfCallDriver+0x31
f7906a6c 805a18de 870f1170 f7906a88 00000000 nt!IopSynchronousCall+0xb7
f7906ab0 80506bf2 8714ab48 87557928 00000001 nt!IopStartDevice+0x4d
f7906acc 8059fced 8714ab48 8714ab01 87557928 nt!PipProcessStartPhase1+0x4e
f7906d24 80626233 86c04ee8 00000001 00000000 nt!PipProcessDevNodeTree+0x1db
f7906d54 80506090 00000003 805615c0 8056a5fc nt!PiRestartDevice+0x80
f7906d7c 804e23a5 00000000 00000000 8a98c020 nt!PipDeviceActionWorker+0x168
f7906dac 8057572b 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
f7906ddc 804ec6c9 804e22e1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
dynambus+171d
9dd7d71d ?? ???

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: dynambus+171d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: 0x10D_5_dynambus+171d

BUCKET_ID: 0x10D_5_dynambus+171d

Followup: MachineOwner

2

Did you single-step through the code?

Looks like you’re passing a NULL handle to WdfRequestForwardToParentDeviceIoQueue:

The diagnostic message:

“A framework object handle of the incorrect type was passed to a framework object method”

Or, do you have reason to believe this ISN’T the problem?

Peter
OSR

3

I created a queue to handle those events in the PDO created by the FDO, but i am not sure if i also need to create a queue for the FDO to handle the I/O request as the PDO does. if i am right does the PDO queue code could it be the same for the FDO queue?
Because what i need is just forward the usbser.sys request to the PDO root and callback the answer.

4

If the FDO is never going to have a handle opened against it and the PDO doesn’t fwd IO requests to the FDO, there is no need for queues in the FDO

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, April 05, 2011 4:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

I created a queue to handle those events in the PDO created by the FDO, but i am not sure if i also need to create a queue for the FDO to handle the I/O request as the PDO does. if i am right does the PDO queue code could it be the same for the FDO queue?

Because what i need is just forward the usbser.sys request to the PDO root and callback the answer.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Hi Doron:

I need to forward the IO request that comes from the usbser to the PDO root.
The problem is when an IO request that comes from the usbser to the PDO created by the FDO does not know how to forward to the PDO root.
I implemented a queue in the PDO that has an entry function:

ioQConfig.EvtIoInternalDeviceControl = EvtIoInternalDeviceControlEntry;

And when the request: URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE comes from the usbser to the PDO it creashes.

The code for the EvtIoInternalDeviceControlEntry is the next:

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PPDO_DEVICE_DATA Context;

KdPrint( (“EvtIoInternalDeviceControlEntry”));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
// get IO target
Target = WdfDeviceGetIoTarget(Device);
// get filter context
Context = PdoGetData(Device);
//get I/O request parameters
WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( (“WdfRequestSend failed: 0x%x\n”, status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

6

There is no default WDFIOTARGET for a PDO. What you want to do is get the default WDFIOTARGET for the parent

WDFDEVICE fdo;

Device = WdfIoQueueGetDevice(Queue);
fdo = WdfPdoGetParent(Device)
// get IO target
Target = WdfDeviceGetIoTarget(fdo);

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 06, 2011 10:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Hi Doron:

I need to forward the IO request that comes from the usbser to the PDO root.
The problem is when an IO request that comes from the usbser to the PDO created by the FDO does not know how to forward to the PDO root.
I implemented a queue in the PDO that has an entry function:

ioQConfig.EvtIoInternalDeviceControl = EvtIoInternalDeviceControlEntry;

And when the request: URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE comes from the usbser to the PDO it creashes.

The code for the EvtIoInternalDeviceControlEntry is the next:

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PPDO_DEVICE_DATA Context;

KdPrint( (“EvtIoInternalDeviceControlEntry”));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
// get IO target
Target = WdfDeviceGetIoTarget(Device);
// get filter context
Context = PdoGetData(Device);
//get I/O request parameters
WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( (“WdfRequestSend failed: 0x%x\n”, status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Hi Doron:

Thanks for your help, this make me sense,
I did what you told me but I got another crash with the next analysis:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it. This is a disasterous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet. This means that some other memory
has probably been trashed at this point.
Arguments:
Arg1: 8609bea8, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x35

LOCK_ADDRESS: 805614e0 -- (!locks 805614e0)

Resource @ nt!PiEngineLock (0x805614e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805614e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 805202fe to 8053767a

STACK_TEXT:
f78fa7ec 805202fe 00000035 8609bea8 00000000 nt!KeBugCheckEx+0x1b
f78fa804 f57be0da 8814e010 8814e104 00000000 nt!IopfCallDriver+0x17
f78fa81c 9f68a6cd 8874c8d8 8a8f4950 864c2940 Wdf01000!imp_WdfRequestSend+0x254
WARNING: Stack unwind information not available. Following frames may be wrong.
f78fa834 9f68a615 7570b6a8 79b3d6b8 f78fa870 dynambus+0x16cd
f78fa8a8 f57d7072 77eb1fe8 7570b6a8 862d936c dynambus+0x1615
f78fa8cc f57d8432 77eb1fe8 7570b6a8 862d936c Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f78fa8fc f57da9ac 7570b6a8 8a8f4950 8814e010 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x37f
f78fa918 f57dba36 8814e000 00000000 8646ae28 Wdf01000!FxIoQueue::DispatchEvents+0x3be
f78fa938 f57dd824 8a8f4950 8609bea8 0000003c Wdf01000!FxIoQueue::QueueRequest+0x1ec
f78fa95c f57cca3f 8609bea8 f78fa984 f588665e Wdf01000!FxPkgIo::Dispatch+0x27d
f78fa968 f588665e 88151318 8609bea8 85f25c20 Wdf01000!FxDevice::Dispatch+0x7f
f78fa984 804e13d9 88151318 89abd8b8 8609bea8 USBlyzer+0x165e
f78fa994 a5d19d71 85f25c20 862d936c 89b02fa4 nt!IopfCallDriver+0x31
f78fa9c0 a5d1632f 85f25b68 862d936c 85f25c20 usbser!CallUSBD+0x77
f78fa9e4 a5d1a333 85f25b68 85f31318 85f25b68 usbser!GetDeviceDescriptor+0x63
f78faa10 a5d19410 85f25b68 85f31318 85f313d0 usbser!StartDevice+0x111
f78faa30 804e13d9 85f25b68 85f31318 f78faaac usbser!UsbSer_PnP+0x1ec
f78faa40 8059716a f78faaac 88151318 00000000 nt!IopfCallDriver+0x31
f78faa6c 805a18de 85f25b68 f78faa88 00000000 nt!IopSynchronousCall+0xb7
f78faab0 80506c02 88151318 885b9780 00000001 nt!IopStartDevice+0x4d
f78faacc 8059fced 88151318 88151301 885b9780 nt!PipProcessStartPhase1+0x4e
f78fad24 8062625b 88002ee8 00000001 00000000 nt!PipProcessDevNodeTree+0x1db
f78fad54 805060a0 00000003 805615c0 8056a5fc nt!PiRestartDevice+0x80
f78fad7c 804e23b5 00000000 00000000 8a98d8b8 nt!PipDeviceActionWorker+0x168
f78fadac 80575723 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
f78faddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

should I set/call someting before forward the irp to the target?

8

You have 2 options, both result in getting PDO->StackSize to be the right size

  1. right after you have created the PDO you can do this
    WdfDeviceWdmGetDeviceObject(pdo)->StackSize = WdfDeviceWdmGetDeviceObject(WdfPdoGetParent(pdo))->StackSize+1

Or
2) call WdfPdoInitAllowForwardingRequestToParent when creating the PDO even though you will never fwd a request from the PDO the FDO. This will essentially do the same thing as #1 underneath the covers

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 06, 2011 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Hi Doron:

Thanks for your help, this make me sense, I did what you told me but I got another crash with the next analysis:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NO_MORE_IRP_STACK_LOCATIONS (35)
A higher level driver has attempted to call a lower level driver through the IoCallDriver() interface, but there are no more stack locations in the packet, hence, the lower level driver would not be able to access its parameters, as there are no parameters for it. This is a disasterous situation, since the higher level driver "thinks" it has filled in the parameters for the lower level driver (something it MUST do before it calls it), but since there is no stack location for the latter driver, the former has written off of the end of the packet. This means that some other memory has probably been trashed at this point.
Arguments:
Arg1: 8609bea8, Address of the IRP
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x35

LOCK_ADDRESS: 805614e0 -- (!locks 805614e0)

Resource @ nt!PiEngineLock (0x805614e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805614e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 805202fe to 8053767a

STACK_TEXT:
f78fa7ec 805202fe 00000035 8609bea8 00000000 nt!KeBugCheckEx+0x1b
f78fa804 f57be0da 8814e010 8814e104 00000000 nt!IopfCallDriver+0x17 f78fa81c 9f68a6cd 8874c8d8 8a8f4950 864c2940 Wdf01000!imp_WdfRequestSend+0x254
WARNING: Stack unwind information not available. Following frames may be wrong.
f78fa834 9f68a615 7570b6a8 79b3d6b8 f78fa870 dynambus+0x16cd
f78fa8a8 f57d7072 77eb1fe8 7570b6a8 862d936c dynambus+0x1615 f78fa8cc f57d8432 77eb1fe8 7570b6a8 862d936c Wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f78fa8fc f57da9ac 7570b6a8 8a8f4950 8814e010 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x37f
f78fa918 f57dba36 8814e000 00000000 8646ae28 Wdf01000!FxIoQueue::DispatchEvents+0x3be
f78fa938 f57dd824 8a8f4950 8609bea8 0000003c Wdf01000!FxIoQueue::QueueRequest+0x1ec
f78fa95c f57cca3f 8609bea8 f78fa984 f588665e Wdf01000!FxPkgIo::Dispatch+0x27d
f78fa968 f588665e 88151318 8609bea8 85f25c20 Wdf01000!FxDevice::Dispatch+0x7f
f78fa984 804e13d9 88151318 89abd8b8 8609bea8 USBlyzer+0x165e
f78fa994 a5d19d71 85f25c20 862d936c 89b02fa4 nt!IopfCallDriver+0x31
f78fa9c0 a5d1632f 85f25b68 862d936c 85f25c20 usbser!CallUSBD+0x77
f78fa9e4 a5d1a333 85f25b68 85f31318 85f25b68 usbser!GetDeviceDescriptor+0x63
f78faa10 a5d19410 85f25b68 85f31318 85f313d0 usbser!StartDevice+0x111
f78faa30 804e13d9 85f25b68 85f31318 f78faaac usbser!UsbSer_PnP+0x1ec
f78faa40 8059716a f78faaac 88151318 00000000 nt!IopfCallDriver+0x31 f78faa6c 805a18de 85f25b68 f78faa88 00000000 nt!IopSynchronousCall+0xb7
f78faab0 80506c02 88151318 885b9780 00000001 nt!IopStartDevice+0x4d f78faacc 8059fced 88151318 88151301 885b9780 nt!PipProcessStartPhase1+0x4e
f78fad24 8062625b 88002ee8 00000001 00000000 nt!PipProcessDevNodeTree+0x1db
f78fad54 805060a0 00000003 805615c0 8056a5fc nt!PiRestartDevice+0x80 f78fad7c 804e23b5 00000000 00000000 8a98d8b8 nt!PipDeviceActionWorker+0x168 f78fadac 80575723 00000000 00000000 00000000 nt!ExpWorkerThread+0xef f78faddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

should I set/call someting before forward the irp to the target?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

9

Doron:

Thank you very much this works fine.
But i have another question:

Now i can send from the usb to the serial, but i do not receive anything,
do i need to implement a function to pass the information that the PDO root receive
to the PDO??, as we do to forward from the PDO to the PDO root but in the other way?

10

The PDO root does not initiate IO down to the device, it will just take the commands and io sent to it by the stack above (ie your driver or the IO you are forwarding from usbser) down to it. There is no way to push information/irps “up” the stack if that is what you are asking

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 06, 2011 4:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Doron:

Thank you very much this works fine.
But i have another question:

Now i can send from the usb to the serial, but i do not receive anything, do i need to implement a function to pass the information that the PDO root receive to the PDO??, as we do to forward from the PDO to the PDO root but in the other way?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

Hi Doron:

Could you answer me this question?

I used to have this hierarchy driver and everything was right

usbser
|
PDO created by FDO 1.sys
|
FDO 1.sys

now that i split the driver, i added a filter driver to enumerate a pdo as the next hierarchy, i got a problem i had with the last hierarchy driver but you helped me to solve it.

usbser
|
PDO created by a Filter 2.sys
|
Filter 2.sys
|
FDO 1.sys

Problem: When usbser sends an I/O Request to the PDO, the PDO enters to the EvtIoInternalDeviceControlEntry but it does not forward the I/O Request, the only difference now
is that the pdo is created by a filter and not by a fdo directly, do i need to get the target from
the fdo? or what should i do for solving the problem?

Thanks.

12

When it hits the filters PDO, send it down the filter’s parent stack. You can get fancy and skip the filter device in the parent and send it directly to the fdo (1.sys) or get even fancier by sending the io to the device the fdo (1.sys) is attached to. How do you get fancy? Getting the fdo (1.sys) is easy, you have that information in the filter device object in the parent stack. Getting the device the fdo (1.sys) is attached to requires a custom ioctl asking 1.sys for that information.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, April 12, 2011 6:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Hi Doron:

Could you answer me this question?

I used to have this hierarchy driver and everything was right

usbser
|
PDO created by FDO 1.sys
|
FDO 1.sys

now that i split the driver, i added a filter driver to enumerate a pdo as the next hierarchy, i got a problem i had with the last hierarchy driver but you helped me to solve it.

usbser
|
PDO created by a Filter 2.sys
|
Filter 2.sys
|
FDO 1.sys

Problem: When usbser sends an I/O Request to the PDO, the PDO enters to the EvtIoInternalDeviceControlEntry but it does not forward the I/O Request, the only difference now is that the pdo is created by a filter and not by a fdo directly, do i need to get the target from the fdo? or what should i do for solving the problem?

Thanks.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

13

In the first hierarchy i mentioned, this is the code i implemented for the PDO that worked right, but now with the new implementation now it does not forward as it used to and the code is the same.
Do i need to change something on it?

I added :
WdfDeviceWdmGetDeviceObject(pdo)->StackSize =
WdfDeviceWdmGetDeviceObject(WdfPdoGetParent(pdo))->StackSize+1
after create the PDO as i used to.

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PPDO_DEVICE_DATA Context;
WDFDEVICE filter;

KdPrint( (“EvtIoInternalDeviceControlEntry:”));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
filter = WdfPdoGetParent(Device);
// get IO target
Target = WdfDeviceGetIoTarget(filter);

WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

//get URB from IRP
urb=(PURB) params.Parameters.Others.Arg1;
DbgPrint(“URB Header Function code:%s\n”,PrintUrbHeaderFunction(urb->UrbHeader.Function));

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( (“WdfRequestSend failed: 0x%x\n”, status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

Thanks for your help.

14

FDO in 1.sys needs to process internal IOCTLs and send them down the stack. Or mark itself as a filter and all io will be automatically sent down the stack (but you will then have to call WdfDeviceInitSetPowerPolicyOwnership(TRUE) after calling WdfDeviceInitSetFilter(TRUE) to make sure that the FDO in 1.sys is still the power policy owner b/c SetFilter(TRUE) turns power policy ownership off)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 13, 2011 10:43 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

In the first hierarchy i mentioned, this is the code i implemented for the PDO that worked right, but now with the new implementation now it does not forward as it used to and the code is the same.
Do i need to change something on it?

I added :
WdfDeviceWdmGetDeviceObject(pdo)->StackSize =
WdfDeviceWdmGetDeviceObject(WdfPdoGetParent(pdo))->StackSize+1
after create the PDO as i used to.

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PPDO_DEVICE_DATA Context;
WDFDEVICE filter;

KdPrint( (“EvtIoInternalDeviceControlEntry:”));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
filter = WdfPdoGetParent(Device);
// get IO target
Target = WdfDeviceGetIoTarget(filter);

WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

//get URB from IRP
urb=(PURB) params.Parameters.Others.Arg1;
DbgPrint(“URB Header Function code:%s\n”,PrintUrbHeaderFunction(urb->UrbHeader.Function));

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( (“WdfRequestSend failed: 0x%x\n”, status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

Thanks for your help.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

15

I tried to the first option to handle internal ioctls in the FDO (1.sys) as i did in the pdo but i got a crash:

The queue is created after the device is created.
with this code:

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PFDO_DEVICE_DATA Context;
WDFDEVICE fdo;

KdPrint( ("EvtIoInternalDeviceControlEntry:"));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
// get IO target
Target = WdfDeviceGetIoTarget(Device);
//get I/O request parameters

WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

//get URB from IRP
urb=(PURB) params.Parameters.Others.Arg1;
//DbgPrint("URB Header Function code:%s\n",PrintUrbHeaderFunction(urb->UrbHeader.Function));

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( ("WdfRequestSend failed: 0x%x\n", status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

CRASH:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f5814696, The address that the exception occurred at
Arg3: f7906560, Exception Record Address
Arg4: f790625c, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
Wdf01000!imp_WdfIoQueueCreate+1ec
f5814696 8901 mov dword ptr [ecx],eax

EXCEPTION_RECORD: f7906560 -- (.exr 0xfffffffff7906560)
Cannot read Exception record @ f7906560

CONTEXT: f790625c -- (.cxr 0xfffffffff790625c)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 6

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LOCK_ADDRESS: 805614e0 -- (!locks 805614e0)

Resource @ nt!PiEngineLock (0x805614e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805614e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from a1efd022 to f5814696

STACK_TEXT:
f790663c a1efd022 86ac26c8 76814718 f7906670 Wdf01000!imp_WdfIoQueueCreate+0x1ec
WARNING: Stack unwind information not available. Following frames may be wrong.
f7906658 a1efcf58 76814718 f7906670 00000000 dynambus+0x1022
f79066a8 a1efe50d 76814718 00000000 e526c788 dynambus+0xf58
f79067b4 f58112c3 762be5a8 00000000 f583f4c8 dynambus+0x250d
f79067d0 f5811755 762be5a8 f79067f0 867a7b30 Wdf01000!FxDriverDeviceAdd::Invoke+0x28
f79069dc f5811821 867a7b30 f7906a00 80506ced Wdf01000!FxDriver::AddDevice+0xc1
f79069e8 80506ced 8862e5c8 867a7b30 e5a587b0 Wdf01000!FxDriver::AddDevice+0x1b
f7906a00 805a0143 f5811806 00000004 00000001 nt!PpvUtilCallAddDevice+0x41
f7906ac8 8059c149 00000000 02000001 00000000 nt!PipCallDriverAddDevice+0x3b9
f7906d24 8062625b 86d63c30 00000001 00000000 nt!PipProcessDevNodeTree+0x1a4
f7906d54 805060a0 00000003 805615c0 8056a5fc nt!PiRestartDevice+0x80
f7906d7c 804e23b5 00000000 00000000 8a98c020 nt!PipDeviceActionWorker+0x168
f7906dac 80575723 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
f7906ddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
dynambus+1022
a1efd022 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dynambus+1022

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff790625c ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus+1022

BUCKET_ID: 0x7E_dynambus+1022

Followup: MachineOwner

Thanks for your help.

16

1 Fix your symbols
2 once you do that, run !wdfkd.wdflogdump dynambus to see if anything is reported
3 change the name of your driver, using the sample name itself will only cause conflict later on

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 13, 2011 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

I tried to the first option to handle internal ioctls in the FDO (1.sys) as i did in the pdo but i got a crash:

The queue is created after the device is created.
with this code:

VOID
EvtIoInternalDeviceControlEntry(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WDF_REQUEST_SEND_OPTIONS options;
WDFIOTARGET Target;
BOOLEAN ret;
NTSTATUS status;
WDF_REQUEST_PARAMETERS params;
WDFDEVICE Device;
PURB urb;
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS usbConfig;
PFDO_DEVICE_DATA Context;
WDFDEVICE fdo;

KdPrint( ("EvtIoInternalDeviceControlEntry:"));
// get device framework
Device = WdfIoQueueGetDevice(Queue);
// get IO target
Target = WdfDeviceGetIoTarget(Device);
//get I/O request parameters

WDF_REQUEST_PARAMETERS_INIT(&params);
WdfRequestGetParameters(
Request,
&params
);

//get URB from IRP
urb=(PURB) params.Parameters.Others.Arg1;
//DbgPrint("URB Header Function code:%s\n",PrintUrbHeaderFunction(urb->UrbHeader.Function));

// any other irp send it forward
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(Request, Target, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (Request);
KdPrint( ("WdfRequestSend failed: 0x%x\n", status));
WdfRequestComplete(Request, status);
}

UNREFERENCED_PARAMETER(OutputBufferLength);
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(IoControlCode);
}

CRASH:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f5814696, The address that the exception occurred at
Arg3: f7906560, Exception Record Address
Arg4: f790625c, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
Wdf01000!imp_WdfIoQueueCreate+1ec
f5814696 8901 mov dword ptr [ecx],eax

EXCEPTION_RECORD: f7906560 -- (.exr 0xfffffffff7906560) Cannot read Exception record @ f7906560

CONTEXT: f790625c -- (.cxr 0xfffffffff790625c) Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 6

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LOCK_ADDRESS: 805614e0 -- (!locks 805614e0)

Resource @ nt!PiEngineLock (0x805614e0) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x805614e0
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from a1efd022 to f5814696

STACK_TEXT:
f790663c a1efd022 86ac26c8 76814718 f7906670 Wdf01000!imp_WdfIoQueueCreate+0x1ec
WARNING: Stack unwind information not available. Following frames may be wrong.
f7906658 a1efcf58 76814718 f7906670 00000000 dynambus+0x1022
f79066a8 a1efe50d 76814718 00000000 e526c788 dynambus+0xf58
f79067b4 f58112c3 762be5a8 00000000 f583f4c8 dynambus+0x250d
f79067d0 f5811755 762be5a8 f79067f0 867a7b30 Wdf01000!FxDriverDeviceAdd::Invoke+0x28
f79069dc f5811821 867a7b30 f7906a00 80506ced Wdf01000!FxDriver::AddDevice+0xc1
f79069e8 80506ced 8862e5c8 867a7b30 e5a587b0 Wdf01000!FxDriver::AddDevice+0x1b
f7906a00 805a0143 f5811806 00000004 00000001 nt!PpvUtilCallAddDevice+0x41
f7906ac8 8059c149 00000000 02000001 00000000 nt!PipCallDriverAddDevice+0x3b9
f7906d24 8062625b 86d63c30 00000001 00000000 nt!PipProcessDevNodeTree+0x1a4
f7906d54 805060a0 00000003 805615c0 8056a5fc nt!PiRestartDevice+0x80 f7906d7c 804e23b5 00000000 00000000 8a98c020 nt!PipDeviceActionWorker+0x168 f7906dac 80575723 00000000 00000000 00000000 nt!ExpWorkerThread+0xef f7906ddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
dynambus+1022
a1efd022 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dynambus+1022

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff790625c ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus+1022

BUCKET_ID: 0x7E_dynambus+1022

Followup: MachineOwner

Thanks for your help.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

17

Hi Doron:

I tried the second option you told me to mark the FDO as a filter and everything was successfuly.
Now i can handle the i/o request.

But now i am trying to add the PPO in the FDO as next:

WdfFdoInitSetFilter(DeviceInit);
WdfDeviceInitSetPowerPolicyOwnership(DeviceInit,TRUE);

WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&pnpPowerCallbacks);
//
// For usb devices, PrepareHardware callback is the to place select the
// interface and configure the device.
//
pnpPowerCallbacks.EvtDevicePrepareHardware = FslEvtDevicePrepareHardware;
pnpPowerCallbacks.EvtDeviceD0Entry = FslEvtDeviceD0Entry;
pnpPowerCallbacks.EvtDeviceD0Exit = FslEvtDeviceD0Exit;

WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks); //This function makes the crash when i add it

This is the Crash:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f40ce74a, The address that the exception occurred at
Arg3: f7902bb0, Exception Record Address
Arg4: f79028ac, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
dynambus+74a
f40ce74a ?? ???

EXCEPTION_RECORD: f7902bb0 -- (.exr 0xfffffffff7902bb0)
Cannot read Exception record @ f7902bb0

CONTEXT: f79028ac -- (.cxr 0xfffffffff79028ac)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LAST_CONTROL_TRANSFER: from 00000000 to f40ce74a

STACK_TEXT:
f7902c74 00000000 86d33468 86d33630 00000014 dynambus+0x74a

FOLLOWUP_IP:
dynambus+74a
f40ce74a ?? ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: dynambus+74a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff79028ac ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus+74a

BUCKET_ID: 0x7E_dynambus+74a

Followup: MachineOwner

18

Fix your symbols and send the stack trace

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 13, 2011 2:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Hi Doron:

I tried the second option you told me to mark the FDO as a filter and everything was successfuly.
Now i can handle the i/o request.

But now i am trying to add the PPO in the FDO as next:

WdfFdoInitSetFilter(DeviceInit);
WdfDeviceInitSetPowerPolicyOwnership(DeviceInit,TRUE);

WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&pnpPowerCallbacks);
//
// For usb devices, PrepareHardware callback is the to place select the
// interface and configure the device.
//
pnpPowerCallbacks.EvtDevicePrepareHardware = FslEvtDevicePrepareHardware;
pnpPowerCallbacks.EvtDeviceD0Entry = FslEvtDeviceD0Entry;
pnpPowerCallbacks.EvtDeviceD0Exit = FslEvtDeviceD0Exit;

WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit,
&pnpPowerCallbacks); //This function makes the crash when i add it

This is the Crash:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f40ce74a, The address that the exception occurred at
Arg3: f7902bb0, Exception Record Address
Arg4: f79028ac, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
dynambus+74a
f40ce74a ?? ???

EXCEPTION_RECORD: f7902bb0 -- (.exr 0xfffffffff7902bb0) Cannot read Exception record @ f7902bb0

CONTEXT: f79028ac -- (.cxr 0xfffffffff79028ac) Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LAST_CONTROL_TRANSFER: from 00000000 to f40ce74a

STACK_TEXT:
f7902c74 00000000 86d33468 86d33630 00000014 dynambus+0x74a

FOLLOWUP_IP:
dynambus+74a
f40ce74a ?? ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: dynambus+74a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff79028ac ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus+74a

BUCKET_ID: 0x7E_dynambus+74a

Followup: MachineOwner

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

19

Sorry:

Here you have the crash with the symbols:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f40ce74a, The address that the exception occurred at
Arg3: f7902bb0, Exception Record Address
Arg4: f79028ac, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
dynambus!FslEvtDevicePrepareHardware+9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f40ce74a ?? ???

EXCEPTION_RECORD: f7902bb0 -- (.exr 0xfffffffff7902bb0)
Cannot read Exception record @ f7902bb0

CONTEXT: f79028ac -- (.cxr 0xfffffffff79028ac)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LAST_CONTROL_TRANSFER: from f157c301 to f40ce74a

STACK_TEXT:
f7902c98 f157c301 792ccb90 79103668 7868adc8 dynambus!FslEvtDevicePrepareHardware+0x9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f7902cb4 f157c543 7868adc8 8680db50 01d33468 Wdf01000!FxPkgPnp::PnpPrepareHardware+0x77
f7902cc8 f157b484 8680db50 8680dbf8 8680db50 Wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x2b
f7902cf0 f157bdb2 00000108 8680dc04 8680db50 Wdf01000!FxPkgPnp::PnpEnterNewState+0x104
f7902d14 f157c503 f7902d44 80701830 8680dbf8 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x149
f7902d28 f157fd1c 8680db50 f7902d44 88cd9f38 Wdf01000!FxPkgPnp::_PnpProcessEventInner+0x26
f7902d58 f1580ff8 875cf210 89b5b500 f7902d7c Wdf01000!FxEventQueue::EventQueueWorker+0x6f
f7902d68 8056df51 89b5b500 8680dbf8 8056a5fc Wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x21
f7902d7c 804e23b5 875cf210 00000000 8a98d3c8 nt!IopProcessWorkItem+0x13
f7902dac 80575723 875cf210 00000000 00000000 nt!ExpWorkerThread+0xef
f7902ddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
dynambus!FslEvtDevicePrepareHardware+9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f40ce74a ?? ???

FAULTING_SOURCE_CODE:
278: status));
279: return status;
280: }
281:

282: pDeviceContext->UsbInterfaceControl = configParams.Types.MultiInterface.Pairs[0].UsbInterface;
283: pDeviceContext->UsbInterfaceData = configParams.Types.MultiInterface.Pairs[1].UsbInterface;
284:
285: status = InitPowerManagement(Device, pDeviceContext);
286: if(!NT_SUCCESS(status))
287: return status;

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: dynambus!FslEvtDevicePrepareHardware+9a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff79028ac ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus!FslEvtDevicePrepareHardware+9a

BUCKET_ID: 0x7E_dynambus!FslEvtDevicePrepareHardware+9a

Followup: MachineOwner

Thanks.

20

This is the line that is blowing up

282: pDeviceContext->UsbInterfaceControl = configParams.Types.MultiInterface.Pairs[0].UsbInterface;

My guess is that either the Pairs array is NULL or garabage or pDeviceContext is NULL or garbage. Use a debugger and step through the code

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, April 13, 2011 3:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Handling I/O Request for the PDO

Sorry:

Here you have the crash with the symbols:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f40ce74a, The address that the exception occurred at
Arg3: f7902bb0, Exception Record Address
Arg4: f79028ac, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
dynambus!FslEvtDevicePrepareHardware+9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f40ce74a ?? ???

EXCEPTION_RECORD: f7902bb0 -- (.exr 0xfffffffff7902bb0) Cannot read Exception record @ f7902bb0

CONTEXT: f79028ac -- (.cxr 0xfffffffff79028ac) Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT: 7

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x7E

EXCEPTION_STR: 0x0

LAST_CONTROL_TRANSFER: from f157c301 to f40ce74a

STACK_TEXT:
f7902c98 f157c301 792ccb90 79103668 7868adc8 dynambus!FslEvtDevicePrepareHardware+0x9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f7902cb4 f157c543 7868adc8 8680db50 01d33468 Wdf01000!FxPkgPnp::PnpPrepareHardware+0x77
f7902cc8 f157b484 8680db50 8680dbf8 8680db50 Wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x2b
f7902cf0 f157bdb2 00000108 8680dc04 8680db50 Wdf01000!FxPkgPnp::PnpEnterNewState+0x104
f7902d14 f157c503 f7902d44 80701830 8680dbf8 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x149
f7902d28 f157fd1c 8680db50 f7902d44 88cd9f38 Wdf01000!FxPkgPnp::_PnpProcessEventInner+0x26
f7902d58 f1580ff8 875cf210 89b5b500 f7902d7c Wdf01000!FxEventQueue::EventQueueWorker+0x6f
f7902d68 8056df51 89b5b500 8680dbf8 8056a5fc Wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x21
f7902d7c 804e23b5 875cf210 00000000 8a98d3c8 nt!IopProcessWorkItem+0x13 f7902dac 80575723 875cf210 00000000 00000000 nt!ExpWorkerThread+0xef f7902ddc 804ec6d9 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
dynambus!FslEvtDevicePrepareHardware+9a [c:\winddk\7600.16385.1\src\general\toaster\kmdf\bus\test_pdof_wseparated_asfilter\busenum.c @ 282]
f40ce74a ?? ???

FAULTING_SOURCE_CODE:
278: status));
279: return status;
280: }
281:

282: pDeviceContext->UsbInterfaceControl = configParams.Types.MultiInterface.Pairs[0].UsbInterface;
283: pDeviceContext->UsbInterfaceData = configParams.Types.MultiInterface.Pairs[1].UsbInterface;
284:
285: status = InitPowerManagement(Device, pDeviceContext);
286: if(!NT_SUCCESS(status))
287: return status;

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: dynambus!FslEvtDevicePrepareHardware+9a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dynambus

IMAGE_NAME: dynambus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xfffffffff79028ac ; kb

FAILURE_BUCKET_ID: 0x7E_dynambus!FslEvtDevicePrepareHardware+9a

BUCKET_ID: 0x7E_dynambus!FslEvtDevicePrepareHardware+9a

Followup: MachineOwner

Thanks.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum