Title: Windows 11 25H2 blocks Korg USB audio driver — documented CiTool workaround fails with 0x80070005

Mason 0 Reputation points
2026-11-05T10:00:32.79+00:00

I'm experiencing an issue with Microsoft's new Windows Driver Policy that has rendered my previously functioning Korg USB DAC/headphone amplifier unusable.

System details:

  • Windows 11 25H2, OS Build 26200.9711

July 2026 cumulative update and subsequent updates installed

Device: Korg DS-DAC USB audio device

Hardware ID: USB\VID_0944&PID_0207

Driver: \Driver\KORGUA

The problem

Following Windows updates, Windows displayed a notification stating that the Korg driver was being blocked because it no longer meets the newer security requirements.

Event Viewer records the following:

The driver \Driver\KORGUA failed to load.
Device: USB\VID_0944&PID_0207
Status: 0xC000026C

The device worked before the security policy change. Korg has not provided a newer compatible driver for this older hardware.

The documented workaround also fails

Microsoft's official documentation states that systems with the July 2026 update or later can disable the relevant policy using:

CiTool.exe --remove-policy "{8F9CB695-5D48-48D6-A329-7202B44607E3}"

However, this returns:

An error occurred: 0x80070005

The error persists after restarting.

The output of CiTool.exe --list-policies confirms that the target policy exists:

Friendly Name: Microsoft Windows Cross
Certificates for Code Integrity Exceptions Policy
Policy ID: 8f9cb695-5d48-48d6-a329-7202b44607e3
Platform Policy: true
Policy is Signed: true
Has File on Disk: true
Is Currently Enforced: true
Is Authorized: true

I understand the security rationale for restricting legacy kernel drivers. However, this change has effectively disabled otherwise functional audio hardware, and Microsoft's documented method for restoring compatibility doesn't work.

My questions are:

Why does CiTool return 0x80070005 when removing this policy on a fully updated Windows 11 25H2 installation?

Is this a known issue with Microsoft-signed platform policies?

Is there an officially supported alternative that doesn't require modifying EFI boot files or disabling Secure Boot?

Is Microsoft considering a more targeted exception mechanism for legacy hardware that no longer receives updated drivers?

I would appreciate guidance on restoring this device without unnecessarily compromising Windows security or replacing functional hardware.

Windows for home | Windows 11 | Devices and drivers
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Vasileios Dionysopoulos 646 Reputation points
    2026-11-05T10:03:20.7366667+00:00

    0x80070005 is E_ACCESSDENIED. There are two likely causes, and one option that avoids touching the policy at all.

    1. CiTool isn't running elevated

    --remove-policy requires an elevated session. A normal Terminal returns exactly this error, even if your account is an administrator. Right-click Start → Terminal (Admin), confirm the title bar shows Administrator, and run:

    CiTool.exe --remove-policy "{8F9CB695-5D48-48D6-A329-7202B44607E3}"

    Then restart. The policy keeps protecting the current session and is only removed after the reboot.

    2. The enforced copy is the boot-protected version

    Microsoft's page distinguishes two cases. With the July 2026 update or later, CiTool can remove the policy. Without it, "the enforced policy has extra startup protection" and the only path is the Secure Boot procedure. If your device entered enforcement mode before the July update was installed, the active .cip may still be the protected version. In that case access denied is expected even from an elevated prompt. I can't confirm this from outside, but it fits what you describe (elevated, rebooted, policy signed and authorized).

    If that's the case, the documented fallback is temporary: disable Secure Boot, delete the .cip from the EFI partition and from System32\CodeIntegrity\CiPolicies\Active, reboot, then turn Secure Boot back on. The exact steps are in the reference below. It doesn't leave Secure Boot off permanently, but it does modify the EFI partition, so it's a last resort.

    3. Try the Windows built-in USB Audio 2.0 driver first (no policy change)

    Many USB DACs that ship with a vendor driver are also USB Audio Class 2.0 compliant. Windows has included a class driver (usbaudio2.sys) since Windows 10 1703. If the DS-DAC is class compliant, removing the KORG driver lets Windows bind its own WHCP-signed driver:

    1. Device Manager → find the Korg device → Uninstall device → tick Attempt to remove the driver for this device.
    2. Also uninstall the KORG driver package from Settings > Apps if it's listed.
    3. Unplug the DAC, restart, plug it back in.
    4. Check Device Manager → device → Properties → Driver Details. If you see usbaudio2.sys, it's using the Windows driver.

    You may lose vendor-specific features (native DSD playback, the AudioGate integration), but PCM playback usually works. That keeps the driver policy enforced.

    Before any of this

    • Check Korg's support site for a newer KORG USB Audio Device Driver. If a WHCP-signed version exists, it will load under the policy.
    • Confirm the block in Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Event 3077 = blocked. The event details show the signer of KORGUA and confirm it's this policy and not something else.

    On your last two questions: I don't know of a known-issue listing for this error. Feedback about a targeted per-driver exception mechanism is best sent through Feedback Hub, where the Windows team tracks it. Include the hardware ID and the 3077 event.

    Reference: The Windows driver policy – Microsoft Support · CiTool technical reference

    Was this answer helpful?

  2. TaoLi 119.5K Reputation points Independent Advisor
    2026-11-05T13:19:39.4266667+00:00

    Hi, your command matches Microsoft’s instructions. 0x80070005 means Access denied, but it doesn’t tell us why removal failed.

    Please confirm you ran it through Start >> Terminal (Admin), then share:

    • Your full build number from Win + R >> winver.
    • The Korg-related Event 3077 from Event Viewer >> Applications and Services Logs >> Microsoft >> Windows >> CodeIntegrity >> Operational, including its Policy ID.

    Microsoft currently provides no individual-driver exception, and I haven’t found another documented workaround meeting your Secure Boot/EFI requirements.

    Please share those details, and I’ll help narrow this down.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.