IRP_MJ_FLUSH_BUFFERS and IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES

NTFSD
1

Hi,

I’m triggering a create snapshot operation using VSHADOW.
I expect the IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES to be sent to the volume device object at least once but it doesn’t look like it is sent anytime throughout the course of the snapshot operation.
I do see IRP_MJ_FLUSH_BUFFERS though.

I first tried to capture the IOCTL in my volume filter driver but never got lucky.
I thought maybe I’m doing something wrong in the driver implementation perhaps.
So I used IRP tracker and it was confirmed that the IOCTL is never received.
None of the IOCTLs had an IO control code of 0x53c000 which represents IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES.
I obtained this value for the IO control code from here:
http://www.ioctls.net/

What exactly is going on here…??
Why don’t I see the well documented IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES…?

I’m testing this on Windows Server 2003 32-bit OS.
I’ve installed VSS SDK 7.2

2

Alright here are some more observations:

All this while I was selecting the required volume’s device object to track IRPs for.
This time I selected the Device object for VOLSNAP driver and the IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES did appear.

The reason why I didn’t see it earlier because it was completed by VOLSNAP itself.
So the rest of the drivers in the stack didn’t get a chance to process the IOCTL.

What could be the special case here…??
Why did VOLSNAP complete the IOCTL at it’s level without giving others a chance at all…??

One thing to note here is that I didn’t make any changes on the volume in between 2 consecutive snapshots.
I had copied just one file of size 1 KB on the volume in the beginning and have been taking snapshots of the volume without adding/modifying any files to/on the volume.

Any help would be greatly appreciated.

3

>Why did VOLSNAP complete the IOCTL at it’s level without giving others a

chance at all…??

This is a VolSnap IOCTL and therefore it is completed by VolSnap. This is as
designed, the expectation is that only drivers above VolSnap are to process
this request.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Alright here are some more observations:

All this while I was selecting the required volume’s device object to track
IRPs for.
This time I selected the Device object for VOLSNAP driver and the
IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES did appear.

The reason why I didn’t see it earlier because it was completed by VOLSNAP
itself.
So the rest of the drivers in the stack didn’t get a chance to process the
IOCTL.

What could be the special case here…??
Why did VOLSNAP complete the IOCTL at it’s level without giving others a
chance at all…??

One thing to note here is that I didn’t make any changes on the volume in
between 2 consecutive snapshots.
I had copied just one file of size 1 KB on the volume in the beginning and
have been taking snapshots of the volume without adding/modifying any files
to/on the volume.

Any help would be greatly appreciated.

4

Hi Scott,

Thank you for your response.
The MSDN page for this IOCTL states:

"This IOCTL is issued as an IRP_MJ_DEVICE_CONTROL request that is sent only to the volume device object of a local file system and to file system filter drivers that may have attached to that volume. "

It states that the IOCTL is sent to the “volume device object”.
Moreover there are plenty of discussions on OSR where people are using this IOCTL in their volume filter drivers to get notified about a VSS snapshot operation.

There’s got to be a special case for which the IOCTL is completed by VOLSNAP itself.

5

I guess that the people that see this are attached above Volsnap. What does the stack look like in your case ? Where does your filter attach ?

Thanks,
Alex.
On Oct 21, 2013, at 11:02 AM, xxxxx@gmail.com wrote:

Hi Scott,

Thank you for your response.
The MSDN page for this IOCTL states:

"This IOCTL is issued as an IRP_MJ_DEVICE_CONTROL request that is sent only to the volume device object of a local file system and to file system filter drivers that may have attached to that volume. "

It states that the IOCTL is sent to the “volume device object”.
Moreover there are plenty of discussions on OSR where people are using this IOCTL in their volume filter drivers to get notified about a VSS snapshot operation.

There’s got to be a special case for which the IOCTL is completed by VOLSNAP itself.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

I’m not guessing. VolSnap is the function driver for volumes (VolMgr is the
bus driver), if you want to see this IOCTL you must sit above the volume
function driver.

-scott
OSR

“Alex Carp” wrote in message news:xxxxx@ntfsd…

I guess that the people that see this are attached above Volsnap. What does
the stack look like in your case ? Where does your filter attach ?

Thanks,
Alex.
On Oct 21, 2013, at 11:02 AM, xxxxx@gmail.com wrote:

Hi Scott,

Thank you for your response.
The MSDN page for this IOCTL states:

"This IOCTL is issued as an IRP_MJ_DEVICE_CONTROL request that is sent
only to the volume device object of a local file system and to file system
filter drivers that may have attached to that volume. "

It states that the IOCTL is sent to the “volume device object”.
Moreover there are plenty of discussions on OSR where people are using
this IOCTL in their volume filter drivers to get notified about a VSS
snapshot operation.

There’s got to be a special case for which the IOCTL is completed by
VOLSNAP itself.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

> There’s got to be a special case for which the IOCTL is completed by VOLSNAP itself.

It is always pended and completed by VolSnap, regardless of what the actual snapshot provider is (be it, say, an SCSI-based client of some external SAN box which does the actual snapshot or so).

Layers below VolSnap are just unaware of flush-and-hold, this is by design.

Even though flush-and-hold is only documented by MSDN for FS filters, you can also use it in volume filters, but… these volume filters must be above VolSnap.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

8

> I’m not guessing. VolSnap is the function driver for volumes (VolMgr is the

This is just a random choice by MS. In XP, it was UpperFilter.

What is important here is that the lower part of flush-and-hold state machine is in VolSnap (the upper one is in VSSVC.EXE). And, this is true regardless of what VSS snapshot provider is used.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

9

“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd…

This is just a random choice by MS. In XP, it was UpperFilter.

It has practical implications on modern Windows releases. Because it is the
FDO, it means that volume upper filters always go above VolSnap and lower
filters always go below. There was no architected way to guarantee ordering
relative to VolSnap in pre-Vista releases.

-scott
OSR

“Maxim S. Shatskih” wrote in message news:xxxxx@ntfsd…

I’m not guessing. VolSnap is the function driver for volumes (VolMgr is
the

This is just a random choice by MS. In XP, it was UpperFilter.

What is important here is that the lower part of flush-and-hold state
machine is in VolSnap (the upper one is in VSSVC.EXE). And, this is true
regardless of what VSS snapshot provider is used.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com