Hi all,
I have the following problem under Windows 2000 SP4 and SP4 with RUP2. I
need to change a drive layout, to be exact, to change a starting offset
and length of a particular partition which resides in a basic disk. So
I’m reading a partition table using IOCTL_DISK_GET_DRIVE_LAYOUT, then
I’m changing one partition entry, marking it as “RewritePartition” and
reseting PartitionNumber for all partition entries in the received drive
layout. But after IOCTL_DISK_SET_DRIVE_LAYOUT returns with success,
PartitionCount in the drive layout structure is set to 1, though before
issuing IOCTL_DISK_SET_DRIVE_LAYOUT it was, say, 4 (for my current disk
configuration). I make this call from my upper filter driver for disk
class drive. I thought that I was doing something wrong, so I tried to
intercept IOCTL_DISK_SET_DRIVE_LAYOUT calls from dmadmin.exe application
and saw the same behavior. Under Windows XP I use
IOCTL_DISK_GET_DRIVE_LAYOUT_EX and IOCTL_DISK_SET_DRIVE_LAYOUT_EX codes
(and it works fine) which are not supported on Windows 2000, despite the
fact that the last WDK docs assert the following:
“In Windows 2000 and later operating systems, disk drivers should use
structures DRIVE_LAYOUT_INFORMATION_EX
<structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm> and
PARTITION_INFORMATION_EX
<structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm> along with
routines IoReadPartitionTableEx and IoSetPartitionInformationEx
<rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm> to read and
alter partition information on the disk.”
I’m really stuck. Plus I noticed a kind of odd behavior in
IRP_MN_QUERY_DEVICE_RELATIONS handler. I synchronously pass this request
to a lower driver and then in case of success check
Irp->IoStatus.Information value. As the WDK docs implies, on success
this field contains a pointer to a DEVICE_RELATIONS structure, but
sometimes this value is NULL even if Status == STATUS_SUCCESS, for
example, when a safe device removal is requested!
Thanks beforehand, any suggestions will be very appreciated.
With best regards,
Konstantin Manurin</rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm></structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm></structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm>
IIRC, NT_SUCCESS and NULL is acceptable the equivalent of a DEVICE_RELATIONS with a zero count
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Konstantin Manurin
Sent: Thursday, October 18, 2007 1:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IOCTL_DISK_SET_DRIVE_LAYOUT and IRP_MN_QUERY_DEVICE_RELATIONS strange behavior
Hi all,
I have the following problem under Windows 2000 SP4 and SP4 with RUP2. I
need to change a drive layout, to be exact, to change a starting offset
and length of a particular partition which resides in a basic disk. So
I’m reading a partition table using IOCTL_DISK_GET_DRIVE_LAYOUT, then
I’m changing one partition entry, marking it as “RewritePartition” and
reseting PartitionNumber for all partition entries in the received drive
layout. But after IOCTL_DISK_SET_DRIVE_LAYOUT returns with success,
PartitionCount in the drive layout structure is set to 1, though before
issuing IOCTL_DISK_SET_DRIVE_LAYOUT it was, say, 4 (for my current disk
configuration). I make this call from my upper filter driver for disk
class drive. I thought that I was doing something wrong, so I tried to
intercept IOCTL_DISK_SET_DRIVE_LAYOUT calls from dmadmin.exe application
and saw the same behavior. Under Windows XP I use
IOCTL_DISK_GET_DRIVE_LAYOUT_EX and IOCTL_DISK_SET_DRIVE_LAYOUT_EX codes
(and it works fine) which are not supported on Windows 2000, despite the
fact that the last WDK docs assert the following:
“In Windows 2000 and later operating systems, disk drivers should use
structures DRIVE_LAYOUT_INFORMATION_EX
<structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm> and
PARTITION_INFORMATION_EX
<structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm> along with
routines IoReadPartitionTableEx and IoSetPartitionInformationEx
<rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm> to read and
alter partition information on the disk.”
I’m really stuck. Plus I noticed a kind of odd behavior in
IRP_MN_QUERY_DEVICE_RELATIONS handler. I synchronously pass this request
to a lower driver and then in case of success check
Irp->IoStatus.Information value. As the WDK docs implies, on success
this field contains a pointer to a DEVICE_RELATIONS structure, but
sometimes this value is NULL even if Status == STATUS_SUCCESS, for
example, when a safe device removal is requested!
Thanks beforehand, any suggestions will be very appreciated.
With best regards,
Konstantin Manurin
—
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</rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm></structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm></structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm>
Doron,
Thank you very much for this detail. I suspected this behavior is just
like you described, but asked this question to make it more accurate.
With best regards,
Konstantin Manurin
Doron Holan wrote:
IIRC, NT_SUCCESS and NULL is acceptable the equivalent of a DEVICE_RELATIONS with a zero count
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Konstantin Manurin
Sent: Thursday, October 18, 2007 1:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IOCTL_DISK_SET_DRIVE_LAYOUT and IRP_MN_QUERY_DEVICE_RELATIONS strange behavior
Hi all,
I have the following problem under Windows 2000 SP4 and SP4 with RUP2. I
need to change a drive layout, to be exact, to change a starting offset
and length of a particular partition which resides in a basic disk. So
I’m reading a partition table using IOCTL_DISK_GET_DRIVE_LAYOUT, then
I’m changing one partition entry, marking it as “RewritePartition” and
reseting PartitionNumber for all partition entries in the received drive
layout. But after IOCTL_DISK_SET_DRIVE_LAYOUT returns with success,
PartitionCount in the drive layout structure is set to 1, though before
issuing IOCTL_DISK_SET_DRIVE_LAYOUT it was, say, 4 (for my current disk
configuration). I make this call from my upper filter driver for disk
class drive. I thought that I was doing something wrong, so I tried to
intercept IOCTL_DISK_SET_DRIVE_LAYOUT calls from dmadmin.exe application
and saw the same behavior. Under Windows XP I use
IOCTL_DISK_GET_DRIVE_LAYOUT_EX and IOCTL_DISK_SET_DRIVE_LAYOUT_EX codes
(and it works fine) which are not supported on Windows 2000, despite the
fact that the last WDK docs assert the following:
“In Windows 2000 and later operating systems, disk drivers should use
structures DRIVE_LAYOUT_INFORMATION_EX
<structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm> and
> PARTITION_INFORMATION_EX
> <structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm> along with
> routines IoReadPartitionTableEx and IoSetPartitionInformationEx
> <rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm> to read and
> alter partition information on the disk.”
>
> I’m really stuck. Plus I noticed a kind of odd behavior in
> IRP_MN_QUERY_DEVICE_RELATIONS handler. I synchronously pass this request
> to a lower driver and then in case of success check
> Irp->IoStatus.Information value. As the WDK docs implies, on success
> this field contains a pointer to a DEVICE_RELATIONS structure, but
> sometimes this value is NULL even if Status == STATUS_SUCCESS, for
> example, when a safe device removal is requested!
>
> Thanks beforehand, any suggestions will be very appreciated.
>
>
> With best regards,
> Konstantin Manurin
>
> —
> 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
>
></rtns-disk_7fd49999-70b3-4d59-b281-ff24b8a22a30.xml.htm></structs-disk_459428ff-6869-41c6-b72f-94721018f66e.xml.htm></structs-disk_e6755f07-50a7-48db-a39c-4485f3fb7b93.xml.htm>