I have a WDF Volume and VolumeSnapshot Class Upper Filter driver (for CBT purpose).
I want to determine if the device for which EVT_WDF_DRIVER_DEVICE_ADD callback has been called is a regular volume or a snapshot volume.
For snapshot volumes created using Microsoft Software Shadow Copy provider, I see that the code can distinguish between them by checking if DEVICE_OBJECT.DeviceType is FILE_DEVICE_DISK (for Volume) vs FILE_DEVICE_VIRTUAL_DISK (for VolumeSnapshot)
However, for VolumeSnapshot created using Hardware VSS Provider, this is not the case. So, I would like to understand, what is the correct way to determine this ?
An almost-same discussion happened earlier : https://www.osronline.com/showthread.cfm?link=183473
The suggestion there is to use IOCTL_VOLUME_GET_GPT_ATTRIBUTES. Is that the correct thing to do ? The discussion ended a bit abruptly without concluding whether its correct to do so irrespective of MBR / GPT
Scott Brender from MSFT provided the answer in that thread. I don?t think I know him, but from the level,of detail in his post I?d say either he?s the dev owner or he looked it up. So… either way, I?d say try his suggestion and if it works, you?re good to go.
That?s what I would do, at least.
Peter
OSR
@OSRDrivers
You have to get the device class in your add device.
DECLARE_GLOBAL_CONST_UNICODE_STRING(g_SnapshotGUID,
L"{533c5b84-ec70-11d2-9505-00c04F79deaf}“);
DECLARE_GLOBAL_CONST_UNICODE_STRING(g_VolumeGUID,
L”{71A27CDD-812A-11D0-BEC7-08002BE2092F}");
ULONG result_len = 0;
PDEVICE_OBJECT base_dev = IoGetDeviceAttachmentBaseRef(PhysicalDevice);
WCHAR property_buf[MAX_UNICODE_STACK_BUFFER_LENGTH];
ULONG property_buf_len = MAX_UNICODE_STACK_BUFFER_LENGTH;
IoGetDeviceProperty(base_dev, DevicePropertyClassGuid, property_buf_len,
property_buf, &result_len);
ObDereferenceObject(base_dev);
UNICODE_STRING dev_guid;
RtlInitUnicodeString(&dev_guid, property_buf);
UINT type;
if (RtlEqualUnicodeString(&dev_guid, &g_SnapshotGUID, TRUE)) {
type = MY_DEV_TYPE_SNAPSHOT;
}
else if (RtlEqualUnicodeString(&dev_guid, &g_VolumeGUID, TRUE)) {
type = MY_DEV_TYPE_VOLUME;
}
On Fri, Apr 27, 2018 at 6:57 AM xxxxx@osr.com wrote:
> Scott Brender from MSFT provided the answer in that thread. I don?t think
> I know him, but from the level,of detail in his post I?d say either he?s
> the dev owner or he looked it up. So… either way, I?d say try his
> suggestion and if it works, you?re good to go.
>
> That?s what I would do, at least.
>
> Peter
> OSR
> @OSRDrivers
>
>
>
> —
> 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 http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>
@Peter : Thanks, I tried it in my code and the IOCTL works for both MBR as well as GPT case. Since that thread ended with an open question, so I thought it may be worth re-checking.
Found another thread that has a mention of the same IOCTL - http://osronline.com/showThread.CFM?link=218390
Nobody (specially Maxim, who has 1 response there) has posted anything to say that the IOCTL would be GPT specific, plus Alex Carp says the IOCTL is not specific to GPT disks. So I think I have no more doubts for the IOCTL.
@Jamey Kirby : Thanks for the response. I tried the code you have posted. The DevicePropertyClassGuid returned for the Snapshot volume created by hardware VSS provider is that of Volume class and not of VolumeSnapshot class. So, it may not work for this case.
IOCTL_VOLUME_GET_GPT_ATTRIBUTES is definitely not just for GPT… For
example, I need to flush my writes to the snapshot in my driver before the
snapshot transitions to read-only, so I filter this IOCTL, and do my flush
before (before passing down) the volume goes to read-only. I’ve never seen
and IRP_MJ_FLUSH sent to a VSS volume.
On Mon, Apr 30, 2018 at 7:25 AM xxxxx@gmail.com <
xxxxx@lists.osr.com> wrote:
@Peter : Thanks, I tried it in my code and the IOCTL works for both MBR as
well as GPT case. Since that thread ended with an open question, so I
thought it may be worth re-checking.
Found another thread that has a mention of the same IOCTL -
http://osronline.com/showThread.CFM?link=218390
Nobody (specially Maxim, who has 1 response there) has posted anything to
say that the IOCTL would be GPT specific, plus Alex Carp says the IOCTL is
not specific to GPT disks. So I think I have no more doubts for the IOCTL.
@Jamey Kirby : Thanks for the response. I tried the code you have posted.
The DevicePropertyClassGuid returned for the Snapshot volume created by
hardware VSS provider is that of Volume class and not of VolumeSnapshot
class. So, it may not work for this case.
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 http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>