[BUG]: BSOD AV_ks!DispatchQuerySecurity when apps open Akai MPC Renaissance (Ploytec 2.9.64 driver) MIDI KS filter on 24H2/25H2 — persists with MidiSrv disabled; UseLegacyMidi=1 not honored on 26200.8875

[refractiv-io]

Report pre-requisites

• I have searched this repo for existing issues to confirm this is not a duplicate
• I agree to follow this project's Code of Conduct
• I acknowledge that if I do not respond to follow-up questions in a timely manner, the issue may be closed without any changes or fixes

Clarity and Disclosure

• I confirm that any AI analysis included in this report is clearly called out / tagged as AI-generated with "AI Generated Content". Reports with suspected AI content may be closed if not disclosed.
• I confirm that I will quickly follow-up to questions or requests for additional detail, otherwise the issue may be closed

Windows Version

Windows 11 Enterprise 25H2, 26200.8875 (also reproduced on 26100.8521 / 24H2)

Type of bug

• Windows doesn't recognize MIDI device (doesn't show in device manager)
• Application doesn't recognize MIDI device or ports
• Cannot update firmware on MIDI device (specify device, app, and firmware info)
• MIDI device is recognized, but cannot send or receive messages
• Sent or received MIDI messages are corrupted
• Application not working as expected
• MIDI 1.0 ports not named as expected
• Performance not as expected
• Localization issue (incorrect or missing language for Windows running something other than en-US)
• General application crash or hang
• MIDI Service crash or hang requiring Windows reboot
• Windows bugcheck / BSOD (please include in the areas below the device id from Windows Settings About page or a link to your crash dump uploaded to a sharing service)
• Other or Unsure (please indicate in additional notes section below)

Location

• Application using WinMM MIDI 1.0 (Classic API). Name provided below.
• Application using WinRT MIDI 1.0 (Windows 10 MIDI). Name provided below.
• Application using Windows MIDI Services API (sometimes referred to as MIDI 2.0). Name provided below.
• Other app/DAW/tool. Not sure about which API or SDK it uses. Name provided below.
• Windows MIDI Services tools like MIDI Settings, Console, etc.
• Directly in Windows MIDI Services SDK (for Developers only, please provide repro code)
• General Windows shell (Device Manager, Settings, Services, etc.). Name provided below.
• Windows MIDI 2.0 Class Driver (usbmidi2-acx.sys)
• Windows MIDI 1.0 Class Driver (usbaudio.sys)
• Vendor-provided MIDI driver (please provide details below)
• Other or Unsure (please indicate in additional notes section below)

Application Name and Version

Akai MPC 2.15.1.1 (trial) AND Akai MPC 1.9.6.1 — identical crash from both

MIDI Device

Akai Professional MPC Renaissance (dual USB enumeration: VID_09E8&PID_207F + VID_09E8&PID_007F)

Vendor Driver

Akai/Ploytec (usb-audio.de) MPC Renaissance stack v2.9.64.0, dated 2014-05-23 — akaiacv0u/a/m.inf; services AKAI_ACV0_USB / AKAI_ACV0_WDM / AKAI_ACV0_MIDI

Output from the MIDI Diagnostics Tool

mididiag/SDK tools are deliberately NOT installed on this machine yet — it BSODs on MIDI filter open, so we are minimizing device-open operations. Output from midicheckservice (your enablement-checker release) instead:

Looking for wdmaud2.drv in registry

• Successfully verified wdmaud2.drv is present in registry, as required by the new MIDI stack.

Testing MIDI Service Activation

• Successfully tested connectivity to service: MIDI Service is available and running from System32.

Happy to run mididiag on request (supervised, expecting a possible BSOD).

Repro

• I confirm that I was able to reproduce this issue using a simple app like midi.exe, midi1monitor.exe or Pocket MIDI
• I tried but was unable to reproduce this issue using a simple application

Your personal observation that led to the bug report

I own an MPC Renaissance, registered to my inMusic account. On this Windows 11 25H2 PC, launching Akai's MPC software blue-screens the whole machine instantly — nine times in one day of testing. It happens with the old MPC 1.9.6.1 and with the current MPC 2.15.1.1 trial I installed to check whether the newer software would help. It did not — same crash.

What I can see as a user: the device itself enumerates fine (all nodes OK in Device Manager), Windows builds its audio endpoints without complaint, and if I disable the Renaissance's MIDI device node in Device Manager, MPC 2 runs perfectly with the Renaissance as an ASIO audio interface (4-in/4-out, 48 kHz) — but the pads/controller are dead in that state, which defeats the point of the instrument. The moment the MIDI side is enabled and MPC opens the device: BSOD.

I also tried the documented UseLegacyMidi rollback from your KB article — the value is set exactly as documented and has had no observable effect on this machine (details in the notes below).

Steps to reproduce

1. Windows 11 25H2 (26200.8875) with Windows MIDI Services active (verified via midicheckservice).
2. Install the Akai MPC Renaissance driver stack v2.9.64.0 (2014, Ploytec) — the only driver Akai provides for this hardware.
3. Connect the MPC Renaissance via USB. All device nodes show OK; MidiSrv aggregates it into KSA endpoints (two parallel sets — see notes).
4. Launch MPC software (1.9.6.1 or 2.15.1.1), or select the Renaissance ASIO device in MPC 2 preferences while the MIDI node is enabled.
5. Immediate SYSTEM_SERVICE_EXCEPTION (0x3B) — bucket AV_ks!DispatchQuerySecurity. 9/9 attempts on 2026-08-04.

Variations tested — crash IDENTICAL in every one: MidiSrv Running / Stopped / service-Disabled (no KSA endpoints present at all); HVCI + Credential Guard ON and OFF (verified via Win32_DeviceGuard in both states); MPC 1.9.6.1 and 2.15.1.1; builds 26100.8521 and 26200.8875.

Configuration with NO crash: Renaissance MIDI device node disabled in Device Manager — audio-only ASIO operation is then stable indefinitely.

Additional notes

Crash signature (cdb !analyze -v, MS public symbols; 4 of 9 dumps deep-analyzed, all identical bucket):

• BUGCHECK 0x3B (SYSTEM_SERVICE_EXCEPTION), P1 c0000005, PROCESS_NAME MPC.exe
• FAILURE_BUCKET_ID: AV_ks!DispatchQuerySecurity; ks.sys 10.0.26100.8737
• Two related fingerprints, same code sequence: usually ks!DispatchQuerySecurity+0x2d 'mov rax,[rcx+28h]' with rcx=0; in one dump +0x2a 'mov rcx,[rax]' with rax=0x7000610000010088 (UTF-16-like bytes in a pointer slot). I.e., the driver-side security context is uninitialized memory, not reliably null.
• Stack: nt!NtCreateFile -> nt!IopCreateFile -> nt!ObOpenObjectByNameEx -> nt!ObpCreateHandle -> nt!ObpAllocateAndQuerySecurityDescriptorInfo -> nt!IopGetSetSecurityObject -> ksthunk!CKernelFilterDevice::DispatchIrp -> ks!DispatchQuerySecurity

We understand the driver is inMusic/Ploytec's to fix (vendor report filed with them separately, and your API-mode KB article already names the "inMusic driver bug" class). Filing here because (a) ks.sys bugchecking on a null/garbage security context during a handle-creation security query might be hardenable OS-side (fail the open instead of bugcheck), and (b) the questions below.

Questions:

1. How can a user verify whether the KB5095093 rollback capability (June 2026 Week D 30-day CFR) has been granted on a specific machine?
2. Is UseLegacyMidi expected to be honored on 25H2 26200.8875 as of Aug 2026? Here it is set exactly per your KB (DWORD=1 in Drivers32) with no observable effect across 11+ reboots — KSA aggregation still forms, midicheckservice reports the service active.
3. Is Mode 1 expected to stop midisrv-side KSA aggregation of legacy-driver devices, or only switch the app-facing API routing?

Other observations:

• ViVeTool /disable /id:58988972 reports success but the override never appears in FeatureManagement\Overrides (checked same-second, all priorities) — silently discarded; the feature is Enabled at ImageOverride(15) on this build.
• MidisrvTransferComplete=0 reverts to 1 on every boot.
• The dual-PID enumeration produces two parallel KSA endpoint sets (..._0_x and ..._1_x) for one physical device — likely related to the duplicate-device issues already on your known-issues list for inMusic hardware.
• Repro with simple apps (midi1monitor, Pocket MIDI) deliberately not attempted yet — each repro is a full BSOD on this machine; happy to run supervised if it helps triage.
• Device ID (Settings > System > About): {C934AF88-2E3F-4BA9-9E42-92E803303BB5} — 9 bugchecks on 2026-08-04 (~12:30-22:38 JST) should be visible in telemetry. 7 minidumps + cdb analysis logs available on request.

Disclosure: this report was prepared with AI assistance (Claude, driving cdb/WinDbg and PowerShell on the affected machine); all quoted output is verbatim tool output, human-reviewed. The personal-observation section is the owner's own account.

[Psychlist1972]

Sorry you're running into these issues.

Disabling the February updates through ViveTool isn't going to help you here. The 2D updates went out of CFR in June (4 months after release) so the id no longer does what you would think it does -- it's physically removed from the code. Claude should know this by now, but inMusic put out like 10 support articles for their various brands all saying to uninstall that KB.

As stated in the article on changing the API mode:

You must be fully up to date with a healthy Windows 11 system to use this feature. If you have uninstalled any updates or used Vive tool or similar, please repair your PC using Windows Settings > System > Recovery > “Fix problems using Windows Update”.

Please do the above and then reboot. At that point, if your PC is not domain-joined (domain policies prevent CFR activation, even with ViveTool) then you will have the feature enabled.

It's also possible that if there's some other issue at play here, that will also address it. But it's a long shot for that given this is a kernel driver bug

Questions from your report

How can a user verify whether the KB5095093 rollback capability (June 2026 Week D 30-day CFR) has been granted on a specific machine?

You can only tell by using MIDI and verifying that midisrv (Windows MIDI Service in the services console, or MidiSrv.exe in Task Manager's details page) is not running. There are no built-in ways in Windows to validate any CFR activation/enablement.

Is UseLegacyMidi expected to be honored on 25H2 26200.8875 as of Aug 2026? Here it is set exactly per your KB (DWORD=1 in Drivers32) with no observable effect across 11+ reboots — KSA aggregation still forms, midicheckservice reports the service active.

If the June 2026 D-week KB was installed and no updates were uninstalled, and no vivetool enable/disable actions were taken, then yes, you should have it activated as of a week ago, if not earlier, with the caveat about domain-joined PCs. (as above, domain-joined PCs have a default policy which prevents CFR activation.) Those who did not install the KB earlier will get the feature installed and auto-enabled in mid-August, in around 10 days from now.

Is Mode 1 expected to stop midisrv-side KSA aggregation of legacy-driver devices, or only switch the app-facing API routing?

Mode 1 prevents the service from starting up at all. It also prevents the use of the usbmidi2-acx driver. The new MIDI stack completely steps aside and only the old code paths are in use.

The actual problem

Note that the inMusic driver bug I've mentioned is not what was described in this report. This is the first I'm hearing of a bugchk when using an MPC. The inMusic driver bug is that the driver hangs when you try to disconnect, but doesn't bluescreen. There may be something else going on with this PC.

I cannot look up by device id. Failure Hash from the crash dump lets me find the set of them, so that's the best identifier to share if you have it. Nevertheless, there was enough info in here for me to find the failures, because there are almost none of them other than your PC's.

In the past 60 days, I see only two different PCs with the issue. One is on Windows 10, but I cannot tell the driver or app. Once is Windows 11 with MPC.exe, which I assume is yours. The Windows code where this fails hasn't changed in 4+ years, and I know we have a lot more MPC users than that, and I'm sure quite a few on the older MPCs.

Copilot analysis confirms the problem is likely within the Akai driver, but perhaps it's a rare code path or something. If you talk to them, it's a problem with object lifetimes, which is not far from the other issue the driver has. We're getting an invalid context at the Kernel Streaming level, which is below non-ASIO audio and both old and new MIDI stacks in Windows.

I own an MPC Renaissance, registered to my inMusic account. On this Windows 11 25H2 PC, launching Akai's MPC software blue-screens the whole machine instantly — nine times in one day of testing. It happens with the old MPC 1.9.6.1 and with the current MPC 2.15.1.1 trial I installed to check whether the newer software would help. It did not — same crash.

Is this a new PC?

In any case, start with the repair. Assuming that doesn't fix it for you, try the legacy mode after that.

I wouldn't expect inMusic to update the old driver. Perhaps the MIDI portion can be reassigned to an in-box driver (usbaudio.sys for MIDI 1 and the most backwards compatibility, usbmidi2-acx for MIDI 1.0 and MIDI 2.0) instead? If it shows up as a separate device in device manager, which it sounds like it does from what you said.

Instructions for changing drivers are on the Discord server https://aka.ms/mididiscord in the #workarounds-and-instructions channel. I haven't had time yet to make a web article out of my instructions for that.

Pete
Microsoft

[Psychlist1972]

refractiv-io

Did you have any additional info? Did you try the suggestions I made?

FWIW, I upgraded my Insider Canary version last night, and have since had 3 of that bugchk today. BUGCHECK 0x3B (SYSTEM_SERVICE_EXCEPTION)

In my case, no MIDI or audio anywhere in the stack, and the faulting apps were Edge twice, and then VS Code. As Claude said, those were just the victims because of the amount of work they were doing.

The recommendation for me was to try disabling memory integrity as the issue seemed possibly related to VBS. So I've done that (in the Windows Security app) and restarted. I'll see if that stops the crashes. TBD.

Likely unrelated to your issue, but I haven't had any green screens on this PC in well over a year, and then I got 3 within 24 hours of the latest experimental/Canary release.

If you have no further information, I will need to close this bug.

Pete
Microsoft

[Psychlist1972]

Abandoned by customer