VSS VolSnap.Sys I/O Control Codes

Hi!

As customer is facing a strange problem during VSS snapshot creation. We have created a trace with vsstrace.exe and the log shows that it times out after sending the 0x53c008 control code, which seems to be related to snapshot preparation.

Anyone has eventually an idea what this control code does? Some are documented and show up in the DDK’s header files but this one is not. It is function 2. It eventually times out after around 20 minutes in our case and then the semaphore timed out error is reported back to the application trying to do the snapshot, in this case the Windows built-in MMC computer management snap-in that we use to create a snapshot. The volume that we try to snapshot s on a storage system connected over iSCSI.

I could find 4 defined macros:
IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES → Function 0
IOCTL_VOLSNAP_RELEASE_WRITES → Function 1
IOCTL_VOLSNAP_COMMIT_SNAPSHOT → Function 4
IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT → Function 5

Thanks for any info!

Andreas

It’s device 0x53 (according to the ioctl decoder)

FILE_DEVICE_VIRTUAL_BLOCK 0x00000053

Thanks for the reply…

I found this in the header file

#ifndef VOLSNAPCONTROLTYPE
#define VOLSNAPCONTROLTYPE 0x00000053 // 'S'
#endif

#ifndef IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES
#define IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 0, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_RELEASE_WRITES
#define IOCTL_VOLSNAP_RELEASE_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 1, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 4, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 5, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

So the one I am looking for would be this one:

#ifndef IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION
#define IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION CTL_CODE(VOLSNAPCONTROLTYPE, 2, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

I didn’t know this IO decoder. It’s cool, but unfortunately it doesn’t seem to know this control code. It decodes the parameters accordingly to function 0x2, FILE_ANY_ACCESS and METHOD_BUFFERED. :slight_smile:

It is invoked by VSS as we could find in the trace:
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0175) SWPRV] . ENTER[CVssQueuedSnapshot::PrepareForSnapshotIoctl]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . ENTER[CVssQueuedSnapshot::GetSnapshotProperties]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . EXIT[CVssQueuedSnapshot::GetSnapshotProperties] Time spent: 00:00:00-0000; total: 0; HRESULT: 0
[10:32:38.113 P:27F0 T:2FF8 INCICHLH(0451) IOCTL] . IOCTL sent: 53c008 on device \?\Volume{fa1a60fe-87a8-4c84-9cbd-96b7d3b2ac25}

It then times out after like 20 minutes.

Interesting, lost reply. Mods?

Anyway I thought of something else to do - which is to look for the device code inside the snapshot driver and see whether it’s location (ln tells you anything).

This control code is sent by VSS to the volsnap device driver.

This is what I found in the header file:
#ifndef VOLSNAPCONTROLTYPE
#define VOLSNAPCONTROLTYPE 0x00000053 // 'S'
#endif

#ifndef IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES
#define IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 0, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_RELEASE_WRITES
#define IOCTL_VOLSNAP_RELEASE_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 1, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 4, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 5, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

So the one I am looking for would be this one:
#ifndef IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION
#define IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION CTL_CODE(VOLSNAPCONTROLTYPE, 2, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

I didn’t know this decoder, it’s cool and it got the parameters correctly like function, access and method. :slight_smile:

We found this IO being sent by VSS to volsnap during snapshot preparation when attempting to create a volume snapshot over iSCSI:
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0175) SWPRV] . ENTER[CVssQueuedSnapshot::PrepareForSnapshotIoctl]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . ENTER[CVssQueuedSnapshot::GetSnapshotProperties]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . EXIT[CVssQueuedSnapshot::GetSnapshotProperties] Time spent: 00:00:00-0000; total: 0; HRESULT: 0
[10:32:38.113 P:27F0 T:2FF8 INCICHLH(0451) IOCTL] . IOCTL sent: 53c008 on device \?\Volume{fa1a60fe-87a8-4c84-9cbd-9fb2d342af21}

It waits for like 20 minutes and then we get a semaphore timedout.

Mods? Did I violate some rules?? Or maybe it’s my attempt to use the code quote thing.

I try again…will try WinDbg on my test system.

This control code is sent by VSS to the volsnap device driver.

This is what I found in the header file:
#ifndef VOLSNAPCONTROLTYPE
#define VOLSNAPCONTROLTYPE 0x00000053 // 'S'
#endif

#ifndef IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES
#define IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 0, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_RELEASE_WRITES
#define IOCTL_VOLSNAP_RELEASE_WRITES CTL_CODE(VOLSNAPCONTROLTYPE, 1, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 4, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

#ifndef IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT
#define IOCTL_VOLSNAP_END_COMMIT_SNAPSHOT CTL_CODE(VOLSNAPCONTROLTYPE, 5, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

So the one I am looking for would be this one:
#ifndef IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION
#define IOCTL_VOLSNAP_DONT_KNOW_THIS_FUNCTION CTL_CODE(VOLSNAPCONTROLTYPE, 2, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
#endif

I didn’t know this decoder, it’s cool and it got the parameters correctly like function, access and method. :slight_smile:

We found this IO being sent by VSS to volsnap during snapshot preparation when attempting to create a volume snapshot over iSCSI:
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0175) SWPRV] . ENTER[CVssQueuedSnapshot::PrepareForSnapshotIoctl]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . ENTER[CVssQueuedSnapshot::GetSnapshotProperties]
[10:32:38.113 P:27F0 T:2FF8 SPRQSNPC(0550) SWPRV] . . EXIT[CVssQueuedSnapshot::GetSnapshotProperties] Time spent: 00:00:00-0000; total: 0; HRESULT: 0
[10:32:38.113 P:27F0 T:2FF8 INCICHLH(0451) IOCTL] . IOCTL sent: 53c008 on device ?\Volume{fa1a60fe-87a8-4c84-9cbd-9fb2d342af21}

It waits for like 20 minutes and then we get a semaphore timed out.

Mods? Did I violate some rules??
Usually its due to too many edits…

Mods? Did I violate some rules?? Or maybe it’s my attempt to use the code quote thing.

From the sticky at the top of the NTDEV list:

If you post something to the forum and it does not immediately appear (or if you edit and existing post and the post you’re editing disappears) it is most likely that your post has been caught in the spam filters. This is particularly likely if you’re a new user.

If you edit an existing post several times in a row, it is also possible to trigger the “flood control” mechanism, which is designed to prevent people (like spammer or DDOSers) posting too many successive messages.

If this happens to you, there are two things you can do:

  1. Chill for a bit and wait for a mod/admin to notice. If it’s not spam, we’ll mark it as such. If you’ve been around awhile and/or your post is clearly technical and not lame, we’ll mark your account as being known good, so you will never get caught in the spam filters again.

  2. Post a plea in the A&A section of the Community for the mods/admins to approve your post.

What I’d appreciate is you not posting the same query again. This just makes more work for the mods (we have to merge the replies, delete one of the posts, etc.).

I’d also appreciate you not emailing the mods, including me, asking for your post to be “liberated” from the spam queue. We have the A&A section for a reason. Contacting the mods is that reason.

Thank you for the explanation. I think I caused a flood. :slight_smile:

Are you responsible for any software related/involved in this backup? Or is this a problem on a machine you’re trying to debug?

Yes and no. I am trying to debug this machine. We have a migration software not a backup solution (and I am responsible for it), using snapshots as well, but we have already isolated the issue to occur without us being involved. The problem occurs if initiating a volume snapshot with the Windows interface (“Create new” button in the “VSS” tab of the drive properties"). There is also a 3rd party backup software installed on this system with their own VSS provider, but it is not being used by Windows, visible in the VSSTrace created while the “Create New” button was pushed.

I now see my duplicate post above, sorry for flooding. I hope nobody drowned.

Problem has been resolved.

Due to low disk space, there were some profiles stuck in HKey_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\ProfileList, having keys below it ending in “.BAK”. This caused the VSS “Shadow Copy Optimization Writer” to disappear during VSS snapshots (if checking with vssadmin list writers).

Additionally the customer discovered that there was a driver missing of the 3rd party backup solution, that was reinstalled, I think through “Update Driver”. Then VSS started working again. Usually a re-installation (or de-installation to test) of 3rd party backup software is recommended as part of the troubleshooting.

Just to leave that for the after world in case someone finds the same strange control code in a VSS trace. :slight_smile: