KDMF EvtIoRead with WdfIoQueueDispatchManual

Hi All,

I am trying to create a queue for IoRead requests. Here is the code:

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE( &readQueueConfig, WdfIoQueueDispatchManual );

readQueueConfig.EvtIoRead = PciDrvEvtIoRead;

status = WdfIoQueueCreate ( fdoData->WdfDevice, &readQueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &fdoData->ReadQueue );

It returns “STATUS_INVALID_PARAMETER”. It succeeds if I choose WdfIoQueueDispatchSequential, but I want to use WdfIoQueueRetrieveNextRequest to manually process requests. Any ideas why it will not allow me to do this?

Thanks,
zep

The KMDF log should tell you why you are getting an error.

d

An EvtIoRead function doesn’t make much sense for use with a manual
queue. The framework will call that function for parallel and
sequential queues configured for read dispatching once a request is
dispatched to the queue. But for a manual queue, the framework just
dispatches the request to the queue and doesn’t call anything. You
need to have a thread or work item or something that pulls it off the
queue when you want to.

Beverly

On 10/4/06, zeppelin@io.com wrote:
> Hi All,
>
> I am trying to create a queue for IoRead requests. Here is the code:
>
> WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE( &readQueueConfig, WdfIoQueueDispatchManual );
>
> readQueueConfig.EvtIoRead = PciDrvEvtIoRead;
>
> status = WdfIoQueueCreate ( fdoData->WdfDevice, &readQueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &fdoData->ReadQueue );
>
> It returns “STATUS_INVALID_PARAMETER”. It succeeds if I choose WdfIoQueueDispatchSequential, but I want to use WdfIoQueueRetrieveNextRequest to manually process requests. Any ideas why it will not allow me to do this?
>
> Thanks,
> zep
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

You can’t set callback functions for a manual queue. They will never be called.

I believe you must use WdfDeviceConfigureRequestDispatching with WdfRequestTypeRead to accomplish what you’re trying to do.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 10:46 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

Hi All,

I am trying to create a queue for IoRead requests. Here is the code:

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE( &readQueueConfig, WdfIoQueueDispatchManual );

readQueueConfig.EvtIoRead = PciDrvEvtIoRead;

status = WdfIoQueueCreate ( fdoData->WdfDevice, &readQueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &fdoData->ReadQueue );

It returns “STATUS_INVALID_PARAMETER”. It succeeds if I choose WdfIoQueueDispatchSequential, but I want to use WdfIoQueueRetrieveNextRequest to manually process requests. Any ideas why it will not allow me to do this?

Thanks,
zep


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Bob,
The moment I read your response it made sense, I went down a wierd path because well… not enough coffee today I guess. The fact is, I don’t want a callback. So here is the real question: I want to process I/O Read requests in my DPC, how do I get those requests in to a queue that I can use with WdfIoQueueRetrieveNextRequest? Obviously I could set up a dispatch routine for IoRead’s and move them into another queue, but that seems like a extra step. Is there a more direct way?

Thanks,
zep

I’m also pretty sure you don’t want to be the default queue (because it’s going to get all of the requests). If you use the dispatching configuration, then you don’t need a default queue.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, October 04, 2006 11:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

You can’t set callback functions for a manual queue. They will never be called.

I believe you must use WdfDeviceConfigureRequestDispatching with WdfRequestTypeRead to accomplish what you’re trying to do.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 10:46 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

Hi All,

I am trying to create a queue for IoRead requests. Here is the code:

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE( &readQueueConfig, WdfIoQueueDispatchManual );

readQueueConfig.EvtIoRead = PciDrvEvtIoRead;

status = WdfIoQueueCreate ( fdoData->WdfDevice, &readQueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &fdoData->ReadQueue );

It returns “STATUS_INVALID_PARAMETER”. It succeeds if I choose WdfIoQueueDispatchSequential, but I want to use WdfIoQueueRetrieveNextRequest to manually process requests. Any ideas why it will not allow me to do this?

Thanks,
zep


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Sorry… I should have read your whole message before I replied. I think you already answered my question.

Thanks,
z

P.S. I Really like KDMF.

Yes, the default queue was a left over experiment from trying to figure why I was getting an error. Thanks for pointing that out though.

-z

I have now compiled and loaded with no errors, however I have a new side effect. My IOCTLS are not getting dispatched anymore. I have two queues now, the manual one we have been discussing, and a parallel one for IOCTLS (it always worked before). Niether are marked as default. I use these calls to configure the queues:

For ioctl queue:

status = WdfDeviceConfigureRequestDispatching(FdoData->WdfDevice, FdoData->IoctlQueue, WdfRequestTypeDeviceControl);

For read queue:

status = WdfDeviceConfigureRequestDispatching(fdoData->WdfDevice, fdoData->ReadQueue, WdfRequestTypeRead);

Have I done something to bungle the ioctl dispatching by adding the read queue?

Thanks,
z

What type of queue is the IOCTL queue? If it is not a manual queue,
does it have an EvtIoDeviceControl callback? If it is a manual queue,
do you have something pulling the requests off of it?

Beverly

On 10/4/06, zeppelin@io.com wrote:
> I have now compiled and loaded with no errors, however I have a new side effect. My IOCTLS are not getting dispatched anymore. I have two queues now, the manual one we have been discussing, and a parallel one for IOCTLS (it always worked before). Niether are marked as default. I use these calls to configure the queues:
>
> For ioctl queue:
>
> status = WdfDeviceConfigureRequestDispatching(FdoData->WdfDevice, FdoData->IoctlQueue, WdfRequestTypeDeviceControl);
>
> For read queue:
>
> status = WdfDeviceConfigureRequestDispatching(fdoData->WdfDevice, fdoData->ReadQueue, WdfRequestTypeRead);
>
>
> Have I done something to bungle the ioctl dispatching by adding the read queue?
>
> Thanks,
> z
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Create a non-default manual queue, and then use WdfDeviceConfigureRequestDispatching to route the read requests there. You do not need a default queue in his configuration (all other I/O requests will fail as invalid).

I showed uncertainty about this before because I hadn’t tried it (so in the meantime I read the source and then asked the devs directly, just to be certain;).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 12:05 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

Bob,
The moment I read your response it made sense, I went down a wierd path because well… not enough coffee today I guess. The fact is, I don’t want a callback. So here is the real question: I want to process I/O Read requests in my DPC, how do I get those requests in to a queue that I can use with WdfIoQueueRetrieveNextRequest? Obviously I could set up a dispatch routine for IoRead’s and move them into another queue, but that seems like a extra step. Is there a more direct way?

Thanks,
zep


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

It is parallel and has a callback… It was working perfectly until configure my read queue using the following statement:

status = WdfDeviceConfigureRequestDispatching(fdoData->WdfDevice, fdoData->ReadQueue, WdfRequestTypeRead);

If I comment out that line my IOCTL queue functions fine.

-z

Here is the code for the IOCTL queue as stated before it works fine until I add the read queue:

WDF_IO_QUEUE_CONFIG_INIT( &ioQueueConfig, WdfIoQueueDispatchParallel );

ioQueueConfig.EvtIoDeviceControl = PciDrvEvtIoDeviceControl;

status = WdfIoQueueCreate (FdoData->WdfDevice, &ioQueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &FdoData->IoctlQueue);

if(!NT_SUCCESS (status)){
TraceEvents(TRACE_LEVEL_ERROR, DBG_INIT, “Error Creating ioctl Queue 0x%x\n”, status);
return status;
}

status = WdfDeviceConfigureRequestDispatching(FdoData->WdfDevice, FdoData->IoctlQueue, WdfRequestTypeDeviceControl);

if(!NT_SUCCESS (status)){
TraceEvents(TRACE_LEVEL_ERROR, DBG_INIT, “Error in config’ing ioctl Queue 0x%x\n”, status);
return status;
}

Let me supply some more specifics about the behavior. I have a user mode DLL with two threads. The primary thread sends commands to the driver using DeviceIoControl calls. The second thread is calling ReadFile in a loop to get data as it becomes availble by the driver. If there is an outstanding ReadFile request into the driver the DeviceIoControl calls just hang. Am I making some kind of fundamental mistake here by doing parallel calls into the driver using the SAME FILE HANDLE in incorrect way? Maybe I have to open two handles or open the the driver with different options. I hope this helps explain why I am having issues with the two queues.

Thanks for all your help,
z

Best answer to this is to get the log. I’d also turn the WDF verifier settings on.

You can use the !wdflogdump extension, or one of the WPP trace viewing utilities (traceview, for instance). The TMF file location for your KMDF Version depends upon which version you are using [at least, the location in a WDK install differs from the one in an SP1DDK + KMDF install].

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

I have now compiled and loaded with no errors, however I have a new side effect. My IOCTLS are not getting dispatched anymore. I have two queues now, the manual one we have been discussing, and a parallel one for IOCTLS (it always worked before). Niether are marked as default. I use these calls to configure the queues:

