In my bus driver in both EvtDeviceAdd and EvtChildListCreateDevice, I
say something like:
WDF_DEVICE_POWER_CAPABILITIES_INIT(&power_capabilities);
power_capabilities.DeviceD1 = WdfTrue;
power_capabilities.WakeFromD1 = WdfTrue;
power_capabilities.DeviceWake = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemWorking] = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemSleeping1] = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemSleeping2] = PowerDeviceD2;
power_capabilities.DeviceState[PowerSystemSleeping3] = PowerDeviceD2;
power_capabilities.DeviceState[PowerSystemHibernate] = PowerDeviceD3;
power_capabilities.DeviceState[PowerSystemShutdown] = PowerDeviceD3;
WdfDeviceSetPowerCapabilities(device, &power_capabilities);
A user is reporting a crash when he puts the system to sleep (the crash
occurs shortly after wake up), and when I look at the debug trace, my
bus fdo and pdo’s EvtDeviceD0Exit routines are being called with
WdfPowerDeviceD3, which I was a little bit surprised by, especially as
my driver is in the paging path. I have yet to confirm that by ‘sleep’
the user meant ‘stand by’ and not ‘hibernate’, but the debug trace does
not suggest that it was hibernate…
So I have the following possibilities:
. The above power_capabilities setup is wrong
. D3 is correct for a ‘stand by’, and my understanding is wrong
. WDF is exhibiting the same sort of problem that I had with hibernate
(see previous thread) and I need to apply the same sort of fix
. Something else 
Help?
Thanks
James
The pwr cap array is a listing of lightest sleep states supported for the s state. A fdo can always decide to go into a lower/deeper d state than what is listed
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: James Harper
Sent: Friday, June 05, 2009 9:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] power state question - D3 for standby???
In my bus driver in both EvtDeviceAdd and EvtChildListCreateDevice, I
say something like:
WDF_DEVICE_POWER_CAPABILITIES_INIT(&power_capabilities);
power_capabilities.DeviceD1 = WdfTrue;
power_capabilities.WakeFromD1 = WdfTrue;
power_capabilities.DeviceWake = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemWorking] = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemSleeping1] = PowerDeviceD1;
power_capabilities.DeviceState[PowerSystemSleeping2] = PowerDeviceD2;
power_capabilities.DeviceState[PowerSystemSleeping3] = PowerDeviceD2;
power_capabilities.DeviceState[PowerSystemHibernate] = PowerDeviceD3;
power_capabilities.DeviceState[PowerSystemShutdown] = PowerDeviceD3;
WdfDeviceSetPowerCapabilities(device, &power_capabilities);
A user is reporting a crash when he puts the system to sleep (the crash
occurs shortly after wake up), and when I look at the debug trace, my
bus fdo and pdo’s EvtDeviceD0Exit routines are being called with
WdfPowerDeviceD3, which I was a little bit surprised by, especially as
my driver is in the paging path. I have yet to confirm that by ‘sleep’
the user meant ‘stand by’ and not ‘hibernate’, but the debug trace does
not suggest that it was hibernate…
So I have the following possibilities:
. The above power_capabilities setup is wrong
. D3 is correct for a ‘stand by’, and my understanding is wrong
. WDF is exhibiting the same sort of problem that I had with hibernate
(see previous thread) and I need to apply the same sort of fix
. Something else
Help?
Thanks
James
—
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
>
The pwr cap array is a listing of lightest sleep states supported for
the s
state. A fdo can always decide to go into a lower/deeper d state than
what is
listed
Understood. So D3 is an acceptable sleep state for a driver in the
paging path when the system gets put into StandBy? If so, then the bug
is obviously in my driver, where I should have been looking all along 
Thanks
James
the sleep state array really has nothing to do with hiber or the paging path. if a driver knows it is in the hiber path, it will not power down the device. as for the paging path, once all power pagable stacks are down, the paging device may be powered down. what is the fdo on top of your pdo?
d
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of James Harper [xxxxx@bendigoit.com.au]
Sent: Friday, June 05, 2009 11:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] power state question - D3 for standby???
The pwr cap array is a listing of lightest sleep states supported for
the s
state. A fdo can always decide to go into a lower/deeper d state than
what is
listed
Understood. So D3 is an acceptable sleep state for a driver in the
paging path when the system gets put into StandBy? If so, then the bug
is obviously in my driver, where I should have been looking all along
Thanks
James
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
>
the sleep state array really has nothing to do with hiber or the
paging path.
if a driver knows it is in the hiber path, it will not power down the
device.
as for the paging path, once all power pagable stacks are down, the
paging
device may be powered down. what is the fdo on top of your pdo?
The PCI bus enumerates a pdo and windows loads my bus driver (xenpci) as
the fdo for it. My bus fdo enumerates pdo’s for network, block device,
and scsi passthrough device. My NDIS5 driver (xennet) attaches to the
network pdo, and scsiport drivers attach to the block device (xenvbd)
and scsi passthrough (xenscsi) pdo’s. The block device and scsi
passthrough interface to xen are sufficiently different that I wrote
separate drivers for them, even though they are both scsiport.
Xenpci is a KMDF driver, and obviously the others are just miniport
drivers.
xenvbd runs the boot device. In theory, xenscsi probably could be used
to boot although I don’t think the BIOS that xen gives to virtual
machines support scsi booting.
I’m not sure I completely understand what you are saying, but my
interpretation is that what I am seeing Windows do is correct, and that
my driver is not handling the power down + power up sequence correctly.
Thanks Doron!
James