Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


VSS VolSnap.Sys I/O Control Codes

Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9

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

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,137

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

    FILE_DEVICE_VIRTUAL_BLOCK 0x00000053

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9
    edited July 1

    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. :)

    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.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,137

    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).

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9
    edited July 1

    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. :)

    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.

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9
    edited July 1

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

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9

    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. :)

    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.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,137

    Mods? Did I violate some rules??

    Usually its due to too many edits...

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,913

    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.

    Peter Viscarola
    OSR
    @OSRDrivers

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9

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

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,302

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

    -scott
    OSR

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9

    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.

  • Andy_9_9_9_9Andy_9_9_9_9 Member Posts: 9
    edited July 3

    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. :)

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA