WDF_VIOLATION due to multiple power policy owners

[mxk]

Running usbdk 1.0.22 on Windows 11 21H2 with libusb 1.0.26. When attempting to open a Bluetooth USB device that is enabled and has OS power management enabled ("Allow the computer to turn off this device to save power" option checked in Device Properties -> Power Management tab), I get a BSOD with WDF_VIOLATION error code. Some googling suggested that this is related to having multiple power policy owners.

If I disable the device in the Device Manager, or if I leave it enabled, but uncheck the "turn off this device" option in the Power Management tab, the BSOD goes away, and I'm able to communicate with the device. Is this something that usbdk could handle automatically?

[YanVugenfirer]

Thank you for reporting. This should be handled automatically.

Do you see the crash on previous Windows versions as well?

[Squall-Leonhart]

This affects Windows 10 as well

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 000000000000000d, A power irp was received for the device but the irp was not
requested by the device (the power policy owner). Possibly there
are multiple power policy owners. Only one driver in the stack can
be the power policy owner. A KMDF driver can change power policy
ownership by calling the DDI WdfDeviceInitSetPowerPolicyOwnership.
Arg2: ffffd48008fb2da0, Device object pointer.
Arg3: ffffd48005871260, Power Irp.
Arg4: ffffd480067f2800, Reserved.

All of this seems to be related to #97

Altering the power plan, does not work, and there is no checkboxes to allow the turn off on this blue tooth radio.

Kernel Dump

[nathankidd]

Using UsbDk 1.0.22 and libusb master (1.0.26+) and a SCR331 smart card reader I reproduce the same WDF_VIOLATION bluescreen on Win10 and Win11. As hinted in #97 I see between 1.0.21 and 1.0.22 there are some power changes. Will try 1.0.21 and see about bisecting.

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this BugCheck.
Arguments:
Arg1: 000000000000000d, A power IRP was received for the device but the IRP was not
requested by the device (the power policy owner). Possibly there
are multiple power policy owners. Only one driver in the stack can
be the power policy owner. A KMDF driver can change power policy
ownership by calling the DDI WdfDeviceInitSetPowerPolicyOwnership.
Arg2: ffffad0a9d975a60, Device object pointer.
Arg3: ffffad0a9abc89a0, Power IRP.
Arg4: ffffad0a851f2540, Reserved.
FAULTING_MODULE: fffff8064b990000 WinUSB

STACK_TEXT:  
ffffab0b`c80b83c8 fffff806`3e628920     : 00000000`0000010d 00000000`0000000d ffffad0a`9d975a60 ffffad0a`9abc89a0 : nt!KeBugCheckEx
ffffab0b`c80b83d0 fffff806`3e5f1842     : ffffad0a`a41ef8b0 00000000`00000016 ffffad0a`898ec530 ffffab0b`c80b8500 : Wdf01000!FxVerifierBugCheckWorker+0x24 [minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp @ 68] 
ffffab0b`c80b8410 fffff806`3e5e10b5     : ffffad0a`a41ef8b0 ffffab0b`c80b84d8 00000000`00000004 00000000`00000000 : Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x10782 [minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 324] 
ffffab0b`c80b8460 fffff806`3e5dcc60     : ffffad0a`a41ef8b0 ffffad0a`898ec530 00000000`00000003 ffff818d`c4dbfa50 : Wdf01000!FxPkgFdo::_DispatchSetPower+0x25 [minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 120] 
ffffab0b`c80b8490 fffff806`3e5da867     : ffffad0a`9abc89a0 ffffad0a`9d975a60 ffffad0a`94487c50 fffff806`3bfb5094 : Wdf01000!FxPkgPnp::Dispatch+0xb0 [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 765] 
ffffab0b`c80b8500 fffff806`3b996d0f     : 00000000`00000300 00000000`00000002 00000000`80000000 ffffad0a`9abc89a0 : Wdf01000!FxDevice::DispatchWithLock+0x157 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1447] 
ffffab0b`c80b8560 fffff806`3b82a72d     : 00000000`80000000 00000000`00000000 00000000`00000300 fffff806`3e5e1068 : nt!IopPoHandleIrp+0x3b
ffffab0b`c80b8590 fffff806`3b998f99     : 00000000`00000001 00000000`00000001 00000000`00000001 fffff806`3b996fce : nt!IofCallDriver+0x6d
ffffab0b`c80b85d0 fffff806`3e5e1012     : ffffad0a`9629c020 ffffad0a`94487c50 00000000`00000014 000052f5`6bb783a8 : nt!IoCallDriver+0x9
ffffab0b`c80b8600 fffff806`3e5e1110     : ffffad0a`9629c020 00000000`00000300 00000000`00000014 ffffab0b`c80b86f8 : Wdf01000!FxPkgFdo::RaiseDevicePower+0x8e [minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 371] 
ffffab0b`c80b8650 fffff806`3e5e10b5     : ffffad0a`9629c020 ffffab0b`c80b8718 00000000`00000004 00000000`00000000 : Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x50 [minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 354] 
ffffab0b`c80b86a0 fffff806`3e5dcc60     : ffffad0a`9629c020 ffffad0a`94487c50 00000000`00000000 ffffad0a`31ec5080 : Wdf01000!FxPkgFdo::_DispatchSetPower+0x25 [minkernel\wdf\framework\shared\irphandlers\pnp\fdopower.cpp @ 120] 
ffffab0b`c80b86d0 fffff806`3e5da867     : ffffad0a`9abc89a0 00000000`00000000 00000000`00000003 fffff806`3bfb5094 : Wdf01000!FxPkgPnp::Dispatch+0xb0 [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 765] 
ffffab0b`c80b8740 fffff806`3b996d0f     : 00000000`00000300 00000000`00000000 00000000`80000000 ffffad0a`9abc89a0 : Wdf01000!FxDevice::DispatchWithLock+0x157 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1447] 
ffffab0b`c80b87a0 fffff806`3b82a72d     : 00000000`80000000 00000000`00000000 00000000`00000300 fffff806`38b7d37b : nt!IopPoHandleIrp+0x3b
ffffab0b`c80b87d0 fffff806`3b998f99     : 9d5fefd6`ae409401 e71e4ae2`02832401 d5fefd6a`e4094f01 71e4ae20`28324eb9 : nt!IofCallDriver+0x6d
ffffab0b`c80b8810 fffff806`38b7d474     : ffffad0a`a9a75816 ffffad0a`99406700 00000000`00000003 55555555`55555555 : nt!IoCallDriver+0x9
ffffab0b`c80b8840 fffff806`38b77e42     : ffffad0a`a9a75820 fffff806`3b813110 ffffe301`b7ac0180 00000000`00000000 : WUDFRd!RdPnpTracker::RdPnpForwardToLowerDevice+0x80 [minkernel\wdf\framework\umdf\redirector\driver\pnp.cpp @ 2049] 
ffffab0b`c80b8890 fffff806`38b77be4     : ffffad0a`873af080 ffffad0a`99406700 00000000`00000000 00000000`00000000 : WUDFRd!RdPnpTracker::RdPnpProcessor+0x3c2 [minkernel\wdf\framework\umdf\redirector\driver\pnp.cpp @ 1147] 
ffffab0b`c80b8930 fffff806`38b77a61     : 00000000`00000000 ffffad0a`99406760 00000000`00000000 fffff806`3c325440 : WUDFRd!RdPnpTracker::RdPnpProcessor+0x164 [minkernel\wdf\framework\umdf\redirector\driver\pnp.cpp @ 1130] 
ffffab0b`c80b89d0 fffff806`3b8996a5     : 00000000`00000000 ffffad0a`a46c6e90 ffffad0a`99406760 fffff806`3e5dc5c0 : WUDFRd!RdPnpTracker::RdPnpCallbackAtPassiveInSystemProcess+0x11 [minkernel\wdf\framework\umdf\redirector\driver\pnp.cpp @ 2166] 
ffffab0b`c80b8a00 fffff806`3b852bc5     : ffffad0a`9aad4040 ffffad0a`9aad4040 fffff806`3b899570 ffffad0a`00000000 : nt!IopProcessWorkItem+0x135
ffffab0b`c80b8a70 fffff806`3b871d85     : ffffad0a`9aad4040 00000000`00000080 ffffad0a`31ec5080 00530020`00270037 : nt!ExpWorkerThread+0x105
ffffab0b`c80b8b10 fffff806`3ba01ed8     : ffffe301`b7ac0180 ffffad0a`9aad4040 fffff806`3b871d30 004e0020`00360031 : nt!PspSystemThreadStartup+0x55
ffffab0b`c80b8b60 00000000`00000000     : ffffab0b`c80b9000 ffffab0b`c80b2000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28

[viktor-prutyanov]

Hi @nathankidd

Could you please elaborate more on how to reproduce the BSoD?

[ybendito]

Seems the same as earlier #97
Caused by 3d2e5a6
The problem happens with some of devices (probably ones that have WDF driver and tend to go to low power mode very fast). Attempt to redirect such device when it is in Dx fails as the device does not get out of Dx.
The commit added a step before redirection for devices in Dx: UsbDk sends Dx->D0 power request for such devices.
Unfortunately for some devices this causes WDF assertion.
I can recommend to try using one of previous releases 1.0.21 or 1.0.19

[nathankidd]

Confirm 1.0.21 avoids the bluescreen.

Reproduced by roughly:

1. libusb attach with specific device ID (04E6:E001)
2. Triggers inside libusb_get_string_descriptor() call but I haven't yet stepped down to the exact final syscall. Will step and give a more detailed log.

Update:
Something environmental seems to have changed and now bluescreen triggers earlier, as soon as UsbDk_StartRedirect() is called:

static int usbdk_open(struct libusb_device_handle *dev_handle)
{
...
   device_priv->redirector_handle = usbdk_helper.StartRedirect(&device_priv->ID);

[nathankidd]

If there's additional testing or info that's useful to add here please let me know. At the moment I'm on a different path to see if I can get away with WinUSB, so paused setting up a physical machine with kernel debugger.

[ybendito]

device_priv->redirector_handle = usbdk_helper.StartRedirect(&device_priv->ID);
@nathankidd Yes, thank you. We know the problem happens exactly this way. At the moment we do not have any device that behaves such a way, this does not happen with most of devices (as their power management is not active or less aggressive).