Easiest way to get the volume file system type (FAT16 or NTFS or ..) in AddDevice of upper filter?

Hi,

I have an upper filter, and i want to detect the file system type of a partition (FAT16, FAT32, NTFS, etc), in my add device (or in my pre write). I read about GetVolumeInformation, but that’s for user mode.
So what is the standard approach for finding the the file system type of a partition in AddDevice?

Note that i have already implemented the detection of volumes in my AddDevice, by using IoGetDeviceProperty with GUID class, on the PDO, and comparing the guid with the volume guid.

Now all i wonder is, what is the standard way of getting the file system type at this point, in my AddDevice?

I also tried to read the content of the volume, but IoCallDriver on the PDO returns STATUS_NO_SUCH_DEVICE.

It would be unusual to do this in AddDevice.

Of course, it would be unusual to even have an AddDevice these days.

So…

  1. What is the larger goal you are trying to achieve. Usually this “I need to do this in AddDevice” is the sign that somebody wants to determine if they should instantiation their filter… and this is not the right way to do things.
  2. Why are you not writing this driver using WDF?

Peter

@“Peter_Viscarola_(OSR)” said:
It would be unusual to do this in AddDevice.

Of course, it would be unusual to even have an AddDevice these days.

So…

  1. What is the larger goal you are trying to achieve. Usually this “I need to do this in AddDevice” is the sign that somebody wants to determine if they should instantiation their filter… and this is not the right way to do things.
  2. Why are you not writing this driver using WDF?

Peter

Hi Peter,

  1. I am trying to detect FileSystem type and also block writes to beginning sectors of the volumes (VBR), and not block it in certain file systems.

  2. I am not experienced with WDF as of right now.

Currently, i solved this problem by doing the reading in the Write callback, i first check if its a volume type (i detect this in my addDevice and add it to device extension), and if it is, then i read the first sector to detect file system type using IoBuldSynchrounousFsdRequest + IoCallDriver. Will this have any issues?

Also, when i use IoCallDriver and it returns STATUS_PENDING, i KeWaitSingleObject with Executive, KernelMode, and Infinite timeout. Considering that i don’t give it a timeout time, Can this have any issue? for example waiting forever for whatever reason and getting a BSOD? note that all of these happen only if the device type is volume (based on guid), and there is a write happening on the first sector (VBR).

And I’m not sure why, but in a file system detection sample from OSR that i found, you guys used Suspended instead of Executive for reading the sectors i assume, what is the difference? Does it matter which one i use?
https://www.osronline.com/article.cfm^id=79.htm

Hmmmm… Well… you’re referring to a 15 year old article on File System Recognizer drivers. I’m not sure that would be your best reference.

And, clearly, you’re having issues… and as for “I am not experienced in WDF as of right now” – No offense intended, but it doesn’t sound like you’re really THAT experienced in WDM, given the questions you’re asking. And, believe me, almost nobody… even somebody who’s VERY experienced in WDM… should be writing WDM code. You’ll be happier if you do this in WDF. I promise you.

and not block it in certain file systems

Right. OK… well, then the place to do this is NOT as part of AddDevice. Do it when you get the first write… and, store it for later. That should be fine.

Considering that i don’t give it a timeout time, Can this have any issue

No. That should be fine. The only time you’ll “wait forever” is if the underlying driver stack loses your IRP… which, of course, would be a Very Bad Thing.

you guys used Suspended instead of Executive

… in KeWaitForSingleObject? The WaitReason is almost entirely decorative. That is to say, for almost all cases, the reason you choose has no impact at all on anything… except on what’s displayed.

Peter

@“Peter_Viscarola_(OSR)” said:
Right. OK… well, then the place to do this is NOT as part of AddDevice. Do it when you get the first write… and, store it for later. That should be fine.

Considering that i don’t give it a timeout time, Can this have any issue

No. That should be fine. The only time you’ll “wait forever” is if the underlying driver stack loses your IRP… which, of course, would be a Very Bad Thing.

you guys used Suspended instead of Executive

… in KeWaitForSingleObject? The WaitReason is almost entirely decorative. That is to say, for almost all cases, the reason you choose has no impact at all on anything… except on what’s displayed.

Peter

Thank you for the help Peter.
I wanted to check if there is any easier approach than sending a read IRP to detect files system during write, for example by using IoGetDeviceProperty in AddDevice, but based on the answers i will stick with the reading the first sector in write requests. And yes, moving to WDF is in my plans.