Wdf driver: DTM failure at CHAOS test.

Hi all,

I’m struggling on an issue that the DTM test exposed and I’d like to know from you if anything comes to your mind.

I wrote an HID filter driver using the kmdf framework and, at least functionally, seems to work just fine. I then went on testing it with the DTM and I found this failure during the CHAOS test. I have a minidump and I’m trying to gather something out of it but I can’t make much sense of it: the failure happens into a completion routine of an IoRead on a WdfRequestRetrieveOutputBuffer. Interestingly enough the stack trace shows a GetMemory in the framework just before the crash and wdfcrashdump shows as last log

GetMemoryObject - Unrecognized Major Function 0x0 on WDFDEVICE 0x0000057FFCFEA738 WDFREQUEST 0x0000057FFCA83B28

From the docs it seems that the only way for WdfRequestRetrieveOutputBuffer to crash is to provide an invalid request handle. A few lines of code before that though, I call WdfRequestGetFileObject on that very same request and that goes through successfully. Also I don’t even know if I have a way to check for sanity of the request handle even if I wanted to.

Does anybody know if there’s a deeper meaning to this?

Thank you so much in advance for your help,
Marco.

Are you creating this request in your driver or using a queue presented request? I am guessing it is the first one b/c of this
GetMemoryObject - Unrecognized Major Function 0x0 on WDFDEVICE 0x0000057FFCFEA738 WDFREQUEST 0x0000057FFCA83B28

Because this means that the current stack location (yours) is not formatted (while IRP_MJ_CREATE is 0x0, I doubt you are forwarding a create creating as a read down the stack). If this is a driver created request, RetrieveInput/OutputBuffer do not make sense b/c those operate on the current stack location (which is invalid). When you format a request (for read, write,etc) you are formatting the /next/ stack location, not yours (the current)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@laurenzano.it
Sent: Friday, March 12, 2010 9:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf driver: DTM failure at CHAOS test.

Hi all,

I’m struggling on an issue that the DTM test exposed and I’d like to know from you if anything comes to your mind.

I wrote an HID filter driver using the kmdf framework and, at least functionally, seems to work just fine. I then went on testing it with the DTM and I found this failure during the CHAOS test. I have a minidump and I’m trying to gather something out of it but I can’t make much sense of it: the failure happens into a completion routine of an IoRead on a WdfRequestRetrieveOutputBuffer. Interestingly enough the stack trace shows a GetMemory in the framework just before the crash and wdfcrashdump shows as last log

GetMemoryObject - Unrecognized Major Function 0x0 on WDFDEVICE 0x0000057FFCFEA738 WDFREQUEST 0x0000057FFCA83B28

From the docs it seems that the only way for WdfRequestRetrieveOutputBuffer to crash is to provide an invalid request handle. A few lines of code before that though, I call WdfRequestGetFileObject on that very same request and that goes through successfully. Also I don’t even know if I have a way to check for sanity of the request handle even if I wanted to.

Does anybody know if there’s a deeper meaning to this?

Thank you so much in advance for your help, Marco.


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

Do you have driver verifier and WDF verifier enabled for your driver? If
not, you could try reproducing the problem with driver verifier and WDF
verifier enabled on your driver.

From the log message, it appears that the major function for the IRP’s
current stack location is 0x0 which corresponds to a create request. That
doesn’t seem right, given that you say it is a read request.

wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I’m struggling on an issue that the DTM test exposed and I’d like to know
> from you if anything comes to your mind.
>
> I wrote an HID filter driver using the kmdf framework and, at least
> functionally, seems to work just fine. I then went on testing it with the
> DTM and I found this failure during the CHAOS test. I have a minidump and
> I’m trying to gather something out of it but I can’t make much sense of
> it: the failure happens into a completion routine of an IoRead on a
> WdfRequestRetrieveOutputBuffer. Interestingly enough the stack trace shows
> a GetMemory in the framework just before the crash and wdfcrashdump shows
> as last log
>
> GetMemoryObject - Unrecognized Major Function 0x0 on WDFDEVICE
> 0x0000057FFCFEA738 WDFREQUEST 0x0000057FFCA83B28
>
> From the docs it seems that the only way for
> WdfRequestRetrieveOutputBuffer to crash is to provide an invalid request
> handle. A few lines of code before that though, I call
> WdfRequestGetFileObject on that very same request and that goes through
> successfully. Also I don’t even know if I have a way to check for sanity
> of the request handle even if I wanted to.
>
> Does anybody know if there’s a deeper meaning to this?
>
> Thank you so much in advance for your help,
> Marco.
>

Thank you.

Your comments have been truly enlightening.

Just for the records, the issued turned out to be quite mundane: a copy/paste had gone bad and the completion routine for the IoRead was wrongly set also for the Create.