Fix 0xC0262304: Invalid Video Present Source in Windows
This error means Windows can't find a valid display output. The fix is resetting your GPU driver or reconnecting the monitor.
You're in the middle of something, and then this error pops up
It's annoying. 0xC0262304 usually hits when you dock a laptop, switch displays, or wake from sleep. The screen might flicker, go black, or just refuse to extend. I've seen it after a dodgy driver update or when a cheap HDMI cable fails.
The Fix (works 9 out of 10 times)
Don't restart your PC yet. Do this first:
- Press Win + Ctrl + Shift + B. This resets your graphics driver. Your screen will flash and you'll hear a beep. If the error clears, you're done.
- If that doesn't work, unplug the display cable (HDMI, DisplayPort, USB-C) and wait 10 seconds. Plug it back in. Windows rebuilds the video present source chain from scratch.
- Still there? Open Device Manager (Win + X > Device Manager). Find your GPU under "Display adapters". Right-click it, select Disable device. Wait 5 seconds, then right-click again and Enable device. This forces the kernel to reallocate video memory and recreate the source object.
Real-world trigger: I got this error after plugging a 4K monitor into a Surface Book 2 via a third-party USB-C hub. The hub was the problem — it didn't negotiate the video alt mode properly. Step 2 fixed it until I swapped the hub.
Why This Happens
The error code 0xC0262304 maps to STATUS_GRAPHICS_INVALID_VIDEO_PRESENT_SOURCE. The DirectX Graphics Kernel (dxgkrnl.sys) manages something called a "video present source" — basically, a logical path from the GPU to a display output. This source struct includes a pointer to the video memory surface that the GPU is supposed to render to.
What's actually happening is the pointer goes stale. When you dock or undock quickly, or when a driver crashes, the kernel invalidates the source but forgets to reinitialize it. The next time an app (like Explorer or a game) tries to present a frame, the kernel says "nope, that source doesn't exist anymore" and throws 0xC0262304.
The Win + Ctrl + Shift + B shortcut sends a hotkey that the driver intercepts — it calls DxgkDdiResetDevice, which tears down and rebuilds the GPU state, including all present sources. That's why it works. Disabling and re-enabling the device in Device Manager does the same thing but at a lower level — it removes the entire device stack and lets Windows re-enumerate it.
Less Common Variations
Sometimes the fix above doesn't cut it. Here's what else I've seen:
Corrupted monitor driver
Yes, monitors have drivers. Go to Device Manager, expand Monitors, right-click your display, choose Update driver > Browse my computer > Let me pick from a list. Select "Generic PnP Monitor" and install that. This strips out any weird EDID overrides that might confuse the kernel.
GPU driver version conflict
If you've got both an integrated Intel GPU and a discrete NVIDIA/AMD one, Windows sometimes mixes up which driver manages the video present source. I've seen this on laptops where the Intel driver is newer than the NVIDIA one. Use Display Driver Uninstaller (DDU) in safe mode, uninstall both drivers, then install the latest from each manufacturer's site. Don't use Windows Update for this — it often serves old builds.
Faulty EDID or cable
The monitor's EDID tells Windows what resolutions it supports. If the cable is damaged or the EDID is corrupted, the source creation fails silently. You'll see 0xC0262304 when the kernel tries to set a mode. Swap the cable. If you're on DisplayPort, make sure it's a certified cable — cheap ones skip the wiring for pin 20 (the hot-plug detect line) and cause exactly this symptom.
Prevention
Once you've fixed it, keep it from coming back:
- Update your GPU driver from the manufacturer's site, not Windows Update. I check NVIDIA/AMD/Intel once a month.
- Don't unplug display cables while the system is under heavy GPU load (rendering, gaming). The kernel can queue pending presents that fail when the cable is yanked.
- If you use a docking station, test with a direct cable connection to rule out the dock. Some USB-C docks (looking at you, early CalDigit models) don't negotiate video alt mode reliably.
And if you're a developer debugging this in your own app — don't cache the present source handle. Always query IDXGIOutput::FindClosestMatchingMode before presenting, and handle DXGI_ERROR_DEVICE_REMOVED gracefully. The kernel invalidates sources on any device hotplug.
Was this solution helpful?