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

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

IOCTL_VOLSNAP_QUERY_ORIGINAL_VOLUME_NAME

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
I am supporting an older driver. The driver filters volumes. I have added
code to filter shadow volumes as well. When VSS creates a snapshot, In PNP
Start call, I use IoForwardIrpSynchronously to pass the call down to the
device below me. Then, on return, I need to send the above mentioned IOCTL
to the ShadowCopy to retrieve the name of the original volume. I am using
IoBuildDeviceIoControlRequest to build my IRP.

The problem is that the call to the lower driver fails with invalid device
object error. The IOCTL is undocumented, so I am driving in the dark here.
Is this IOCTL intended to be sent to the top of the stack through the FS,
or is it OK to send this directly to the devices under the attached filter?

I need a quick way to associate a ShadowCopy with its original volume. If I
were rewriting the driver, it would be easier to implement, but I am forced
to work on an existing code base. So, I just was to setup a pointer
association in the device extensions between the volume and the shadow. I
have implemented all of the code, but I am getting stuck on the IOCTL error.

I fear I am going to have to do a lot more work, but if I could somehow
achieve this association, it would save me time, and help my client meet
their deadline.

Thanks.

Comments

  • Petr_KurtinPetr_Kurtin Member Posts: 275
    You should send this IOCTL directly to \Device\HarddiskVolumeShadowCopyX, i.e.



    status = IoGetDeviceObjectPointer( &uDeviceName, FILE_READ_ATTRIBUTES, &pFileObject, &pDeviceObject );

    ...

    IoBuildDeviceIoControlRequest( IOCTL_VOLSNAP_QUERY_*, pDeviceObject, NULL, 0, &uOutput.Buffer, uOutput.MaximumLength, ... );

    status = IoCallDriver( pDeviceObject, pIrp );

    ...



    Petr





    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
    Sent: Wednesday, January 27, 2016 10:08 PM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] IOCTL_VOLSNAP_QUERY_ORIGINAL_VOLUME_NAME



    I am supporting an older driver. The driver filters volumes. I have added code to filter shadow volumes as well. When VSS creates a snapshot, In PNP Start call, I use IoForwardIrpSynchronously to pass the call down to the device below me. Then, on return, I need to send the above mentioned IOCTL to the ShadowCopy to retrieve the name of the original volume. I am using IoBuildDeviceIoControlRequest to build my IRP.



    The problem is that the call to the lower driver fails with invalid device object error. The IOCTL is undocumented, so I am driving in the dark here. Is this IOCTL intended to be sent to the top of the stack through the FS, or is it OK to send this directly to the devices under the attached filter?



    I need a quick way to associate a ShadowCopy with its original volume. If I were rewriting the driver, it would be easier to implement, but I am forced to work on an existing code base. So, I just was to setup a pointer association in the device extensions between the volume and the shadow. I have implemented all of the code, but I am getting stuck on the IOCTL error.



    I fear I am going to have to do a lot more work, but if I could somehow achieve this association, it would save me time, and help my client meet their deadline.



    Thanks.

    --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    That is what I am doing, and I am getting an error. The problem may be that
    I am doing this in the PNP start routine using the device object I have
    setup as the target in AddDevice. This give me hope, so I will continue
    working down this path for a bit longer.



    On Thu, Jan 28, 2016 at 4:20 AM Petr Kurtin wrote:

    > You should send this IOCTL directly to \Device\HarddiskVolumeShadowCopyX,
    > i.e.
    >
    >
    >
    > status = IoGetDeviceObjectPointer( &uDeviceName, FILE_READ_ATTRIBUTES,
    > &pFileObject, &pDeviceObject );
    >
    > ...
    >
    > IoBuildDeviceIoControlRequest( IOCTL_VOLSNAP_QUERY_*, pDeviceObject,
    > NULL, 0, &uOutput.Buffer, uOutput.MaximumLength, ... );
    >
    > status = IoCallDriver( pDeviceObject, pIrp );
    >
    > ...
    >
    >
    >
    > Petr
    >
    >
    >
    >
    >
    > *From:* xxxxx@lists.osr.com [mailto:
    > xxxxx@lists.osr.com] *On Behalf Of *Jamey Kirby
    > *Sent:* Wednesday, January 27, 2016 10:08 PM
    > *To:* Windows System Software Devs Interest List
    > *Subject:* [ntdev] IOCTL_VOLSNAP_QUERY_ORIGINAL_VOLUME_NAME
    >
    >
    >
    > I am supporting an older driver. The driver filters volumes. I have added
    > code to filter shadow volumes as well. When VSS creates a snapshot, In PNP
    > Start call, I use IoForwardIrpSynchronously to pass the call down to the
    > device below me. Then, on return, I need to send the above mentioned IOCTL
    > to the ShadowCopy to retrieve the name of the original volume. I am using
    > IoBuildDeviceIoControlRequest to build my IRP.
    >
    >
    >
    > The problem is that the call to the lower driver fails with invalid device
    > object error. The IOCTL is undocumented, so I am driving in the dark here.
    > Is this IOCTL intended to be sent to the top of the stack through the FS,
    > or is it OK to send this directly to the devices under the attached filter?
    >
    >
    >
    > I need a quick way to associate a ShadowCopy with its original volume. If
    > I were rewriting the driver, it would be easier to implement, but I am
    > forced to work on an existing code base. So, I just was to setup a pointer
    > association in the device extensions between the volume and the shadow. I
    > have implemented all of the code, but I am getting stuck on the IOCTL error.
    >
    >
    >
    > I fear I am going to have to do a lot more work, but if I could somehow
    > achieve this association, it would save me time, and help my client meet
    > their deadline.
    >
    >
    >
    > Thanks.
    >
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    > on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at To unsubscribe, visit the List Server section of OSR Online at
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 429
    This is how I build my IRP. I am building it in the PNP start call, so I
    wonder if calling the lower driver before the start has returned up the
    stack is the source of the problem.

    irp = IoBuildDeviceIoControlRequest
    (
    IOCTL_VOLSNAP_QUERY_ORIGINAL_VOLUME_NAME,
    DeviceExtension->TargetDevice,
    NULL,
    0,
    volume_name,
    name_buf_len,
    FALSE,
    &event,
    &iosb
    );


    On Thu, Jan 28, 2016 at 9:13 AM Jamey Kirby wrote:

    > That is what I am doing, and I am getting an error. The problem may be
    > that I am doing this in the PNP start routine using the device object I
    > have setup as the target in AddDevice. This give me hope, so I will
    > continue working down this path for a bit longer.
    >
    >
    >
    > On Thu, Jan 28, 2016 at 4:20 AM Petr Kurtin wrote:
    >
    >> You should send this IOCTL directly to \Device\HarddiskVolumeShadowCopyX,
    >> i.e.
    >>
    >>
    >>
    >> status = IoGetDeviceObjectPointer( &uDeviceName, FILE_READ_ATTRIBUTES,
    >> &pFileObject, &pDeviceObject );
    >>
    >> ...
    >>
    >> IoBuildDeviceIoControlRequest( IOCTL_VOLSNAP_QUERY_*, pDeviceObject,
    >> NULL, 0, &uOutput.Buffer, uOutput.MaximumLength, ... );
    >>
    >> status = IoCallDriver( pDeviceObject, pIrp );
    >>
    >> ...
    >>
    >>
    >>
    >> Petr
    >>
    >>
    >>
    >>
    >>
    >> *From:* xxxxx@lists.osr.com [mailto:
    >> xxxxx@lists.osr.com] *On Behalf Of *Jamey Kirby
    >> *Sent:* Wednesday, January 27, 2016 10:08 PM
    >> *To:* Windows System Software Devs Interest List
    >> *Subject:* [ntdev] IOCTL_VOLSNAP_QUERY_ORIGINAL_VOLUME_NAME
    >>
    >>
    >>
    >> I am supporting an older driver. The driver filters volumes. I have added
    >> code to filter shadow volumes as well. When VSS creates a snapshot, In PNP
    >> Start call, I use IoForwardIrpSynchronously to pass the call down to the
    >> device below me. Then, on return, I need to send the above mentioned IOCTL
    >> to the ShadowCopy to retrieve the name of the original volume. I am using
    >> IoBuildDeviceIoControlRequest to build my IRP.
    >>
    >>
    >>
    >> The problem is that the call to the lower driver fails with invalid
    >> device object error. The IOCTL is undocumented, so I am driving in the dark
    >> here. Is this IOCTL intended to be sent to the top of the stack through the
    >> FS, or is it OK to send this directly to the devices under the attached
    >> filter?
    >>
    >>
    >>
    >> I need a quick way to associate a ShadowCopy with its original volume. If
    >> I were rewriting the driver, it would be easier to implement, but I am
    >> forced to work on an existing code base. So, I just was to setup a pointer
    >> association in the device extensions between the volume and the shadow. I
    >> have implemented all of the code, but I am getting stuck on the IOCTL error.
    >>
    >>
    >>
    >> I fear I am going to have to do a lot more work, but if I could somehow
    >> achieve this association, it would save me time, and help my client meet
    >> their deadline.
    >>
    >>
    >>
    >> Thanks.
    >>
    >> --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
    >> on crash dump analysis, WDF, Windows internals and software drivers!
    >> Details at To unsubscribe, visit the List Server section of OSR Online at
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at: <
    >> http://www.osronline.com/showlists.cfm?list=ntdev>;
    >>
    >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    >> software drivers!
    >> Details at
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at <
    >> http://www.osronline.com/page.cfm?name=ListServer>;
    >>
    >
  • Petr_KurtinPetr_Kurtin Member Posts: 275
    When I call this IOCTL later, it worked well. PNP Start is usually too early (you should try to call it after receiving IOCTL_VOLUME_ONLINE). You can also debug this IOCTL to volsnap driver (handler isn't too complex).
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
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA