IOCTL_DISK_GET_DRIVE_GEOMETRY_EX not returning disk size immediately

Hi folks,

We have a disk class upper filter, and in our EvtDriverDeviceAdd function,
we are sending IOCTL_DISK_GET_DRIVE_GEOMETRY_EX to the underlying device
(whose IoTarget we obtained via WdfDeviceGetIoTarget).

The ioctl always succeeds, but doesn’t immediately populate it’s returned
DISK_GEOMETRY_EX.DiskSize field. To account for this, we have to delay a few
ms and try again. Eventually, it always comes back with a valid (nonzero)
size.

All we really need is the size of the added disk (we don’t need the
geometry), so …

  1. is there a better way to get this info than using this ioctl?

  2. if not, is this expected behavior? The msdn page for this ioctl mentions
    needing to wait for partition information to appear (if using GPT), but I
    have a feeling that the page is wrong (looks like that part of the commentary
    applies to a different ioctl). We only care about the disk size, not partitions.

PS we are using WdfIoTargetSendIoctlSynchronously, in case that makes any
difference.

Thanks.

-ml

Fixed or removable device?

EvtDriverDeviceAdd *really* isn’t the best place to be doing this… Your devnode isn’t even necessarily in D0 at this point.

Peter
OSR
@OSRDrivers

On Fri, Oct 14, 2016 at 04:05:00PM -0400, xxxxx@osr.com wrote:

Fixed or removable device?

Fixed.

EvtDriverDeviceAdd *really* isn’t the best place to be doing this… Your devnode isn’t even necessarily in D0 at this point.

That could explain things. Maybe wait for the D0 transition and query the
geometry there? Or is there another subsequent transition that’s more
appropriate?

Thanks Peter.

-ml

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:
>
> 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:</http:></http:></http:>

Yes. Or do it in EvtDevicePrepareHardware. While technically not yet informed of the D0 transition, your device will be in D0 when PrepareHardware is called.

Increasingly, devs I know (including myslelf) are seeing PrepareHardware as the place to do one time initialization taks, and restricting EvtDeviceD0Entry to those things that need done for @every@ Dx to D0 transition.

Give it a try…

Peter
OSR
@OSRDrivers

On Sun, Oct 16, 2016 at 10:02:04AM -0400, xxxxx@osr.com wrote:

Yes. Or do it in EvtDevicePrepareHardware. While technically not yet informed of the D0 transition, your device will be in D0 when PrepareHardware is called.

Increasingly, devs I know (including myslelf) are seeing PrepareHardware as the place to do one time initialization taks, and restricting EvtDeviceD0Entry to those things that need done for @every@ Dx to D0 transition.

Give it a try…

Thanks Peter, will give it a shot!

-ml

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:
>
> 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:</http:></http:></http:>

On Sun, Oct 16, 2016 at 10:02:04AM -0400, xxxxx@osr.com wrote:

Yes. Or do it in EvtDevicePrepareHardware. While technically not yet informed of the D0 transition, your device will be in D0 when PrepareHardware is called.

Increasingly, devs I know (including myslelf) are seeing PrepareHardware as the place to do one time initialization taks, and restricting EvtDeviceD0Entry to those things that need done for @every@ Dx to D0 transition.

Give it a try…

Peter
OSR
@OSRDrivers

Just to close out this thread - waiting to query the size until PrepareHardware
is called works fine. Thanks Peter.

-ml

YAY!

Thanks for closing the loop and getting back to us.

Glad it worked for you.

Peter
OSR
@OSRDrivers