I wonder what UMDF is unhappy about in a certain Win8.1 9600 power mgmt scenario. I’m talking about a mature UMDF driver suspending and resuming fine when installed on a variety of busses. The new third-party bus driver is causing the following trouble however:
**** WUDF DriverStop - Driver error 0x50100040000010d
**** in Host
**** drivers\wdf\umdf\driverhost\framework\v1\fxtosharedinterface\fxverifier\ufxverifier.cpp:22(Mx::MxBugCheckEx):
WDF Violation: Please check tracelog for description of error., Context Record: .cxr 0x0093F408
The offending stack extract:
0093f704 67b4ef58 WUDFx!FxVerifierBugCheck+0xf
0093f720 67b0d65a WUDFx!FxPkgFdo::DispatchDeviceSetPower+0x65
0093f72c 67b0981d WUDFx!FxPkgFdo::_DispatchSetPower+0x25
0093f74c 67b096e8 WUDFx!FxPkgPnp::Dispatch+0x11d
0093f758 008583ef WUDFx!CWdfDevice::DispatchPnP+0x32
The relevant WudfTrace entries:
16:27:10.168 [WUDFRd]RdPnpTracker::RdPnp: RdFdoDevice 0x85739330 !devobj 0x85664020 IRP_MJ_POWER 0x00000002(IRP_MN_SET_POWER) IRP 0x86544C08 received
16:27:10.168 [WUDFRd]RdPnpTracker::RdPnpProcessor: forward irp to host on its way DOWN
16:27:10.168 [WUDFRd]RdPnpTracker::RdPnp: RdFdoDevice 0x85739330 !devobj 0x85664020 IRP_MJ_POWER 0x00000002(IRP_MN_SET_POWER) IRP 0x86544C08 returning 0x00000103(STATUS_PENDING)
16:27:10.168 [lpc]lpcport got a message!
16:27:10.168 [lpc]lpc handle 0x009E2BD0 received msg
16:27:10.168 [WUDFHost]CLpcNotification::Message: Host process receives message: 0x1
16:27:10.168 [WUDFHost]CLpcNotification::ProcessPnpPowerIrp: Received IRP (major/minor) = (0x16/0x2)
16:27:10.168 [WUDFPlatform]WUDF DriverStop Driver error 0x50100040000010d component Host @ drivers\wdf\umdf\driverhost\framework\v1\fxtosharedinterface\fxverifier\ufxverifier.cpp:22(Mx::MxBugCheckEx):WDF Violation: Please check tracelog for description of error. Context Record: 0x007BF418
The UMDF crash is followed by the platform crash if I don’t let WUDFHOST process die keeping it in the WinDbg. That’s understandable as I block the IRP_MN_SET_POWER. Kernel dump indicates that this is device power request to go into D0. Now, the device is in D0 already so it’s not clear how come the bus driver sends it into D0 again. However, it’s not illegal to do so, right? Is that possibly the UMDF failure root cause? Any other ideas? I wish WudfTrace would have listed the real cause.
Many thanks for all the input,
Ilya Faenson
Rockville MD USA