How to get volume/partition info in drivers Adddevice

NTDEV
1

Hi,

I have a upper volume filter driver which is working like a charm. I use addfilter utility from winddk to attach my filter driver to any desired volume. I use IOAttachDeviceToStack in driver`s adddevice. It intercepts all the IRPs along with the data properly without any problems.

Now I need to do the following:

Get the Volume/partition`s length/Block Size etc (basically partition_info). To do this, I need to know the volume/partition name. So I used “IoVolumeDeviceToDosName” function with input object as TargetDev (that I receive as input parameter to AddDevice).

Above call only prints “???”. Am I missing something or doing something wrong (obviously, otherwise it would be working :D)?

Below is the portion of the code from my drivers AddDevice.

static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN PDEVICE_OBJECT pTargDev )
{
WCHAR stringBuffer[512];
UNICODE_STRING DosName;
stringBuffer[0] = L’\0’;

DosName.Buffer = stringBuffer;
DosName.Length = 0;
DosName.MaximumLength = 512;

IoVolumeDeviceToDosName(pTargDev, &DosName);
DbgPrint(“Target Volume Name (unicode string) = %wZ\n”, DosName);
}

Printing above unicode string only prints “???” (that too only sometimes).

Appreciate your help.

2

Did you try reading the documentation for IoVolumeDeviceToDosName?

  1. it returns a status value. That value just might be important.
  2. it allocates the buffer for the UNICODE_STRING.

“IoVolumeDeviceToDosName allocates the Unicode string buffer for the
MS-DOS path from the memory pool. After the buffer is no longer
required, a caller of this routine should use ExFreePool to free it.”

Mark Roddy

On Tue, Oct 12, 2010 at 5:47 AM, wrote:
> IoVolumeDeviceToDosName

3

Hi Mark,

Thanks for your prompt reply.

As a matter of fact, I did read this in WDDK doc.

Before trying the current code, I did have PUNICODE_STRING variable
(uninitialized) being passed to IoVolumeDeviceToDosName. Result was the
same. Only after that, out of curiosity, I tried allocating the buffer.

Let me check the return value. Will post back in few minutes.

Regards

Jaswant

On 12 October 2010 16:54, Mark Roddy wrote:

> Did you try reading the documentation for IoVolumeDeviceToDosName?
>
> 1) it returns a status value. That value just might be important.
> 2) it allocates the buffer for the UNICODE_STRING.
>
> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
> MS-DOS path from the memory pool. After the buffer is no longer
> required, a caller of this routine should use ExFreePool to free it.”
>
>
> Mark Roddy
>
>
>
> On Tue, Oct 12, 2010 at 5:47 AM, wrote:
> > IoVolumeDeviceToDosName
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

4

Hi Mark,

Status code returned is “*0xc000000e*” - which I believe means “*
no_such_device*”

Changed the code as follows (falling back to previous thing )

static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN
PDEVICE_OBJECT pTargDev )
{
UNICODE_STRING DosName;
NTSTATUS status;
RtlInitUnicodeString(&DosName, NULL);
status = IoVolumeDeviceToDosName(pTargDev, &DosName);

DbgPrint(“----Target Device name (unicode string) = %wZ\n”, DosName);
DbgPrint(“----return status = %#010x\n”, status);
}

Both unicode and wide string are printing NULL. Any reason why would it say
“no_such_device” ? I execute “addfilter” utility as below

“*addfilter.exe /device \HarddiskVolume4 /add myfilter*”

So the target device object that I get as parameter to adddevice should be
refering to this volume right ?

Appreciate your help and thoughts once again.

Regards

Jaswant

On 12 October 2010 17:23, Jaswanth Chajjed wrote:

> Hi Mark,
>
> Thanks for your prompt reply.
>
> As a matter of fact, I did read this in WDDK doc.
>
> Before trying the current code, I did have PUNICODE_STRING variable
> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was the
> same. Only after that, out of curiosity, I tried allocating the buffer.
>
> Let me check the return value. Will post back in few minutes.
>
> Regards
>
> Jaswant
>
>
> On 12 October 2010 16:54, Mark Roddy wrote:
>
>> Did you try reading the documentation for IoVolumeDeviceToDosName?
>>
>> 1) it returns a status value. That value just might be important.
>> 2) it allocates the buffer for the UNICODE_STRING.
>>
>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
>> MS-DOS path from the memory pool. After the buffer is no longer
>> required, a caller of this routine should use ExFreePool to free it.”
>>
>>
>> Mark Roddy
>>
>>
>>
>> On Tue, Oct 12, 2010 at 5:47 AM, wrote:
>> > IoVolumeDeviceToDosName
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>>
>
>

5

The ‘target device’ is the PDO and is unlikely to be the correct
device object for IoVolumeDeviceToDosName. Not only that, but it is
likely that at AddDevice there are no mount points for the volume. I
think you need to wait for the volume to get mounted before you query
its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
interesting to a volume filter driver.

You continue to ignore the status returned - if this function returns
an error there is no valid ‘dos name’. Printing the contents of the
unicode string at this point is just asking for a BSOD.

Mark Roddy

On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
wrote:
> Hi Mark,
>
> Status code returned is “0xc000000e” - which I believe means
> “no_such_device”
>
> Changed the code as follows (falling back to previous thing )
>
> static NTSTATUS AddDevice(IN PDRIVER_OBJECT ? ? pDriverObject, IN
> PDEVICE_OBJECT ? ?? pTargDev )
> {
> ??? UNICODE_STRING DosName;
> ??? NTSTATUS??? ??? status;
> ??? RtlInitUnicodeString(&DosName, NULL);
> ??? status = IoVolumeDeviceToDosName(pTargDev, &DosName);
>
> ??? DbgPrint(“----Target Device name (unicode string) = %wZ\n”, DosName);
> ??? DbgPrint(“----return status = %#010x\n”, status);
> }
>
> Both unicode and wide string are printing NULL. Any reason why would it say
> “no_such_device” ? I execute “addfilter” utility as below
>
> “addfilter.exe /device \HarddiskVolume4 /add myfilter”
>
> So the target device object that I get as parameter to adddevice should be
> refering to this volume right ?
>
> Appreciate your help and thoughts once again.
>
> Regards
>
> Jaswant
>
> On 12 October 2010 17:23, Jaswanth Chajjed
> wrote:
>>
>> Hi Mark,
>>
>> Thanks for your prompt reply.
>>
>> As a matter of fact, I did read this in WDDK doc.
>>
>> Before trying the current code,? I did have PUNICODE_STRING variable
>> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was the
>> same. Only after that, out of curiosity, I tried allocating the buffer.
>>
>> Let me check the return value. Will post back in few minutes.
>>
>> Regards
>>
>> Jaswant
>>
>> On 12 October 2010 16:54, Mark Roddy wrote:
>>>
>>> Did you try reading the documentation for IoVolumeDeviceToDosName?
>>>
>>> 1) it returns a status value. That value just might be important.
>>> 2) it allocates the buffer for the UNICODE_STRING.
>>>
>>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
>>> MS-DOS path from the memory pool. After the buffer is no longer
>>> required, a caller of this routine should use ExFreePool to free it.”
>>>
>>>
>>> Mark Roddy
>>>
>>>
>>>
>>> On Tue, Oct 12, 2010 at 5:47 AM, ? wrote:
>>> > IoVolumeDeviceToDosName
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other 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
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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

%wZ expects a pointer to a UNICODE_STRING

d

dent from a phpne with no keynoard

From: Jaswanth Chajjed
Sent: October 12, 2010 5:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to get volume/partition info in drivers Adddevice

Hi Mark,

Status code returned is “0xc000000e” - which I believe means “no_such_device”

Changed the code as follows (falling back to previous thing )

static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN PDEVICE_OBJECT pTargDev )
{
UNICODE_STRING DosName;
NTSTATUS status;
RtlInitUnicodeString(&DosName, NULL);
status = IoVolumeDeviceToDosName(pTargDev, &DosName);

DbgPrint(“----Target Device name (unicode string) = %wZ\n”, DosName);
DbgPrint(“----return status = %#010x\n”, status);
}

Both unicode and wide string are printing NULL. Any reason why would it say “no_such_device” ? I execute “addfilter” utility as below

“addfilter.exe /device \HarddiskVolume4 /add myfilter”

So the target device object that I get as parameter to adddevice should be refering to this volume right ?

Appreciate your help and thoughts once again.

Regards

Jaswant

On 12 October 2010 17:23, Jaswanth Chajjed > wrote:
Hi Mark,

Thanks for your prompt reply.

As a matter of fact, I did read this in WDDK doc.

Before trying the current code, I did have PUNICODE_STRING variable (uninitialized) being passed to IoVolumeDeviceToDosName. Result was the same. Only after that, out of curiosity, I tried allocating the buffer.

Let me check the return value. Will post back in few minutes.

Regards

Jaswant

On 12 October 2010 16:54, Mark Roddy > wrote:
Did you try reading the documentation for IoVolumeDeviceToDosName?

1) it returns a status value. That value just might be important.
2) it allocates the buffer for the UNICODE_STRING.

“IoVolumeDeviceToDosName allocates the Unicode string buffer for the
MS-DOS path from the memory pool. After the buffer is no longer
required, a caller of this routine should use ExFreePool to free it.”

Mark Roddy

On Tue, Oct 12, 2010 at 5:47 AM, > wrote:
> IoVolumeDeviceToDosName

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other 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

But the target device is already mounted. I attach this filter driver
manually after booting to a non system partition (H:).

Do you happen to have any other way on top of your mind through which I can
acheive what I want i.e getting the volume/partition information (length,
block size…)?

Let me give you some background info for you to help me better.

Purpose of this filter driver is to create a bitmap that would represent
volume blocks that have changed vs unchanged. So far driver has been doing
well but with hardcoded values. i.e Bitmap array has been hardcoded for a
known volume size. But in reality it can be anything. Right?

So I thought it would be better to get the volume name in adddevice (when
the filter driver is being attached) and query for its partition info to
create a Bitmaparray of appropriate size.

Can you help me acheive this in some other way if the tried solution is not
feasible?

Regards

Jaswant

On 12 October 2010 19:23, Mark Roddy wrote:

> The ‘target device’ is the PDO and is unlikely to be the correct
> device object for IoVolumeDeviceToDosName. Not only that, but it is
> likely that at AddDevice there are no mount points for the volume. I
> think you need to wait for the volume to get mounted before you query
> its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
> interesting to a volume filter driver.
>
> You continue to ignore the status returned - if this function returns
> an error there is no valid ‘dos name’. Printing the contents of the
> unicode string at this point is just asking for a BSOD.
>
>
> Mark Roddy
>
>
>
> On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
> wrote:
> > Hi Mark,
> >
> > Status code returned is “0xc000000e” - which I believe means
> > “no_such_device”
> >
> > Changed the code as follows (falling back to previous thing )
> >
> > static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN
> > PDEVICE_OBJECT pTargDev )
> > {
> > UNICODE_STRING DosName;
> > NTSTATUS status;
> > RtlInitUnicodeString(&DosName, NULL);
> > status = IoVolumeDeviceToDosName(pTargDev, &DosName);
> >
> > DbgPrint(“----Target Device name (unicode string) = %wZ\n”, DosName);
> > DbgPrint(“----return status = %#010x\n”, status);
> > }
> >
> > Both unicode and wide string are printing NULL. Any reason why would it
> say
> > “no_such_device” ? I execute “addfilter” utility as below
> >
> > “addfilter.exe /device \HarddiskVolume4 /add myfilter”
> >
> > So the target device object that I get as parameter to adddevice should
> be
> > refering to this volume right ?
> >
> > Appreciate your help and thoughts once again.
> >
> > Regards
> >
> > Jaswant
> >
> > On 12 October 2010 17:23, Jaswanth Chajjed
> > wrote:
> >>
> >> Hi Mark,
> >>
> >> Thanks for your prompt reply.
> >>
> >> As a matter of fact, I did read this in WDDK doc.
> >>
> >> Before trying the current code, I did have PUNICODE_STRING variable
> >> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was the
> >> same. Only after that, out of curiosity, I tried allocating the buffer.
> >>
> >> Let me check the return value. Will post back in few minutes.
> >>
> >> Regards
> >>
> >> Jaswant
> >>
> >> On 12 October 2010 16:54, Mark Roddy wrote:
> >>>
> >>> Did you try reading the documentation for IoVolumeDeviceToDosName?
> >>>
> >>> 1) it returns a status value. That value just might be important.
> >>> 2) it allocates the buffer for the UNICODE_STRING.
> >>>
> >>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
> >>> MS-DOS path from the memory pool. After the buffer is no longer
> >>> required, a caller of this routine should use ExFreePool to free it.”
> >>>
> >>>
> >>> Mark Roddy
> >>>
> >>>
> >>>
> >>> On Tue, Oct 12, 2010 at 5:47 AM, wrote:
> >>> > IoVolumeDeviceToDosName
> >>>
> >>> —
> >>> NTDEV is sponsored by OSR
> >>>
> >>> For our schedule of WDF, WDM, debugging and other 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
> >>
> >
> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> > other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

8

IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
assuming you are actually filtering above a volume device.

This ought to return you a VOLUME_DISK_EXTENTS object with an array of
DISK_EXTENTS, one for each physical disk containing backing store for
the volume, with the information about the size. in bytes, of each
extent.

Presumably you are going to pass on volumes with more than one extent.

Mark Roddy

On Tue, Oct 12, 2010 at 1:33 PM, Jaswanth Chajjed
wrote:
> But the target device is already mounted. I attach this filter driver
> manually after booting to a non system partition (H:).
>
> Do you happen to have any other way on top of your mind through which I can
> acheive what I want i.e getting the volume/partition information (length,
> block size…)?
>
> Let me give you some background info for you to help me better.
>
> Purpose of this filter driver is to create a bitmap that would represent
> volume blocks that have changed vs unchanged. So far driver has been doing
> well but with hardcoded values. i.e Bitmap array has been hardcoded for a
> known volume size. But in reality it can be anything. Right?
>
> So I thought it would be better to get the volume name in adddevice (when
> the filter driver is being attached) and query for its partition info to
> create a Bitmaparray of appropriate size.
>
> Can you help me acheive this in some other way if the tried solution is not
> feasible?
>
> Regards
>
> Jaswant
>
> On 12 October 2010 19:23, Mark Roddy wrote:
>>
>> The ‘target device’ is the PDO and is unlikely to be the correct
>> device object for IoVolumeDeviceToDosName. Not only that, but it is
>> likely that at AddDevice there are no mount points for the volume. I
>> think you need to wait for the volume to get mounted before you query
>> its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
>> interesting to a volume filter driver.
>>
>> You continue to ignore the status returned - if this function returns
>> an error there is no valid ‘dos name’. Printing the contents of the
>> unicode string at this point is just asking for a BSOD.
>>
>>
>> Mark Roddy
>>
>>
>>
>> On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
>> wrote:
>> > Hi Mark,
>> >
>> > Status code returned is “0xc000000e” - which I believe means
>> > “no_such_device”
>> >
>> > Changed the code as follows (falling back to previous thing )
>> >
>> > static NTSTATUS AddDevice(IN PDRIVER_OBJECT ? ? pDriverObject, IN
>> > PDEVICE_OBJECT ? ?? pTargDev )
>> > {
>> > ??? UNICODE_STRING DosName;
>> > ??? NTSTATUS??? ??? status;
>> > ??? RtlInitUnicodeString(&DosName, NULL);
>> > ??? status = IoVolumeDeviceToDosName(pTargDev, &DosName);
>> >
>> > ??? DbgPrint(“----Target Device name (unicode string) = %wZ\n”,
>> > DosName);
>> > ??? DbgPrint(“----return status = %#010x\n”, status);
>> > }
>> >
>> > Both unicode and wide string are printing NULL. Any reason why would it
>> > say
>> > “no_such_device” ? I execute “addfilter” utility as below
>> >
>> > “addfilter.exe /device \HarddiskVolume4 /add myfilter”
>> >
>> > So the target device object that I get as parameter to adddevice should
>> > be
>> > refering to this volume right ?
>> >
>> > Appreciate your help and thoughts once again.
>> >
>> > Regards
>> >
>> > Jaswant
>> >
>> > On 12 October 2010 17:23, Jaswanth Chajjed
>> > wrote:
>> >>
>> >> Hi Mark,
>> >>
>> >> Thanks for your prompt reply.
>> >>
>> >> As a matter of fact, I did read this in WDDK doc.
>> >>
>> >> Before trying the current code,? I did have PUNICODE_STRING variable
>> >> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was the
>> >> same. Only after that, out of curiosity, I tried allocating the buffer.
>> >>
>> >> Let me check the return value. Will post back in few minutes.
>> >>
>> >> Regards
>> >>
>> >> Jaswant
>> >>
>> >> On 12 October 2010 16:54, Mark Roddy wrote:
>> >>>
>> >>> Did you try reading the documentation for IoVolumeDeviceToDosName?
>> >>>
>> >>> 1) it returns a status value. That value just might be important.
>> >>> 2) it allocates the buffer for the UNICODE_STRING.
>> >>>
>> >>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
>> >>> MS-DOS path from the memory pool. After the buffer is no longer
>> >>> required, a caller of this routine should use ExFreePool to free it.”
>> >>>
>> >>>
>> >>> Mark Roddy
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Oct 12, 2010 at 5:47 AM, ? wrote:
>> >>> > IoVolumeDeviceToDosName
>> >>>
>> >>> —
>> >>> NTDEV is sponsored by OSR
>> >>>
>> >>> For our schedule of WDF, WDM, debugging and other 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
>> >>
>> >
>> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> > and
>> > other 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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

9

Mark,

Thanks for your suggestion and I really appreciate your patience.

I had explored this IOCTL earlier but got stuck because of the following
reason:

It would need a handle. When I do not know the volume name, how do I open
the volume and get its handle to make an IOCTL call on it? Is there a way
(any driver routine) to get the volume handle in “AddDevice” from any of its
input parameter ?

Thanks

Jaswant

On 12 October 2010 23:34, Mark Roddy wrote:

> IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
> assuming you are actually filtering above a volume device.
>
> This ought to return you a VOLUME_DISK_EXTENTS object with an array of
> DISK_EXTENTS, one for each physical disk containing backing store for
> the volume, with the information about the size. in bytes, of each
> extent.
>
> Presumably you are going to pass on volumes with more than one extent.
>
> Mark Roddy
>
>
>
> On Tue, Oct 12, 2010 at 1:33 PM, Jaswanth Chajjed
> wrote:
> > But the target device is already mounted. I attach this filter driver
> > manually after booting to a non system partition (H:).
> >
> > Do you happen to have any other way on top of your mind through which I
> can
> > acheive what I want i.e getting the volume/partition information (length,
> > block size…)?
> >
> > Let me give you some background info for you to help me better.
> >
> > Purpose of this filter driver is to create a bitmap that would represent
> > volume blocks that have changed vs unchanged. So far driver has been
> doing
> > well but with hardcoded values. i.e Bitmap array has been hardcoded for a
> > known volume size. But in reality it can be anything. Right?
> >
> > So I thought it would be better to get the volume name in adddevice (when
> > the filter driver is being attached) and query for its partition info to
> > create a Bitmaparray of appropriate size.
> >
> > Can you help me acheive this in some other way if the tried solution is
> not
> > feasible?
> >
> > Regards
> >
> > Jaswant
> >
> > On 12 October 2010 19:23, Mark Roddy wrote:
> >>
> >> The ‘target device’ is the PDO and is unlikely to be the correct
> >> device object for IoVolumeDeviceToDosName. Not only that, but it is
> >> likely that at AddDevice there are no mount points for the volume. I
> >> think you need to wait for the volume to get mounted before you query
> >> its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
> >> interesting to a volume filter driver.
> >>
> >> You continue to ignore the status returned - if this function returns
> >> an error there is no valid ‘dos name’. Printing the contents of the
> >> unicode string at this point is just asking for a BSOD.
> >>
> >>
> >> Mark Roddy
> >>
> >>
> >>
> >> On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
> >> wrote:
> >> > Hi Mark,
> >> >
> >> > Status code returned is “0xc000000e” - which I believe means
> >> > “no_such_device”
> >> >
> >> > Changed the code as follows (falling back to previous thing )
> >> >
> >> > static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN
> >> > PDEVICE_OBJECT pTargDev )
> >> > {
> >> > UNICODE_STRING DosName;
> >> > NTSTATUS status;
> >> > RtlInitUnicodeString(&DosName, NULL);
> >> > status = IoVolumeDeviceToDosName(pTargDev, &DosName);
> >> >
> >> > DbgPrint(“----Target Device name (unicode string) = %wZ\n”,
> >> > DosName);
> >> > DbgPrint(“----return status = %#010x\n”, status);
> >> > }
> >> >
> >> > Both unicode and wide string are printing NULL. Any reason why would
> it
> >> > say
> >> > “no_such_device” ? I execute “addfilter” utility as below
> >> >
> >> > “addfilter.exe /device \HarddiskVolume4 /add myfilter”
> >> >
> >> > So the target device object that I get as parameter to adddevice
> should
> >> > be
> >> > refering to this volume right ?
> >> >
> >> > Appreciate your help and thoughts once again.
> >> >
> >> > Regards
> >> >
> >> > Jaswant
> >> >
> >> > On 12 October 2010 17:23, Jaswanth Chajjed <
> xxxxx@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Mark,
> >> >>
> >> >> Thanks for your prompt reply.
> >> >>
> >> >> As a matter of fact, I did read this in WDDK doc.
> >> >>
> >> >> Before trying the current code, I did have PUNICODE_STRING variable
> >> >> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was
> the
> >> >> same. Only after that, out of curiosity, I tried allocating the
> buffer.
> >> >>
> >> >> Let me check the return value. Will post back in few minutes.
> >> >>
> >> >> Regards
> >> >>
> >> >> Jaswant
> >> >>
> >> >> On 12 October 2010 16:54, Mark Roddy wrote:
> >> >>>
> >> >>> Did you try reading the documentation for IoVolumeDeviceToDosName?
> >> >>>
> >> >>> 1) it returns a status value. That value just might be important.
> >> >>> 2) it allocates the buffer for the UNICODE_STRING.
> >> >>>
> >> >>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for the
> >> >>> MS-DOS path from the memory pool. After the buffer is no longer
> >> >>> required, a caller of this routine should use ExFreePool to free
> it.”
> >> >>>
> >> >>>
> >> >>> Mark Roddy
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Oct 12, 2010 at 5:47 AM,
> wrote:
> >> >>> > IoVolumeDeviceToDosName
> >> >>>
> >> >>> —
> >> >>> NTDEV is sponsored by OSR
> >> >>>
> >> >>> For our schedule of WDF, WDM, debugging and other 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
> >> >>
> >> >
> >> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
> >> > and
> >> > other 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
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other 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
> >
> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> > other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

10

IoBuildDeviceIoControlRequest takes as input a DeviceObject rather
than a handle and returns you an Irp all set to use with IoCallDriver
to forward to the volume device you are attached to. You then wait for
the volume driver to fill in the details and return the Irp back to
you.

Mark Roddy

On Tue, Oct 12, 2010 at 2:14 PM, Jaswanth Chajjed
wrote:
> Mark,
>
> Thanks for your suggestion and I really appreciate your patience.
>
> I had explored this IOCTL earlier but got stuck because of the following
> reason:
>
> It would need a handle. When I do not know the volume name, how do I open
> the volume and get its handle to make an IOCTL call on it? Is there a way
> (any driver routine) to get the volume handle in “AddDevice” from any of its
> input parameter ?
>
> Thanks
>
> Jaswant
>
>
>
>
> On 12 October 2010 23:34, Mark Roddy wrote:
>>
>> IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
>> ?assuming you are actually filtering above a volume device.
>>
>> This ought to return you a VOLUME_DISK_EXTENTS object with an array of
>> DISK_EXTENTS, one for each physical disk containing backing store for
>> the volume, with the information about the size. in bytes, of each
>> extent.
>>
>> Presumably you are going to pass on volumes with more than one extent.
>>
>> Mark Roddy
>>
>>
>>
>> On Tue, Oct 12, 2010 at 1:33 PM, Jaswanth Chajjed
>> wrote:
>> > But the target device is already mounted. I attach this filter driver
>> > manually after booting to a non system partition (H:).
>> >
>> > Do you happen to have any other way on top of your mind through which I
>> > can
>> > acheive what I want i.e getting the volume/partition information
>> > (length,
>> > block size…)?
>> >
>> > Let me give you some background info for you to help me better.
>> >
>> > Purpose of this filter driver is to create a bitmap that would represent
>> > volume blocks that have changed vs unchanged. So far driver has been
>> > doing
>> > well but with hardcoded values. i.e Bitmap array has been hardcoded for
>> > a
>> > known volume size. But in reality it can be anything. Right?
>> >
>> > So I thought it would be better to get the volume name in adddevice
>> > (when
>> > the filter driver is being attached) and query for its partition info to
>> > create a Bitmaparray of appropriate size.
>> >
>> > Can you help me acheive this in some other way if the tried solution is
>> > not
>> > feasible?
>> >
>> > Regards
>> >
>> > Jaswant
>> >
>> > On 12 October 2010 19:23, Mark Roddy wrote:
>> >>
>> >> The ‘target device’ is the PDO and is unlikely to be the correct
>> >> device object for IoVolumeDeviceToDosName. Not only that, but it is
>> >> likely that at AddDevice there are no mount points for the volume. I
>> >> think you need to wait for the volume to get mounted before you query
>> >> its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
>> >> interesting to a volume filter driver.
>> >>
>> >> You continue to ignore the status returned - if this function returns
>> >> an error there is no valid ‘dos name’. Printing the contents of the
>> >> unicode string at this point is just asking for a BSOD.
>> >>
>> >>
>> >> Mark Roddy
>> >>
>> >>
>> >>
>> >> On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
>> >> wrote:
>> >> > Hi Mark,
>> >> >
>> >> > Status code returned is “0xc000000e” - which I believe means
>> >> > “no_such_device”
>> >> >
>> >> > Changed the code as follows (falling back to previous thing )
>> >> >
>> >> > static NTSTATUS AddDevice(IN PDRIVER_OBJECT ? ? pDriverObject, IN
>> >> > PDEVICE_OBJECT ? ?? pTargDev )
>> >> > {
>> >> > ??? UNICODE_STRING DosName;
>> >> > ??? NTSTATUS??? ??? status;
>> >> > ??? RtlInitUnicodeString(&DosName, NULL);
>> >> > ??? status = IoVolumeDeviceToDosName(pTargDev, &DosName);
>> >> >
>> >> > ??? DbgPrint(“----Target Device name (unicode string) = %wZ\n”,
>> >> > DosName);
>> >> > ??? DbgPrint(“----return status = %#010x\n”, status);
>> >> > }
>> >> >
>> >> > Both unicode and wide string are printing NULL. Any reason why would
>> >> > it
>> >> > say
>> >> > “no_such_device” ? I execute “addfilter” utility as below
>> >> >
>> >> > “addfilter.exe /device \HarddiskVolume4 /add myfilter”
>> >> >
>> >> > So the target device object that I get as parameter to adddevice
>> >> > should
>> >> > be
>> >> > refering to this volume right ?
>> >> >
>> >> > Appreciate your help and thoughts once again.
>> >> >
>> >> > Regards
>> >> >
>> >> > Jaswant
>> >> >
>> >> > On 12 October 2010 17:23, Jaswanth Chajjed
>> >> >
>> >> > wrote:
>> >> >>
>> >> >> Hi Mark,
>> >> >>
>> >> >> Thanks for your prompt reply.
>> >> >>
>> >> >> As a matter of fact, I did read this in WDDK doc.
>> >> >>
>> >> >> Before trying the current code,? I did have PUNICODE_STRING variable
>> >> >> (uninitialized) being passed to IoVolumeDeviceToDosName. Result was
>> >> >> the
>> >> >> same. Only after that, out of curiosity, I tried allocating the
>> >> >> buffer.
>> >> >>
>> >> >> Let me check the return value. Will post back in few minutes.
>> >> >>
>> >> >> Regards
>> >> >>
>> >> >> Jaswant
>> >> >>
>> >> >> On 12 October 2010 16:54, Mark Roddy wrote:
>> >> >>>
>> >> >>> Did you try reading the documentation for IoVolumeDeviceToDosName?
>> >> >>>
>> >> >>> 1) it returns a status value. That value just might be important.
>> >> >>> 2) it allocates the buffer for the UNICODE_STRING.
>> >> >>>
>> >> >>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for
>> >> >>> the
>> >> >>> MS-DOS path from the memory pool. After the buffer is no longer
>> >> >>> required, a caller of this routine should use ExFreePool to free
>> >> >>> it.”
>> >> >>>
>> >> >>>
>> >> >>> Mark Roddy
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Tue, Oct 12, 2010 at 5:47 AM, ?
>> >> >>> wrote:
>> >> >>> > IoVolumeDeviceToDosName
>> >> >>>
>> >> >>> —
>> >> >>> NTDEV is sponsored by OSR
>> >> >>>
>> >> >>> For our schedule of WDF, WDM, debugging and other 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
>> >> >>
>> >> >
>> >> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> >> > and
>> >> > other 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
>> >>
>> >> —
>> >> NTDEV is sponsored by OSR
>> >>
>> >> For our schedule of WDF, WDM, debugging and other 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
>> >
>> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> > and
>> > other 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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

11

Thanks a lot Mark.

Let me try it out. Will get back :).

Jaswant

On 12 October 2010 23:53, Mark Roddy wrote:

> IoBuildDeviceIoControlRequest takes as input a DeviceObject rather
> than a handle and returns you an Irp all set to use with IoCallDriver
> to forward to the volume device you are attached to. You then wait for
> the volume driver to fill in the details and return the Irp back to
> you.
>
> Mark Roddy
>
>
>
> On Tue, Oct 12, 2010 at 2:14 PM, Jaswanth Chajjed
> wrote:
> > Mark,
> >
> > Thanks for your suggestion and I really appreciate your patience.
> >
> > I had explored this IOCTL earlier but got stuck because of the following
> > reason:
> >
> > It would need a handle. When I do not know the volume name, how do I open
> > the volume and get its handle to make an IOCTL call on it? Is there a way
> > (any driver routine) to get the volume handle in “AddDevice” from any of
> its
> > input parameter ?
> >
> > Thanks
> >
> > Jaswant
> >
> >
> >
> >
> > On 12 October 2010 23:34, Mark Roddy wrote:
> >>
> >> IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
> >> assuming you are actually filtering above a volume device.
> >>
> >> This ought to return you a VOLUME_DISK_EXTENTS object with an array of
> >> DISK_EXTENTS, one for each physical disk containing backing store for
> >> the volume, with the information about the size. in bytes, of each
> >> extent.
> >>
> >> Presumably you are going to pass on volumes with more than one extent.
> >>
> >> Mark Roddy
> >>
> >>
> >>
> >> On Tue, Oct 12, 2010 at 1:33 PM, Jaswanth Chajjed
> >> wrote:
> >> > But the target device is already mounted. I attach this filter driver
> >> > manually after booting to a non system partition (H:).
> >> >
> >> > Do you happen to have any other way on top of your mind through which
> I
> >> > can
> >> > acheive what I want i.e getting the volume/partition information
> >> > (length,
> >> > block size…)?
> >> >
> >> > Let me give you some background info for you to help me better.
> >> >
> >> > Purpose of this filter driver is to create a bitmap that would
> represent
> >> > volume blocks that have changed vs unchanged. So far driver has been
> >> > doing
> >> > well but with hardcoded values. i.e Bitmap array has been hardcoded
> for
> >> > a
> >> > known volume size. But in reality it can be anything. Right?
> >> >
> >> > So I thought it would be better to get the volume name in adddevice
> >> > (when
> >> > the filter driver is being attached) and query for its partition info
> to
> >> > create a Bitmaparray of appropriate size.
> >> >
> >> > Can you help me acheive this in some other way if the tried solution
> is
> >> > not
> >> > feasible?
> >> >
> >> > Regards
> >> >
> >> > Jaswant
> >> >
> >> > On 12 October 2010 19:23, Mark Roddy wrote:
> >> >>
> >> >> The ‘target device’ is the PDO and is unlikely to be the correct
> >> >> device object for IoVolumeDeviceToDosName. Not only that, but it is
> >> >> likely that at AddDevice there are no mount points for the volume. I
> >> >> think you need to wait for the volume to get mounted before you query
> >> >> its mount points. Perhaps IOCTL_MOUNTDEV_LINK_CREATED would be
> >> >> interesting to a volume filter driver.
> >> >>
> >> >> You continue to ignore the status returned - if this function returns
> >> >> an error there is no valid ‘dos name’. Printing the contents of the
> >> >> unicode string at this point is just asking for a BSOD.
> >> >>
> >> >>
> >> >> Mark Roddy
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Oct 12, 2010 at 8:20 AM, Jaswanth Chajjed
> >> >> wrote:
> >> >> > Hi Mark,
> >> >> >
> >> >> > Status code returned is “0xc000000e” - which I believe means
> >> >> > “no_such_device”
> >> >> >
> >> >> > Changed the code as follows (falling back to previous thing )
> >> >> >
> >> >> > static NTSTATUS AddDevice(IN PDRIVER_OBJECT pDriverObject, IN
> >> >> > PDEVICE_OBJECT pTargDev )
> >> >> > {
> >> >> > UNICODE_STRING DosName;
> >> >> > NTSTATUS status;
> >> >> > RtlInitUnicodeString(&DosName, NULL);
> >> >> > status = IoVolumeDeviceToDosName(pTargDev, &DosName);
> >> >> >
> >> >> > DbgPrint(“----Target Device name (unicode string) = %wZ\n”,
> >> >> > DosName);
> >> >> > DbgPrint(“----return status = %#010x\n”, status);
> >> >> > }
> >> >> >
> >> >> > Both unicode and wide string are printing NULL. Any reason why
> would
> >> >> > it
> >> >> > say
> >> >> > “no_such_device” ? I execute “addfilter” utility as below
> >> >> >
> >> >> > “addfilter.exe /device \HarddiskVolume4 /add myfilter”
> >> >> >
> >> >> > So the target device object that I get as parameter to adddevice
> >> >> > should
> >> >> > be
> >> >> > refering to this volume right ?
> >> >> >
> >> >> > Appreciate your help and thoughts once again.
> >> >> >
> >> >> > Regards
> >> >> >
> >> >> > Jaswant
> >> >> >
> >> >> > On 12 October 2010 17:23, Jaswanth Chajjed
> >> >> >
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi Mark,
> >> >> >>
> >> >> >> Thanks for your prompt reply.
> >> >> >>
> >> >> >> As a matter of fact, I did read this in WDDK doc.
> >> >> >>
> >> >> >> Before trying the current code, I did have PUNICODE_STRING
> variable
> >> >> >> (uninitialized) being passed to IoVolumeDeviceToDosName. Result
> was
> >> >> >> the
> >> >> >> same. Only after that, out of curiosity, I tried allocating the
> >> >> >> buffer.
> >> >> >>
> >> >> >> Let me check the return value. Will post back in few minutes.
> >> >> >>
> >> >> >> Regards
> >> >> >>
> >> >> >> Jaswant
> >> >> >>
> >> >> >> On 12 October 2010 16:54, Mark Roddy
> wrote:
> >> >> >>>
> >> >> >>> Did you try reading the documentation for
> IoVolumeDeviceToDosName?
> >> >> >>>
> >> >> >>> 1) it returns a status value. That value just might be important.
> >> >> >>> 2) it allocates the buffer for the UNICODE_STRING.
> >> >> >>>
> >> >> >>> “IoVolumeDeviceToDosName allocates the Unicode string buffer for
> >> >> >>> the
> >> >> >>> MS-DOS path from the memory pool. After the buffer is no longer
> >> >> >>> required, a caller of this routine should use ExFreePool to free
> >> >> >>> it.”
> >> >> >>>
> >> >> >>>
> >> >> >>> Mark Roddy
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> On Tue, Oct 12, 2010 at 5:47 AM,
> >> >> >>> wrote:
> >> >> >>> > IoVolumeDeviceToDosName
> >> >> >>>
> >> >> >>> —
> >> >> >>> NTDEV is sponsored by OSR
> >> >> >>>
> >> >> >>> For our schedule of WDF, WDM, debugging and other 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
> >> >> >>
> >> >> >
> >> >> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM,
> debugging
> >> >> > and
> >> >> > other 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
> >> >>
> >> >> —
> >> >> NTDEV is sponsored by OSR
> >> >>
> >> >> For our schedule of WDF, WDM, debugging and other 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
> >> >
> >> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
> >> > and
> >> > other 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
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other 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
> >
> > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> > other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

12

> Get the Volume/partition`s length/Block Size etc (basically partition_info). To do this, I need to know

the volume/partition name.

Not so.

You can just send the query IOCTLs down the PnP stack.

Note that, this can only be done in MN_START_DEVICE, AddDevice is too early.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

How about doing below?

I have application pass on a user defined structure filled with required
info to the driver through a custom IOCTL call. Driver upon receiving this
IOCTL, stores it in the registry.

Upon reboot, while filter driver is added to appropriate volumes, it reads
the value from the registry and initialize it. Just a thought?

If possible, then which solution would be “*Ideal*” ? Through registry or to
get the volumes length dynamically in driver ?

Regards

Jaswant

On 13 October 2010 13:27, Maxim S. Shatskih wrote:

> > Get the Volume/partition`s length/Block Size etc (basically
> partition_info). To do this, I need to know
> >the volume/partition name.
>
> Not so.
>
> You can just send the query IOCTLs down the PnP stack.
>
> Note that, this can only be done in MN_START_DEVICE, AddDevice is too
> early.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

14

Mark/Maxim,

I did try building an IRP through “*IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS*”
when the IRP minor request is “IRP_MN_START_DEVICE” in my filter driver.
When I call the target volumes driver with this IRP, it returns “0xc000000e”
which I believe no_such_device.

*Below is the code:*
*
PIRP irp;
KEVENT event;
VOLUME_DISK_EXTENTS extents;
IO_STATUS_BLOCK ioStatus;

irp = IoBuildDeviceIoControlRequest(
IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS,
pDevExt->pTargStack,
NULL,
0,
&extents,
sizeof(extents),
FALSE,
&event,
&ioStatus);
if (!irp) {
DbgPrint(“Failed to build irp for
IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control code\n”);
}

status = IoCallDriver(pDevExt->pTargStack, irp);
DbgPrint(“Status = %#x\n”, status); // -----------------
Returns 0xc000000e
if (status == STATUS_PENDING) {
DbgPrint(“----Status is pending so waiting for KeEvent
Single Object\n”);
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
NULL);
status = ioStatus.Status;
} else {

DbgPrint(“Status is not pending\n”);

}

if (NT_SUCCESS(status)) {
DbgPrint(“Volume Extents = %#x\n”,
extents.NumberOfDiskExtents);
}
}*

Any idea/pointers on what is wrong?

Jaswant

On 13 October 2010 17:11, Jaswanth Chajjed wrote:

> How about doing below?
>
> I have application pass on a user defined structure filled with required
> info to the driver through a custom IOCTL call. Driver upon receiving this
> IOCTL, stores it in the registry.
>
> Upon reboot, while filter driver is added to appropriate volumes, it reads
> the value from the registry and initialize it. Just a thought?
>
> If possible, then which solution would be “Ideal” ? Through registry or
> to get the volumes length dynamically in driver ?
>
> Regards
>
> Jaswant
>
>
> On 13 October 2010 13:27, Maxim S. Shatskih wrote:
>
>> > Get the Volume/partition`s length/Block Size etc (basically
>> partition_info). To do this, I need to know
>> >the volume/partition name.
>>
>> Not so.
>>
>> You can just send the query IOCTLs down the PnP stack.
>>
>> Note that, this can only be done in MN_START_DEVICE, AddDevice is too
>> early.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>>
>
>

15

Hey Mark/Maxim,

Thank you so much for your help and suggestion. I finally got it working.
Problem was that I was trying to send the IOCTL call even before
start_device.

Changed it after start_device and it seems to be working pretty well. Thank
you again.

Jaswant

On 13 October 2010 18:03, Jaswanth Chajjed wrote:

> Mark/Maxim,
>
> I did try building an IRP through “IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS”
> when the IRP minor request is “IRP_MN_START_DEVICE” in my filter driver.
> When I call the target volumes driver with this IRP, it returns “0xc000000e”
> which I believe no_such_device.
>
> Below is the code:
>
> PIRP irp;
> KEVENT event;
> VOLUME_DISK_EXTENTS extents;
> IO_STATUS_BLOCK ioStatus;
>
> irp = IoBuildDeviceIoControlRequest(
> IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS,
> pDevExt->pTargStack,
> NULL,
> 0,
> &extents,
> sizeof(extents),
> FALSE,
> &event,
> &ioStatus);
> if (!irp) {
> DbgPrint(“Failed to build irp for
> IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control code\n”);
> }
>
> status = IoCallDriver(pDevExt->pTargStack, irp);
> DbgPrint(“Status = %#x\n”, status); // -----------------
> Returns 0xc000000e
> if (status == STATUS_PENDING) {
> DbgPrint(“----Status is pending so waiting for KeEvent
> Single Object\n”);
> KeWaitForSingleObject(&event, Executive, KernelMode, FALSE,
> NULL);
> status = ioStatus.Status;
> } else {
>
> DbgPrint(“Status is not pending\n”);
>
> }
>
> if (NT_SUCCESS(status)) {
> DbgPrint(“Volume Extents = %#x\n”,
> extents.NumberOfDiskExtents);
> }
> }
>
> Any idea/pointers on what is wrong?
>
> Jaswant
>
>
> On 13 October 2010 17:11, Jaswanth Chajjed wrote:
>
>> How about doing below?
>>
>> I have application pass on a user defined structure filled with required
>> info to the driver through a custom IOCTL call. Driver upon receiving this
>> IOCTL, stores it in the registry.
>>
>> Upon reboot, while filter driver is added to appropriate volumes, it reads
>> the value from the registry and initialize it. Just a thought?
>>
>> If possible, then which solution would be “Ideal” ? Through registry or
>> to get the volumes length dynamically in driver ?
>>
>> Regards
>>
>> Jaswant
>>
>>
>> On 13 October 2010 13:27, Maxim S. Shatskih wrote:
>>
>>> > Get the Volume/partition`s length/Block Size etc (basically
>>> partition_info). To do this, I need to know
>>> >the volume/partition name.
>>>
>>> Not so.
>>>
>>> You can just send the query IOCTLs down the PnP stack.
>>>
>>> Note that, this can only be done in MN_START_DEVICE, AddDevice is too
>>> early.
>>>
>>> –
>>> Maxim S. Shatskih
>>> Windows DDK MVP
>>> xxxxx@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other 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
>>>
>>
>>
>