This is explained on msdn. A synchronous (not OVERLAPPED) handle allows one io at a time and that is enforced at the io manager layer.
Get Outlook for Androidhttps:
From: xxxxx@lists.osr.com on behalf of lizzoe
Sent: Friday, October 14, 2016 1:47:09 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ?ظ???Re: [ntdev] [NTDEV]How to pending a IO Request in WDF driver on Windows 7
You mean that’s impossible in synchronous I/O? A uncompleted Read request is bound to block other Write request? Is there a document can explain it ?
thank u.
--------------------------------
----- ԭʼ?ʼ? -----
???ˣ?Doron Holan
?ռ??ˣ?“Windows System Software Devs Interest List”
???⣺Re: [ntdev] [NTDEV]How to pending a IO Request in WDF driver on Windows 7
???ڣ?2016??10??13?? 21??51??
Is the application opening the handle as OVERLAPPED? It must be
Get Outlook for Androidhttps:
From: xxxxx@lists.osr.com on behalf of lizzoe
Sent: Thursday, October 13, 2016 4:49:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] [NTDEV]How to pending a IO Request in WDF driver on Windows 7
Hi, everyone
I’m a newbee in KMDF driver developing, there is a problem has troubled me very long, I hope to get help from experts here.
I create three I/O Queues for different IO Request: Read, Write, DeviceIOControl seperately?? set each queue’s dispatch type to sequential (only on request will be processed at one time)
WDF_IO_QUEUE_CONFIG_INIT(&queueConfig, WdfIoQueueDispatchSequential);
status = WdfIoQueueCreate(DevExt->Device,
&queueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&DevExt->ReadQueue);
status = WdfDeviceConfigureRequestDispatching(DevExt->Device,
DevExt->ReadQueue,
WdfRequestTypeRead);
status = WdfIoQueueCreate(DevExt->Device,
&queueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&DevExt->WriteQueue);
status = WdfDeviceConfigureRequestDispatching(DevExt->Device,
DevExt->WriteQueue,
WdfRequestTypeWrite);
status = WdfIoQueueCreate(DevExt->Device,
&queueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&DevExt->IOCTLQueue);
status = WdfDeviceConfigureRequestDispatching(DevExt->Device,
DevExt->IOCTLQueue,
WdfRequestTypeDeviceControl);
Under certain condition, I want to achieve such a scene: When dirver received a Read request, I just need to foword the request to another queue(via WdfRequestForwardToIoQueue), don’t reply completion immediately. It should be completed after user application invoke a particular DeviceIOControl code.
// code in EvtIORead
VOID
myEvtIoRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
{
NTSTATUS status = STATUS_UNSUCCESSFUL;
PDEVICE_CONTEXT devExt;
UNREFERENCED_PARAMETER(Length);
status = WdfRequestForwardToIoQueue(Request, devExt->PendingReadQueue);
if (!NT_SUCCESS(status)) {
WdfDmaTransactionRelease(devExt->ReadDmaTransaction);
WdfRequestComplete(Request, status);
}
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_READ,
“<– EvtIoRead: status %!STATUS!”, status);
return;
}
// code in EvtIOControl
VOID EvtIoControl
(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength,
IN ULONG IoControlCode
)
{
WdfRequestGetParameters(
Request,
¶ms
);
switch (IoControlCode)
{
case PCIe_IOCTL_STOP_IO:
status = WdfIoQueueRetrieveNextRequest(
DevExt->PendingReadQueue,
&request
);
// WdfRequestCancelSentRequest(DevExt->ReadRequest);
status = WdfIoQueueRetrieveNextRequest(
DevExt->PendingReadQueue,
&request
);
WdfDmaTransactionDmaCompleted(DevExt->ReadDmaTransaction, &status);
WdfRequestComplete(DevExt->ReadRequest, status);
WdfRequestCompleteWithInformation(Request, status, sizeof(ULONG));
break;
default:
ASSERTMSG(FALSE, “Invalid IOCTL request\n”);
WdfRequestComplete(Request, STATUS_INVALID_DEVICE_REQUEST);
break;
}
return;
}
I found it’s impossible after my debugging. After user application invoking DeviceIOControl, the whole user application blocks! I can’t do anything except killing it by Task Manager.
In my opinion??I have dispatched different IO request to seperate queue, so an uncompleted Read Request can’t block a DeviceIOControl Request.
I want to know is there an effective way to solve the problem, Thank you very much.
--------------------------------
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
—
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:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></https:></https:>