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?
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
Thanks again!
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.
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
Beautiful! Thanks for your patience and insight. Both are great appreciated.