Possible spurious KWDF verifier message on KWDF 1.7?

NTDEV
1

Hi all,
I am now trying to see whether my WDF driver works with the new KWDF (1.7 -From WD 6001.18000 RTM).
The test machine I checked is a new one with some other 3rd party drivers, therefore I cannot comment if the issue is a new thing or happened on 1.5 as well.
The problem appears when some 3rd party driver send my driver an IRP with FILE_OBJECT that is NULL. My driver expects only IRPs with FILE_OBJECT (Following a successful IRP_MJ_CREATE). When my driver called WdfRequestGetFileObject on the WDFREQUEST, I saw the following message in windbg:

KMDF detected potentially invalid operation by rxfcp.sys. Turn on framework verifier to break into the debugger.

Now, my driver checks the return value of WdfRequestGetFileObject and fail the WDFREQUEST if this is NULL. Therefore I don’t understand why KMDF complain at all.
Checking KWDF logs I see:
…
44: FxFileObject::GetFileObjectFromWdm - NULL passed for PFILE_OBJECT when FileObject support is requested in an I/O request.

So is it just a KWDF issue (Someone fogot to remove a printf) or is there something more deep that I need to change my code to deal with?

Thanks,
Eran.

2

What did you set FileObjectClass to?

On Feb 6, 2008 5:14 AM, wrote:

> Hi all,
> I am now trying to see whether my WDF driver works with the new KWDF (1.7-From WD
> 6001.18000 RTM).
> The test machine I checked is a new one with some other 3rd party drivers,
> therefore I cannot comment if the issue is a new thing or happened on 1.5as well.
> The problem appears when some 3rd party driver send my driver an IRP with
> FILE_OBJECT that is NULL. My driver expects only IRPs with FILE_OBJECT
> (Following a successful IRP_MJ_CREATE). When my driver called
> WdfRequestGetFileObject on the WDFREQUEST, I saw the following message in
> windbg:
>
> -----------------------------------------------------------------------------------------------
> KMDF detected potentially invalid operation by rxfcp.sys. Turn on
> framework verifier to break into the debugger.
>
> -------------------------------------------------------------------------------------
>
> Now, my driver checks the return value of WdfRequestGetFileObject and fail
> the WDFREQUEST if this is NULL. Therefore I don’t understand why KMDF
> complain at all.
> Checking KWDF logs I see:
> …
> 44: FxFileObject::GetFileObjectFromWdm - NULL passed for PFILE_OBJECT when
> FileObject support is requested in an I/O request.
>
> So is it just a KWDF issue (Someone fogot to remove a printf) or is there
> something more deep that I need to change my code to deal with?
>
> Thanks,
> Eran.
>
>
>
> —
> 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
>

–
Mark Roddy

3

Hi,
I’v set it to WdfFileObjectWdfCanUseFsContext.

Thanks,
Eran.

4

When this value is set, KMDF assumes that all read/write/ioctl irps coming in will have a valid PFILE_OBJECT on them (b/c the contract on WdfRequestGetFileObject cannot fail, e.g. it is a “get” function, not a “retrieve” function which can fail). Is this a storage or FS related driver?

We have a feature in post 1.7 that relaxes the contract and kmdf will not require the pfile_object to be present, but by making this setting in the driver, it is up to you in the driver to check the value of WdfRequestGetFileObject for != NULL before using it.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@topio.com
Sent: Wednesday, February 06, 2008 7:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Possible spurious KWDF verifier message on KWDF 1.7?

Hi,
I’v set it to WdfFileObjectWdfCanUseFsContext.

Thanks,
Eran.

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,
My driver is storage related. It acts as a function driver for an HBA port, but instead of going the miniport/storport path, it does everything internally (Thus hiding the SAN that it sees from windows).
Accidentally, we had a multipath driver installed on the machine. This driver installed itself as a filter and layered itself in my device stack. When a device is added, the 3rd party driver starts sending IOCTLs without first doing CreateFile. I guess he can do it because this is the “expected” behaviour of such a stack (After all it is layered above me). The machine is intended to act as an appliance, and therefore we will make sure that at customers, this driver isn’t installed.
Nevertheless, my code is checking the return value of the WdfRequestGetFileObject to avoid exactly such issues. Do you foresee any issues with my code doing this with WDF 1.7?
Thanks,
Eran.

6

Are you using the WDFFILEOBJECT or the contex on it for anything? If not, I would just remove this entirely. If you must have it, check the return value and you can ignore the warning but IIRC you will have a dbg break when the contract is violated.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@topio.com
Sent: Thursday, February 07, 2008 2:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Possible spurious KWDF verifier message on KWDF 1.7?

Hi,
My driver is storage related. It acts as a function driver for an HBA port, but instead of going the miniport/storport path, it does everything internally (Thus hiding the SAN that it sees from windows).
Accidentally, we had a multipath driver installed on the machine. This driver installed itself as a filter and layered itself in my device stack. When a device is added, the 3rd party driver starts sending IOCTLs without first doing CreateFile. I guess he can do it because this is the “expected” behaviour of such a stack (After all it is layered above me). The machine is intended to act as an appliance, and therefore we will make sure that at customers, this driver isn’t installed.
Nevertheless, my code is checking the return value of the WdfRequestGetFileObject to avoid exactly such issues. Do you foresee any issues with my code doing this with WDF 1.7?
Thanks,
Eran.

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,
Indeed I use the context from WDFFILEOBJECT so I have to keep it.
What do you mean by “dbg break” when the contract is violated?
I did notice that if I turn on WDF verifier than Windbg is invoked. Are you referring to that or to other behaviour?

Many thanks!!
Eran.