[BUG] Roland-reported WDF_VIOLATION crash with MIDI 2.0 driver and Roland UM-One

[Psychlist1972]

Applies To MIDI 2.0 USB Driver

Describe the bug Roland reported green screen with UM-One MK2 when set to class-compliant mode.

Crash dumps sent separately in email.

[AmeNote-Michael]

I will be purchasing a UM-One to test with.

[m-komo]

@AmeNote-Michael You can reproduce the issue with the attached firmware on ProtoZOA. UUT_Roland_Eval.zip

[Psychlist1972]

@AmenNote-Michael @m-komo

This may be a random bugcheck, or one related to Insider version. I just plugged in a UM-ONE mk2, set to tablet mode, assigned the attestation-signed driver, and no problem. I am on Windows 11 Insider Preview 26020.1000

[m-komo]

@Psychlist1972 @AmeNote-Michael

The issue seems to be related to the Insider version. I was using Windows 11 Insider Build 26016.1000 and faced the issue. After updating the OS to Insider Build 26020.1000, now it works fine.

I will double check with both OS versions and update you all with a result.

[m-komo]

@Psychlist1972 @AmeNote-Michael

I set up the new Insider Build 26020.1000 and verified. Unfortunately, the issue could be reproduced several times.

The issue occurred when or after the device enters into the suspend state.

I would like to update steps to reproduce as below:

1. Open the Device Manager and show hidden devices.
2. If you can find "UM-ONE" devices under "Sound, video and game controllers", uninstall them.
3. Set the UM-ONE to class-compliant mode and attach it to the PC.
4. Open the Device Manager and double click "UM-ONE" under "Sound, video and game controllers".
5. Make sure the device is running with the in-box USB Audio driver (USBAUDIO.sys).
6. Update driver with the new USB MIDI 2.0 driver (USBMidi2.sys).
7. Wait for a while. Then the device entered into the suspend state.

The issue occurs just after the device enters into the suspend state. If it does not happen in few minutes, please detach the device from the PC and repeat above steps.

I will share crash dumps in separate email.

Thank you.

[Psychlist1972]

@AmeNote-Michael

I wonder if this is related to the other power management event issues you were seeing. Worth discussing with Egidio if you're not already sure of the cause.

https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/pnp-and-power-management-callback-sequences

[Psychlist1972]

Note on my own primary PC, I have USB suspend and related power management turned off, so that may explain why the issue didn't crop up here.

[AmeNote-Michael]

Note on my own primary PC, I have USB suspend and related power management turned off, so that may explain why the issue didn't crop up here.

Pete, excellent point. That is probably why I am not seeing issue in my testing - because of my debugging sessions, I had turned them off - forgot to reenable for this test. Will try soon. Thanks.

[Psychlist1972]

I just approved Michael's PR. This should be fixed in the next attestation-signed driver.

[m-komo]

@Psychlist1972 @AmeNote-Michael The issue persists on DP5 service and driver. I re-installed Windows 11 24H2 (26063.1) and then installed DP5 MIDI 2.0 service and driver.

I will share kernel dump separately. It indicates same issue I faced on DP4.

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: ffffbf88633d7060, Device object pointer.
Arg3: ffffbf88630598a0, Power IRP.
Arg4: ffffbf8865922df0, Reserved.

[Psychlist1972]

Thank you @m-komo

Actually, I see I had packaged the wrong driver version! The file name was correct, but the driver inside was not. It was installing a .2 version instead of the .4 version.

I've updated the release with the corrected version.

Sorry for that.

Pete

[Psychlist1972]

[Psychlist1972]

Tested on my Surface

[AmeNote-Michael]

Thanks @Psychlist1972 (Pete) - little bit of panic when I first read this in AM cause I really was at a lost at what it could have been.

Thanks for looking into this and submitting probable correction even though you are travelling this week. Much appreciated.

[Psychlist1972]

Plugged into my main dev PC. I have a female-female DIN adapter so it is a physical loopback.

[Psychlist1972]

Thanks @Psychlist1972 (Pete) - little bit of panic when I first read this in AM cause I really was at a lost at what it could have been.

Thanks for looking into this and submitting probable correction even though you are travelling this week. Much appreciated.

No worries. My mistake. I head to the airport shortly, so hoping this was my last build artifact problem. Not sure why I picked up the wrong version when building the release. :/

Luckily, when this ships in box, I'm not doing those builds :D

[Psychlist1972]

@AmeNote-Michael note: I did just get the WDF_VIOLATION when I plugged in a second MIDI 1.0 device and opened it for monitoring. The bugcheck happened as soon as I connected to it for input. In this case, it was an iConnectivity mio 1-in, 1-out interface cable. The UM-One was still connected so it's possible it was unrelated to the second device, but that's impossible for me to know here.

It's the same power management event issue. I'm running the correct driver version here.

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: ffffd58e3d054330, Device object pointer.
Arg3: ffffd58e7fea4010, Power IRP.
Arg4: ffffd58e184cedc0, Reserved.

BUGCHECK_CODE:  10d
BUGCHECK_P1: d
BUGCHECK_P2: ffffd58e3d054330
BUGCHECK_P3: ffffd58e7fea4010
BUGCHECK_P4: ffffd58e184cedc0
FILE_IN_CAB:  MIO Open MEMORY.DMP
DUMP_FILE_ATTRIBUTES: 0x1800

I tried !devobj output to see if we can figure out which device, but this is all it reported:

0: kd> !devobj ffffd58e3d054330 f
Device object (ffffd58e3d054330) is for:
 00000543 \Driver\USBMidi2 DriverObject ffffd58e184cfe10
Current Irp 00000000 RefCount 0 Type 0000001d Flags 00002044
SecurityDescriptor ffffaf0d2effa6e0 DevExt ffffd58e2f5dbb30 DevObjExt ffffd58e3d0544a8 
ExtensionFlags (0000000000)  
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffd58e8f76e6a0 \Driver\ksthunk
AttachedTo (Lower) ffffd58e743d22f0 \Driver\usbccgp
Device queue is not busy.

[AmeNote-Michael]

@Psychlist1972 is there a chance you loaded a cached version of old driver instead of new one for the mio?

You know, you would think I would have easy access to a mio - but alas I have it packed away somewhere :)

[Psychlist1972]

@Psychlist1972 is there a chance you loaded a cached version of old driver instead of new one for the mio?

You know, you would think I would have easy access to a mio - but alas I have it packed away somewhere :)

Seems unlikely, but anything is possible. I have not used the mio with the ACX driver on this PC at all, and I haven't had it plugged in here since before I moved to canary builds.

[Psychlist1972]

@AmeNote-Michael just tested again on my Surface

Plugged in mio, assigned driver, and sent/received messages. No problem. I left it open and monitoring. Plugged in UM-One and assigned driver. A few seconds later, I got the WDF_VIOLATION green screen.

It's possible this is something unique to the UM-One, or with having more than one MIDI 1.0 device connected. Unfortunately, I have a couple meetings now and then I head to airport, so I can't test any more this week.

[AmeNote-Michael]

@Psychlist1972 might have more to do with having two MIDI 1.0 devices. Thanks for test, I will try to reproduce. But I am not sure how it is related to Power Policy holder.

[m-komo]

@Psychlist1972 @AmeNote-Michael The issue could be reproduced with the updated driver several times. In all cases, crash dumps indicate the power IRP related error as below:

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: ffff958a786bd810, Device object pointer.
Arg3: ffff958a780528a0, Power IRP.
Arg4: ffff958a74ecbdd0, Reserved.

The issue occurs not only with the Roland UM-ONE (USB MIDI 1.0 device), but also with the ProtoZOA (USB MIDI 2.0 device). So, the condition seems not be limited to "USB MIDI 1.0 device".

And in my case, issue occurred just after assigning the new driver to the device. I'm not sure if it is the requisite condition. But if you cannot reproduce the issue, please follow steps below:

1. Detach the target device and restart Windows.
2. Open the Device Manager and show hidden devices.
3. If you can see the target device under "Sound, video and game controllers", uninstall it with the "Attempt to remove the driver for this device" check-box on.
4. Attach the target device to the PC.
5. Open the Device Manager and double click the target device under "Sound, video and game controllers".
6. Make sure the device is running with the in-box USB Audio driver (USBAUDIO.sys).
7. Update driver with the latest USB MIDI 2.0 driver (USBMidi2.sys).
8. Wait for a while.
9. If the issue does not happen in few minutes, please detach the device from the PC and repeat all the above steps.

[masahirokakishita]

I tried the title issue with my PC as well. Windows 11 Insider Preview 24H2 26063.1 MIDI Services Developer Preview 5 1.0.24066.2126 USBMIDI2_10.0.1.4

The result is the same, which may result in a green screen. I tried it with the UM-ONE and the iConectiviry mio4. In both cases, if I update the standard MIDI 1.0 driver to the MIDI 2.0 driver and wait for about 2 minutes from 30 seconds, I may get a green screen. Enclose the memory dump files. memorydump_um_one.txt memorydump_mio4.txt

[AmeNote-Michael]

Issue related to invalid call during D0Exit routing. Resolved by removing D0Entry and D0Exit from driver as no longer needed in new architecture. Resolved in pull request #301

[Psychlist1972]

Re-opening until we ship to customers.

[AmeNote-Michael]

It was discovered that existing MIDI driver, USBAUDIO.sys, was not properly removing event registrations thus requiring a force unload to use new driver. To do this, when you update driver from USBAUDIO.sys to new USBMIDI2.sys driver, immediately after update unplug the USB MIDI 1.0 device from USB before green screen occurs (up to 30 second window). Then about 10 seconds after plug back in the USB MIDI 1.0 device. Verify through device manager and device details that the new USBMIDI2.sys driver is loaded for the device. It should operate fine from this point on.

You only have to do the unplug and replug when you update to new driver from original class driver. After avoiding the green screen, should be no issue to use device with new driver moving forward, even across multiple reboots and reloads.

[Psychlist1972]

This requires an updated USB MIDI 1.0 Class driver to go out via Windows servicing.