Hi,

WDF documentation states that WdfDeviceAssignSxWakeSettings might fail on
some systems or platforms, so driver shouldn't fail to load based on an
un-success return status.

1. In my experiment and on several different platforms which I've tested, I
only saw this behaviour on one particular system. On this system,
WdfDeviceAssignS0IdleSettings also fails. Is there any common reason behind
failure of both functions (WDF samples will fail DriverEntry if
WdfDeviceAssignS0IdleSettings fails, something which I avoided to get the
driver load on this system).

2. On the same platform, I noticed that the PCI power capabilities of the
bus my device is attached to, reports that it does not support wakes from Dx
states. My device reports it supports wakes from D0 as well as all Dx states.
Could this be the reason the Framework fails the call to
WdfDeviceAssignSxWakeSettings? I.e. WDF assumes when the enumerator does not
support a power state, the child devices won't and shouldn't support it too?

3. Under what circumstances (apart from those documented) calls to these two
functions will fail?

Thanks
Harison213

--
There are 10 kinds of people in the world: those who understand binary, and
those who don''t!

1) WdfDeviceAssignSxWakeSettings cannot be called from DriverEntry b/c you
don't have a pnp device there, so i am confused by this statement. did you
mean EvtDriverDeviceAdd?
2) WDF sends a query capabilities irp down to the PDO to ask what the power
caps are. if the PDO says the device cannot wake from an S state, the call
fails. Idle settings check the caps for wake from S0, Wake settings check
the caps for wake from the targeted Sx state that the OS is going into.
3) failure to allocate a pnp irp and a failure to allocate internal WMI
structures if you allow these functions to be controlled by a user (it is a
flag passed in the caps struct you pass to the DDI). all of these will
return STATUS_INSUFFICIENT_RESOURCES which is probably not what you are
seeing on error.

what it boils down to is if the underlying bus says you can't wake, you
can't wake. KMDF respects what the bus tells us the device can do.

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.


"Harison213" <Harison213@discussions.microsoft.com> wrote in message
news:91A46A32-1202-4E90-AD13-2D59842DC7F0@microsoft.com...

Thanks for the reply Doron.

1. EvtDriverDeviceAdd is indeed what I meant.
2 & 3. What I don't understand is what power caps or system properties the
WDF looks for before failing the call? As far as I can tell, the device
reports that it does support D0-D3 states and also wakes from all of them
including D3cold. It's reasonable if wake from D3cold fails as the parent bus
doesn't support this wake; But I can't see any reason why other wakes and
specially WdfDeviceAssignS0IdleSettings fail!?

--
There are 10 kinds of people in the world: those who understand binary, and
those who don''t!


"Doron Holan [MSFT]" wrote:

Did you check the logdump? Whenever a DDI is failed by framework, it logs
the reason.

http://www.microsoft.com/whdc/driver...DF_IfrLog.mspx

-Eliyas

The target machine is a notebook without any 1394 or a serial interface, so
no kernel debugger can be used

First is you go down the page you see the log is included in a crash dump,
so worst case test for the failure and use KeBugCheck to crash the system .
There are PCMCIA interfaces that will work for the debugger, if you are
using Vista you can also debug with USB.,


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"Harison213" <Harison213@discussions.microsoft.com> wrote in message
news:ADF6DC24-F74F-4184-8DE9-63556AE6EAE5@microsoft.com...

You can get the log in usermode also. If you have the WDF book, refer to
page 437 for instruction on how to get the WPP log.

-Eliyas

"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:%238g9IFO4HHA.1184@TK2MSFTNGP04.phx.gbl...