For ioctl queue:

status = WdfDeviceConfigureRequestDispatching(FdoData->WdfDevice, FdoData->IoctlQueue, WdfRequestTypeDeviceControl);

For read queue:

status = WdfDeviceConfigureRequestDispatching(fdoData->WdfDevice, fdoData->ReadQueue, WdfRequestTypeRead);

Have I done something to bungle the ioctl dispatching by adding the read queue?

Thanks,
z


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

No problem. Let me know if you need help in getting a log set up [it took me a while to sort it out the first few times].

Glad you like it!

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 12:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

Sorry… I should have read your whole message before I replied. I think you already answered my question.

Thanks,
z

P.S. I Really like KDMF.


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

I touched upon the different commands/files to use to view the log in a
blog entry, http://blogs.msdn.com/doronh/archive/2006/07/31/684531.aspx

If you are using the 5600 build of KMDF v1.5, the symbols issue is
resolved and the public symbol servers have the correct KMDF symbols in
them.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, October 04, 2006 1:38 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

Best answer to this is to get the log. I’d also turn the WDF verifier
settings on.

You can use the !wdflogdump extension, or one of the WPP trace viewing
utilities (traceview, for instance). The TMF file location for your
KMDF Version depends upon which version you are using [at least, the
location in a WDK install differs from the one in an SP1DDK + KMDF
install].

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of zeppelin@io.com
Sent: Wednesday, October 04, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

I have now compiled and loaded with no errors, however I have a new side
effect. My IOCTLS are not getting dispatched anymore. I have two
queues now, the manual one we have been discussing, and a parallel one
for IOCTLS (it always worked before). Niether are marked as default. I
use these calls to configure the queues:

For ioctl queue:

status = WdfDeviceConfigureRequestDispatching(FdoData->WdfDevice,
FdoData->IoctlQueue, WdfRequestTypeDeviceControl);

For read queue:

status = WdfDeviceConfigureRequestDispatching(fdoData->WdfDevice,
fdoData->ReadQueue, WdfRequestTypeRead);

Have I done something to bungle the ioctl dispatching by adding the read
queue?

Thanks,
z


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Did you use the FILE_FLAG_OVERLAPPED flag when you called CreateFile?
If not, the driver will not service a second request until the first
one is completed.

Make sure you supply an OVERLAPPED structure to all of your
ReadFile/DeviceIoControl calls when you sue this flag.

You will also need to call GetOverlappedResult with the wait parameter
set to TRUE in your app when the ReadFile/DeviceIoControl all
completes with TRUE and GetLastError() returns ERROR_IO_PENDING .

Beverly

On 10/4/06, zeppelin@io.com wrote:
> Let me supply some more specifics about the behavior. I have a user mode DLL with two threads. The primary thread sends commands to the driver using DeviceIoControl calls. The second thread is calling ReadFile in a loop to get data as it becomes availble by the driver. If there is an outstanding ReadFile request into the driver the DeviceIoControl calls just hang. Am I making some kind of fundamental mistake here by doing parallel calls into the driver using the SAME FILE HANDLE in incorrect way? Maybe I have to open two handles or open the the driver with different options. I hope this helps explain why I am having issues with the two queues.
>
> Thanks for all your help,
> z
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

You need to open the handle as FILE_FLAG_OVERLAPPED (and provide the prerequisite OVERLAPPED + event handle for each i/o call) if you want concurrent async i/o. if you do not open the file as overlapped, all i/o is serialized and synchronous.

d

This requires the file handle to be open with overlapped flag, otherwise,
any operations on it from multiple threads are serialized by the mutex-kind
lock in the kernel in FILE_OBJECT.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 05, 2006 12:38 AM
Subject: RE:[ntdev] KDMF EvtIoRead with WdfIoQueueDispatchManual

> Let me supply some more specifics about the behavior. I have a user mode DLL
with two threads. The primary thread sends commands to the driver using
DeviceIoControl calls. The second thread is calling ReadFile in a loop to get
data as it becomes availble by the driver. If there is an outstanding ReadFile
request into the driver the DeviceIoControl calls just hang. Am I making some
kind of fundamental mistake here by doing parallel calls into the driver using
the SAME FILE HANDLE in incorrect way? Maybe I have to open two handles or
open the the driver with different options. I hope this helps explain why I am
having issues with the two queues.
>
> Thanks for all your help,
> z
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer