IoReadPartitionTableEx

Hello

In my driver, a call to IoReadPartitionTableEx returns with
STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns successfully.
Running on WindowsXP with most latest service packs, building the driver with
WDK6000. When compiling with IoReadPartitionTable call in the code, get a
warning about the function being deprecated

Doron
Wed Oct 10 15:50:49 PDT 2007

as far as i can tell, this can only be returned by the storage stack itself.
the Io code does not have this error code explicitly.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:008879DD-D164-4F1C-B768-E56A0C2F95A2@microsoft.com...
> Hello
>
> In my driver, a call to IoReadPartitionTableEx returns with
> STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns successfully.
> Running on WindowsXP with most latest service packs, building the driver
> with
> WDK6000. When compiling with IoReadPartitionTable call in the code, get a
> warning about the function being deprecated

Maxim
Wed Oct 10 16:22:01 PDT 2007

Interesting. I believe my driver is the storage stack in itself, i.e. I am
doing this within my own disk class driver. I was under the impression that
IoReadPartition* functions would actually go and read the disk media and
parse the MBR or the GPT partition tables. Looking at accesses to my device,
I believe
thats what IoReadPartitionTable does... Is that not so?

"Doron Holan [MSFT]" wrote:

> as far as i can tell, this can only be returned by the storage stack itself.
> the Io code does not have this error code explicitly.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
> news:008879DD-D164-4F1C-B768-E56A0C2F95A2@microsoft.com...
> > Hello
> >
> > In my driver, a call to IoReadPartitionTableEx returns with
> > STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns successfully.
> > Running on WindowsXP with most latest service packs, building the driver
> > with
> > WDK6000. When compiling with IoReadPartitionTable call in the code, get a
> > warning about the function being deprecated
>
>

Doron
Wed Oct 10 16:30:24 PDT 2007

it does read the tables, but it does so by sending io ioctls to the storage
stack so if you are in the stack, look at which IOCTLs you are failing. one
easy check would be to return a different error code in your class driver
for unknown IOCTLs and see if that new error code is returned from
IoReadPartitionTableEx

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:816E8E45-4157-43CD-B686-C9CEEF5059B8@microsoft.com...
> Interesting. I believe my driver is the storage stack in itself, i.e. I
> am
> doing this within my own disk class driver. I was under the impression
> that
> IoReadPartition* functions would actually go and read the disk media and
> parse the MBR or the GPT partition tables. Looking at accesses to my
> device,
> I believe
> thats what IoReadPartitionTable does... Is that not so?
>
> "Doron Holan [MSFT]" wrote:
>
>> as far as i can tell, this can only be returned by the storage stack
>> itself.
>> the Io code does not have this error code explicitly.
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
>> news:008879DD-D164-4F1C-B768-E56A0C2F95A2@microsoft.com...
>> > Hello
>> >
>> > In my driver, a call to IoReadPartitionTableEx returns with
>> > STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns
>> > successfully.
>> > Running on WindowsXP with most latest service packs, building the
>> > driver
>> > with
>> > WDK6000. When compiling with IoReadPartitionTable call in the code,
>> > get a
>> > warning about the function being deprecated
>>
>>

Maxim
Wed Oct 10 17:17:01 PDT 2007

OK, now it looks like catch-22. I was using these calls from inside the
driver on startup to get the partition data which I could then return in
response to IOCTLs such as IOCTL_DISK_GET_DRIVE_LAYOUT_EX. If these calls
actually perform the media reads themselves, then what is the point of them
sending IOCTLs? If on the other hand they are nothing but wrappers for
IOCTLs, then whats the purpose of having them and also is there any assist in
the kernel for reading/parsing MBR/GPT data or does my driver have to read
and parse the data itself?

I do dump all the IOCTLs to the log, btw, but if there is an
inter-dependency, then it is of little use.


"Doron Holan [MSFT]" wrote:

> it does read the tables, but it does so by sending io ioctls to the storage
> stack so if you are in the stack, look at which IOCTLs you are failing. one
> easy check would be to return a different error code in your class driver
> for unknown IOCTLs and see if that new error code is returned from
> IoReadPartitionTableEx
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
> news:816E8E45-4157-43CD-B686-C9CEEF5059B8@microsoft.com...
> > Interesting. I believe my driver is the storage stack in itself, i.e. I
> > am
> > doing this within my own disk class driver. I was under the impression
> > that
> > IoReadPartition* functions would actually go and read the disk media and
> > parse the MBR or the GPT partition tables. Looking at accesses to my
> > device,
> > I believe
> > thats what IoReadPartitionTable does... Is that not so?
> >
> > "Doron Holan [MSFT]" wrote:
> >
> >> as far as i can tell, this can only be returned by the storage stack
> >> itself.
> >> the Io code does not have this error code explicitly.
> >>
> >> d
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
> >> news:008879DD-D164-4F1C-B768-E56A0C2F95A2@microsoft.com...
> >> > Hello
> >> >
> >> > In my driver, a call to IoReadPartitionTableEx returns with
> >> > STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns
> >> > successfully.
> >> > Running on WindowsXP with most latest service packs, building the
> >> > driver
> >> > with
> >> > WDK6000. When compiling with IoReadPartitionTable call in the code,
> >> > get a
> >> > warning about the function being deprecated
> >>
> >>
>
>

Doron
Wed Oct 10 17:32:27 PDT 2007

the routine do not read the media themselves, they rely on the storage stack
to do the reads. the routines exist to give unified functionality so that
any component, storage based or not, can get the partition table. to
process the IOCTLs at the lowest levels of the storage stack, you must do
this on your own in your driver since this can be specific to your device.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim" <Maxim@discussions.microsoft.com> wrote in message
news:CDCEE549-687F-45AC-A306-89492EA3DC91@microsoft.com...
> OK, now it looks like catch-22. I was using these calls from inside the
> driver on startup to get the partition data which I could then return in
> response to IOCTLs such as IOCTL_DISK_GET_DRIVE_LAYOUT_EX. If these
> calls
> actually perform the media reads themselves, then what is the point of
> them
> sending IOCTLs? If on the other hand they are nothing but wrappers for
> IOCTLs, then whats the purpose of having them and also is there any assist
> in
> the kernel for reading/parsing MBR/GPT data or does my driver have to read
> and parse the data itself?
>
> I do dump all the IOCTLs to the log, btw, but if there is an
> inter-dependency, then it is of little use.
>
>
> "Doron Holan [MSFT]" wrote:
>
>> it does read the tables, but it does so by sending io ioctls to the
>> storage
>> stack so if you are in the stack, look at which IOCTLs you are failing.
>> one
>> easy check would be to return a different error code in your class driver
>> for unknown IOCTLs and see if that new error code is returned from
>> IoReadPartitionTableEx
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
>> news:816E8E45-4157-43CD-B686-C9CEEF5059B8@microsoft.com...
>> > Interesting. I believe my driver is the storage stack in itself, i.e.
>> > I
>> > am
>> > doing this within my own disk class driver. I was under the impression
>> > that
>> > IoReadPartition* functions would actually go and read the disk media
>> > and
>> > parse the MBR or the GPT partition tables. Looking at accesses to my
>> > device,
>> > I believe
>> > thats what IoReadPartitionTable does... Is that not so?
>> >
>> > "Doron Holan [MSFT]" wrote:
>> >
>> >> as far as i can tell, this can only be returned by the storage stack
>> >> itself.
>> >> the Io code does not have this error code explicitly.
>> >>
>> >> d
>> >>
>> >> --
>> >> Please do not send e-mail directly to this alias. this alias is for
>> >> newsgroup purposes only.
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >> "Maxim" <Maxim@discussions.microsoft.com> wrote in message
>> >> news:008879DD-D164-4F1C-B768-E56A0C2F95A2@microsoft.com...
>> >> > Hello
>> >> >
>> >> > In my driver, a call to IoReadPartitionTableEx returns with
>> >> > STATUS_NOT_IMPLEMENTED whereas IoReadPartitionTable returns
>> >> > successfully.
>> >> > Running on WindowsXP with most latest service packs, building the
>> >> > driver
>> >> > with
>> >> > WDK6000. When compiling with IoReadPartitionTable call in the code,
>> >> > get a
>> >> > warning about the function being deprecated
>> >>
>> >>
>>
>>

Maxim
Wed Oct 10 17:53:01 PDT 2007

Thats really strange. The documentation from MSDN says something quiet
opposite. Pasting below straight from the MSDN:

IoReadPartitionTableEx must only be used by disk drivers. Other drivers
should
use the IOCTL_DISK_GET_DRIVE_LAYOUT_EX disk I/O request instead.
...
IoReadPartitionTableEx is able to read partition table information from
GUID
Partition Table (GPT) disks as well as legacy Master Boot Record (MBR)
disks.
Disk device drivers call this routine during driver initialization.

I will disable IOCTL handling altogether in my driver and try issuing
IoReadPartitionTable. Will post the results once I have them.


"Doron Holan [MSFT]" wrote:

> the routine do not read the media themselves, they rely on the storage stack
> to do the reads. the routines exist to give unified functionality so that
> any component, storage based or not, can get the partition table. to
> process the IOCTLs at the lowest levels of the storage stack, you must do
> this on your own in your driver since this can be specific to your device.
>
> d

Maxim
Wed Oct 10 20:23:16 PDT 2007

> actually perform the media reads themselves, then what is the point of them
> sending IOCTLs? If on the other hand they are nothing but wrappers for
> IOCTLs

No.

IoReadPartitionTable(Ex) is the function which really reads the partition table
sectors from the disk by handicrafted MJ_READ IRPs (and possibly some IOCTLs),
then parses the MBR or GPT on-disk data and fills the
DRIVE_LAYOUT_INFORMATION(_EX), which is the universal format of the partition
table data.

The reason for existence of this functions is to remove the MBR/GPT parsing
code from Disk.sys to the kernel (actually the HAL due to some very old reasons
of NT3 times).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Oct 10 22:11:02 PDT 2007

Aha, thats what I thought. This serves my intended purposes very well, since
I am effectively replacing disk.sys. Perhaps you might have an idea then of
why IoReadPartitionTable works fine, but IoReadPartitionTableEx returns with
STATUS_NOT_IMPLEMENTED?

"Maxim S. Shatskih" wrote:

> No.
>
> IoReadPartitionTable(Ex) is the function which really reads the partition table
> sectors from the disk by handicrafted MJ_READ IRPs (and possibly some IOCTLs),
> then parses the MBR or GPT on-disk data and fills the
> DRIVE_LAYOUT_INFORMATION(_EX), which is the universal format of the partition
> table data.
>
> The reason for existence of this functions is to remove the MBR/GPT parsing
> code from Disk.sys to the kernel (actually the HAL due to some very old reasons
> of NT3 times).

Maxim
Thu Oct 11 08:37:04 PDT 2007

OK, so I correlated IoReadPartitionTableEx/IoWritePartitionTableEx functions
with IOCTLs that they issue. Both issue IOCTL_GET_DRIVE_GEOMETRY_EX IOCTL,
which fails in my IOCTL handler because I was trying to get an output buffer
of sizeof(DISK_GEOMETRY_EX), which failed and in turn functions failed. When
requesting an output buffer of size FIELD_OFFSET(DISK_GEOMETRY_EX, Data)
(which is what CDROM sample driver does), it succeeded and in turn IO
functions succeed.

Frustrating... Why describe DISK_GEOMETRY_EX in the documentation as having
a field (+ 2 additional structures at the end) if the kernel functions that
use it do not allocate space for those structures and fail unconditinally
even when their IOCTLs return with STATUS_BUFFER_TOO_SMALL...

Thanks for both of you guys' help!

"Maxim S. Shatskih" wrote:

> > actually perform the media reads themselves, then what is the point of them
> > sending IOCTLs? If on the other hand they are nothing but wrappers for
> > IOCTLs
>
> No.
>
> IoReadPartitionTable(Ex) is the function which really reads the partition table
> sectors from the disk by handicrafted MJ_READ IRPs (and possibly some IOCTLs),
> then parses the MBR or GPT on-disk data and fills the
> DRIVE_LAYOUT_INFORMATION(_EX), which is the universal format of the partition
> table data.
>
> The reason for existence of this functions is to remove the MBR/GPT parsing
> code from Disk.sys to the kernel (actually the HAL due to some very old reasons
> of NT3 times).
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Maxim
Thu Oct 11 08:36:04 PDT 2007

OK, so I correlated IoReadPartitionTableEx/IoWritePartitionTableEx functions
with IOCTLs that they issue. Both issue IOCTL_GET_DRIVE_GEOMETRY_EX IOCTL,
which fails in my IOCTL handler because I was trying to get an output buffer
of sizeof(DISK_GEOMETRY_EX), which failed and in turn functions failed. When
requesting an output buffer of size FIELD_OFFSET(DISK_GEOMETRY_EX, Data)
(which is what CDROM sample driver does), it succeeded and in turn IO
functions succeed.

Frustrating... Why describe DISK_GEOMETRY_EX in the documentation as having
a field (+ 2 additional structures at the end) if the kernel functions that
use it do not allocate space for those structures and fail unconditinally
even when their IOCTLs return with STATUS_BUFFER_TOO_SMALL...

Thanks for both of you guys' help!

"Maxim S. Shatskih" wrote:

> > actually perform the media reads themselves, then what is the point of them
> > sending IOCTLs? If on the other hand they are nothing but wrappers for
> > IOCTLs
>
> No.
>
> IoReadPartitionTable(Ex) is the function which really reads the partition table
> sectors from the disk by handicrafted MJ_READ IRPs (and possibly some IOCTLs),
> then parses the MBR or GPT on-disk data and fills the
> DRIVE_LAYOUT_INFORMATION(_EX), which is the universal format of the partition
> table data.
>
> The reason for existence of this functions is to remove the MBR/GPT parsing
> code from Disk.sys to the kernel (actually the HAL due to some very old reasons
> of NT3 times).
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>