Wrong WDFFILEOBJECT passed to EvtDeviceFileCreate

NTDEV
1

I’ve provided callbacks for FileCreate and close in an effort to limit the number of writters to my device. However, it appears I’m an incorrect FILEOBJECT handle in when my callback gets called. Here’s how I’ve defined my callbacks:

// in EvtDeviceAdd()
…
WDF_FILEOBJECT_CONFIG fileObjectConfig;
WDF_OBJECT_ATTRIBUTES fileObjAttributes;

WDF_OBJECT_ATTRIBUTES_INIT(&fileObjAttributes);
fileObjAttributes.SynchronizationScope = WdfSynchronizationScopeNone;
WDF_FILEOBJECT_CONFIG_INIT(
&fileObjectConfig,
MyEvtDeviceFileCreate, // Create
MyEvtFileClose, // Close
WDF_NO_EVENT_CALLBACK // Cleanup
);
WdfDeviceInitSetFileObjectConfig(
DeviceInit,
&fileObjectConfig,
&fileObjAttributes // Tried with WDF_NO_OBJECT_ATTRIBUTES also
);

// in openclose.cpp – Not that you really care
VOID
MyEvtDeviceFileCreate(IN WDFDEVICE Device, IN WDFREQUEST Request,
IN WDFFILEOBJECT FIleObject)
{
PFILE_OBJECT wdmFileObject = WdfFileObjectWdmGetFileObject(FileObject);
DbgBreakPoint();
}

When I watch wdmFileObject, it doesn’t appear to be my file object at all. The ReadAccess, and WriteAccess don’t match how I opened it, and if I use WinDbg to look at the FILE_OBJECT it doesn’t match. I’m doing the following to look at the FILE_OBJECT using WinDbg:

kd>!handle
// I look at the handle table and find the location of my handle
kd>dt nt!_FILE_OBJECT

This method has the appropriate FileName and ReadAccess, and WriteAccess so that’s great.

Am I failing to use the proper techniques to get at the FileObject in my driver so that I can check the WriteAccess and ultimately accomplish my goal?

2

  1. make sure you are building a driver w/out optimization. For instance the optimizer might see that you do not touch wdmFileObject and never assign it. What does eax contain after the call to WdfFileObjectWdmGetFileObject?

  2. __debugbreak() will be a little better for you I think. It will not introduce another frame on the stack and let you look at the registers immediately.

  3. PFILE_OBJECT is pointer, not a handle. So use !object if you want to see its validity

    4) requested permissions do not live in the file object, they are in the current irp stack location.

    PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(WdfRequestWdmGetIrp(Request));

    if (stack->Parameters.Create.SecurityContext->DesiredAccess & FILE_WRITE_DATA) {

    etc etc

    5) you want EvtFileCleanup, not close if you are tracking state. Cleanup()) will be called when the handle is closed in UM, Close() will be called when the last reference on the pfile_object is released which may be a long time afterward.

    d

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
    Sent: Thursday, February 28, 2008 4:08 PM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] Wrong WDFFILEOBJECT passed to EvtDeviceFileCreate

    I’ve provided callbacks for FileCreate and close in an effort to limit the number of writters to my device. However, it appears I’m an incorrect FILEOBJECT handle in when my callback gets called. Here’s how I’ve defined my callbacks:

    // in EvtDeviceAdd()
    …
    WDF_FILEOBJECT_CONFIG fileObjectConfig;
    WDF_OBJECT_ATTRIBUTES fileObjAttributes;

    WDF_OBJECT_ATTRIBUTES_INIT(&fileObjAttributes);
    fileObjAttributes.SynchronizationScope = WdfSynchronizationScopeNone;
    WDF_FILEOBJECT_CONFIG_INIT(
    &fileObjectConfig,
    MyEvtDeviceFileCreate, // Create
    MyEvtFileClose, // Close
    WDF_NO_EVENT_CALLBACK // Cleanup
    );
    WdfDeviceInitSetFileObjectConfig(
    DeviceInit,
    &fileObjectConfig,
    &fileObjAttributes // Tried with WDF_NO_OBJECT_ATTRIBUTES also
    );

    // in openclose.cpp – Not that you really care
    VOID
    MyEvtDeviceFileCreate(IN WDFDEVICE Device, IN WDFREQUEST Request,
    IN WDFFILEOBJECT FIleObject)
    {
    PFILE_OBJECT wdmFileObject = WdfFileObjectWdmGetFileObject(FileObject);
    DbgBreakPoint();
    }

    When I watch wdmFileObject, it doesn’t appear to be my file object at all. The ReadAccess, and WriteAccess don’t match how I opened it, and if I use WinDbg to look at the FILE_OBJECT it doesn’t match. I’m doing the following to look at the FILE_OBJECT using WinDbg:

    kd>!handle
    // I look at the handle table and find the location of my handle
    kd>dt nt!_FILE_OBJECT

    This method has the appropriate FileName and ReadAccess, and WriteAccess so that’s great.

    Am I failing to use the proper techniques to get at the FileObject in my driver so that I can check the WriteAccess and ultimately accomplish my goal?

    —
    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

3

Thanks Doron!

The documenation was a little misleading to me, I saw ReadAccess, and WriteAccess as members of a FILE_OBJECT, so I thought I was home free. I’ll give it a try using the irp stack location as you suggested. Oh, and thanks for the heads up on the cleanup also… I know better than to do that; or at least I thought I did :wink: Thanks again!

4

Alright, so using the irp stack location I was able to determine file access requested. However, on the cleanup end I’m having difficulty determining which file is attempting to close. All I have access to is the WDFFILEOBJECT and I still have the problem where that file object doesn’t appear to actually be my file object as the filename is NULL, and numerous other member of the FILEOBJECT appear to be incorrect.

So, how can I make sure that the file object I am cleaning up is the one that requested write permissions? If the FILEOBJECT was correct, I could keep track of which files were opened with which permissions and continue on my way.

5

The filename in a file object is only valid during create, afterwards it is freed. What other fields in the PFILE_OBJECT are invalid?

The solution here is to store the state you want as a context on the WDFFILEOBJECT. In your device init function where you register the create/cleanup functions you can specify a WDF_OBJECT_ATTRIBUTES. Init an attributes with a context type and pass it in. One field in this context is a BOOLEAN WriteAccessGranted (or whatever your semantic is) field which you set in the file object create callback and check in the file cleanup callback.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, February 29, 2008 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Wrong WDFFILEOBJECT passed to EvtDeviceFileCreate

Alright, so using the irp stack location I was able to determine file access requested. However, on the cleanup end I’m having difficulty determining which file is attempting to close. All I have access to is the WDFFILEOBJECT and I still have the problem where that file object doesn’t appear to actually be my file object as the filename is NULL, and numerous other member of the FILEOBJECT appear to be incorrect.

So, how can I make sure that the file object I am cleaning up is the one that requested write permissions? If the FILEOBJECT was correct, I could keep track of which files were opened with which permissions and continue on my 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

6

Beautiful! Thanks for your patience and insight. Both are great appreciated.