NULL Fileobject in ioctl?

Hi all,

I am writing a legacy file system driver. I’m getting a IOCTL_MOUNTMGR_QUERY_POINTS ioctl (you know, the one with ‘M’ as the devicetype)(4d0008 is the code field in the IRP). The problem I’m having is the file object is NULL. It looks like Cc is sending me the IRP, as the stack looks like this:

0: kd> kb
ChildEBP RetAddr Args to Child
f88de9f0 80e034e8 81d8e990 8134a150 81d8e990 mydriv!ImpVfsDeviceControl+0x1d6 [c:.…\devcntrl.c @ 102] f88dea20 80a266f4 80c65594 81325860 00000200 nt!IovCallDriver+0x14e
f88dea38 80c65594 81325860 000000c8 e188f120 nt!IofCallDriver+0x1a f88dec7c 80c74653 81d8e990 e188f120 6e446f49 nt!IoVolumeDeviceToDosName+0x7a
f88decd4 80c61376 81325860 00000001 00000001 nt!IopQueryNameInternal+0xbd
f88ded08 80a1581a 81325860 f88ded3c 80b1cb90 nt!IoQueryFileDosDeviceName+0x2e f88ded40 80a1848c 81fffb20 80bf5c80 81fff298 nt!CcWriteBehind+0x154 f88ded80 80af2b99 81fff298 00000000 81fffb20 nt!CcWorkerThread+0x12c f88dedac 80d391f0 81fff298 00000000 00000000 nt!ExpWorkerThread+0x10f f88deddc 80b00d32 80af2a8a 00000000 00000000 nt!PspSystemThreadStartup+0x2e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Looking at assembly, IoVolumeDeviceToDosName calls IoBuildDeviceIoControlRequest to build the IRP. Does anybody know if a NULL fileobject is normal? I assume it’s not, because Fastfat will bugcheck if so, as far as I can tell after looking at fastfat source. Anyway, does anybody know where Cc may be getting a NULL fileobject and passing it to me with this IRP, or how I could debug this further?

Also, it appears that IoQueryFileDosDeviceName is called in CcWriteBehind after delayed write is lost, if that is any help.

Any help is much appreciated.

Thanks,
Matt

For some IOCTLs, NULL fileobject is OK.

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

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Thursday, August 11, 2005 7:41 PM
Subject: [ntfsd] NULL Fileobject in ioctl?

> Hi all,
>
> I am writing a legacy file system driver. I’m getting a
IOCTL_MOUNTMGR_QUERY_POINTS ioctl (you know, the one with ‘M’ as the
devicetype)(4d0008 is the code field in the IRP). The problem I’m having is
the file object is NULL. It looks like Cc is sending me the IRP, as the stack
looks like this:
>
> 0: kd> kb
> ChildEBP RetAddr Args to Child
> f88de9f0 80e034e8 81d8e990 8134a150 81d8e990 mydriv!ImpVfsDeviceControl+0x1d6
[c:.…\devcntrl.c @ 102] f88dea20 80a266f4 80c65594 81325860 00000200
nt!IovCallDriver+0x14e
> f88dea38 80c65594 81325860 000000c8 e188f120 nt!IofCallDriver+0x1a f88dec7c
80c74653 81d8e990 e188f120 6e446f49 nt!IoVolumeDeviceToDosName+0x7a
> f88decd4 80c61376 81325860 00000001 00000001 nt!IopQueryNameInternal+0xbd
> f88ded08 80a1581a 81325860 f88ded3c 80b1cb90 nt!IoQueryFileDosDeviceName+0x2e
f88ded40 80a1848c 81fffb20 80bf5c80 81fff298 nt!CcWriteBehind+0x154 f88ded80
80af2b99 81fff298 00000000 81fffb20 nt!CcWorkerThread+0x12c f88dedac 80d391f0
81fff298 00000000 00000000 nt!ExpWorkerThread+0x10f f88deddc 80b00d32 80af2a8a
00000000 00000000 nt!PspSystemThreadStartup+0x2e 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16
>
> Looking at assembly, IoVolumeDeviceToDosName calls
IoBuildDeviceIoControlRequest to build the IRP. Does anybody know if a NULL
fileobject is normal? I assume it’s not, because Fastfat will bugcheck if so,
as far as I can tell after looking at fastfat source. Anyway, does anybody
know where Cc may be getting a NULL fileobject and passing it to me with this
IRP, or how I could debug this further?
>
> Also, it appears that IoQueryFileDosDeviceName is called in CcWriteBehind
after delayed write is lost, if that is any help.
>
> Any help is much appreciated.
>
> Thanks,
> Matt
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks Max. I have a question then. In FatFsdDeviceControl(), in devcntrl.c, FAT calls CanFsdWait, which is really a call to IoIsOperationSynchronous, which actually accesses the flags field of a FILE_OBJECT. If it is supposed to handle NULL Fileobject cases, how could this actually work for FAT without an access violation?

IrpContext = FatCreateIrpContext( Irp, CanFsdWait( Irp ));

Matt

FSD’s IRPs must have a valid file object, really so. Not so with disk’s and
most other IRPs.

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

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Friday, August 12, 2005 8:58 PM
Subject: RE: [ntfsd] NULL Fileobject in ioctl?

> Thanks Max. I have a question then. In FatFsdDeviceControl(), in
devcntrl.c, FAT calls CanFsdWait, which is really a call to
IoIsOperationSynchronous, which actually accesses the flags field of a
FILE_OBJECT. If it is supposed to handle NULL Fileobject cases, how could this
actually work for FAT without an access violation?
>
> IrpContext = FatCreateIrpContext( Irp, CanFsdWait( Irp ));
>
> Matt
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com