Fix ERROR_GRAPHICS_UNASSIGNED_MODESET_ALREADY_EXISTS (0xC0262350)

You're staring at a blue screen with ERROR_GRAPHICS_UNASSIGNED_MODESET_ALREADY_EXISTS and the hex code 0xC0262350. This isn't a disk failure or a dead RAM stick. It's the Windows display stack (dxgkrnl.sys and the vendor miniport) throwing a fit because a VidPN source or target tried to register more than one unassigned mode set at the same time. The rule inside the kernel is one unassigned mode set per source/target — and something just broke it.

The trigger I see most in the field: a GPU driver update that half-installed. You reboot, Windows loads the new miniport plus a leftover piece of the old one, and the VidPN manager gets two claims on the same source. Boom. Bugcheck 0x119 family, subcode 0xC0262350.

Let's walk it in order of likelihood. Don't skip ahead.

Cause 1: Corrupted or mismatched GPU driver (most common)

This is the culprit about 7 out of 10 times. Windows Update pushes a driver, the vendor utility (GeForce Experience, Adrenalin, Intel DSA) pushes a different one, and you end up with mixed binaries in System32\DriverStore\FileRepository. The VidPN code chokes on the version mismatch during mode enumeration — usually right at boot or the moment you plug in a second monitor.

Real scenario: a Dell OptiPlex 7090 with Intel UHD 630 and an added NVIDIA T400. Windows Update installs a new Intel iGPU driver over the top of the OEM one, and every cold boot dumps 0xC0262350. That's textbook.

The real fix is a clean wipe of the driver stack. Not a rollback. Not "update driver" from Device Manager. Use DDU.

1. Grab Display Driver Uninstaller (DDU) from Wagnardsoft. Current build is fine.
2. Boot into Safe Mode. Yes, actually do it — DDU works better when dxgkrnl isn't holding file locks.
3. Run DDU, select your GPU vendor, and pick Clean and restart.
4. After reboot, install the driver from the vendor's site, not Windows Update. For NVIDIA, use the Studio branch if you're not gaming. For AMD, grab the WHQL Adrenalin, not the optional.

If you're on a laptop with switchable graphics, install the Intel/AMD iGPU driver first, reboot, then the discrete GPU driver. Order matters. Windows gets confused when the dGPU miniport loads before the iGPU.

Cause 2: Faulty or loose display cable / port negotiation

Yeah, I know. "Check the cable" sounds like tier-1 script reading. But 0xC0262350 is a display link error at its heart, and a marginal DP or HDMI link can absolutely trigger it. When the link retrains mid-session and the EDID handshake fails, the VidPN source keeps an unassigned mode set from the previous negotiation and the new one collides.

Typical hardware: cheap DisplayPort-to-HDMI adapters, USB-C docks, KVM switches. I've seen a StarTech USB-C dock cause this on a Surface Laptop 4 every time the user undocked.

Try this:

• Swapped the cable for a known-good one. Not a different cable — a known-good one you've tested elsewhere.
• Bypass the dock or KVM entirely. Plug straight into the GPU.
• Use DP over HDMI if both are available. DP handles link retraining better.
• If you're on a multi-monitor setup, drop to a single monitor and see if the bugcheck stops. If it does, you've narrowed it to one port or one cable.

Don't bother reseating the same cable five times. If it's loose, you'll feel it. If it isn't, reseating won't help.

Cause 3: Aggressive TDR settings or a bad Windows build

Timeout Detection and Recovery (TDR) is the watchdog that resets the GPU when it stops responding. Default is 2 seconds. If someone (or a "gaming optimizer" tool) cranked TdrDelay way up or set TdrLevel to 0, the VidPN manager can end up holding a stale unassigned mode set past the point where it should've been released. Result: 0xC0262350.

Also worth checking: you're on a Windows build with a known dxgkrnl regression. Builds 19041.2xxx and 22621.2xxx have both shipped with graphics stack bugs that got fixed a couple of cumulative updates later.

Reset TDR to defaults. Open an elevated Command Prompt and run:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrLevel /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDdiDelay /f

Reboot. Windows recreates the values with defaults on next boot. Then patch fully — wuauclt /updatenow or just hit Check for updates until it stops offering anything.

If you're on an Insider build, get off it. This error shows up on Dev channel far more than retail.

What to grab from the crash dump

Before you nuke anything, pull the minidump from C:\Windows\Minidump. Open it in WinDbg and run:

!analyze -v
lmvm dxgkrnl
lmvm nvlddmkm

Look at the faulting module. If it's the vendor miniport (nvlddmkm.sys, amdkmdag.sys, igdkmd64.sys), you're back to Cause 1. If it's dxgkrnl itself, look hard at your Windows build number — Cause 3.

Quick reference

One more thing: if you're seeing this on a VM with GPU passthrough, stop. The virtualized VidPN layer doesn't handle this bugcheck gracefully. Drop to a basic display adapter inside the guest and do your graphics work on the host.