[BSOD / VK_ERROR_DEVICE_LOST] Vulkan Exclusive Fullscreen swapchain transition crashes Windows 10 display stack (DX11 works)

Question

Hi Microsoft Community & Developer Support,

I am developing a custom graphics engine targeting low-end integrated graphics (iGPU) hardware. Following a clean installation of Windows 10 Pro, I am encountering a severe, system-crashing issue (BSOD / TDR) specifically during Vulkan API Fullscreen swapchain transitions.

🔹 Crucial Observation (Vulkan vs DX11):

• DirectX 11 runs stably and handles Exclusive Fullscreen transitions without any crashes.
• Vulkan API CRASHES THE ENTIRE SYSTEM (BSOD) or forces a kernel-level driver reset (VK_ERROR_DEVICE_LOST) specifically during Fullscreen swapchain initialization or transition.

🔹 Key Symptoms & Behaviors:

1. Vulkan Fullscreen BSOD: Transitioning the Vulkan swapchain to Exclusive Fullscreen (or starting in Fullscreen) instantly crashes the executable or triggers a system Blue Screen of Death (Kernel mode display driver crash).
2. Presentation Pacing Failure: In windowed mode, presentation pacing breaks completely (ignores VK_PRESENT_MODE_FIFO_KHR), resulting in uncontrolled frame rates and GPU TDR timeouts during vkQueueSubmit.
3. Pre-Reinstall Binary Test: Testing an exact pre-reinstall compiled binary (which previously ran flawlessly on this same OS/hardware configuration) reproduces the EXACT same Vulkan BSOD post-reinstallation.

🔹 Technical Environment & Log:

• OS: Windows 10 Pro (Clean Install, fully updated)
• Graphics APIs: Vulkan (VK_KHR_swapchain, VkSurfaceKHR) vs DirectX 11
• Engine Error Log: [ERROR] VulkanRenderer::EndFrame - vkQueueSubmit failed! VkResult = VK_ERROR_DEVICE_LOST (-4) [ERROR] EngineApp Run Error: ERROR: Command Buffer could not be submitted to GPU! VkResult = VK_ERROR_DEVICE_LOST

Since the engine codebase remains unchanged and DirectX 11 operates normally, we are trying to isolate whether this stems from Windows 10 DWM (Desktop Window Manager) / WDDM presentation queue interactions or a graphics driver conflict.

🔹 Questions for Windows Display & DWM Team:

1. Are there known DWM / Fullscreen Optimization changes or WDDM presentation regressions in recent Windows 10 updates that disrupt Vulkan surface presentation queues on iGPU architectures?
2. How can we verify if Windows DWM / DirectFlip is forcibly overriding the application's Vulkan swapchain presentation state?
3. What event logs or Minidumps (e.g., MEMORY.DMP) can we provide to analyze the kernel-level display stack crash?

Thank you for your assistance!

Answer 1

Hello @ABSLT_DVL ,

Thank you for providing such a detailed explanation of the VK_ERROR_DEVICE_LOST and BSOD situation.

To answer your questions and help determine the root cause, below are my thoughts and suggested next steps:

1. DWM / WDDM Changes & Fullscreen Optimizations:

It is possible that recent Windows 10 cumulative updates or the WDDM drivers pulled during the clean install are interacting differently with your iGPU's Vulkan presentation queues. As an initial isolation step, it might be beneficial to right-click your compiled executable, select Properties > Compatibility, and check "Disable fullscreen optimizations". This can help indicate if the DWM's dynamic presentation model is a contributing factor to the crash.

2. Verifying DWM / DirectFlip Status:

To observe if DWM is overriding your Vulkan swapchain state, I would suggest analyzing the frame presentation using a tool like PresentMon. It can log the exact presentation mode (e.g., Hardware Composed Independent Flip vs. BitBlt) being negotiated in real-time right up until the vkQueueSubmit fails.

3. Event Logs and Minidumps:

You asked about which logs to provide. Because this is a public community forum and dump files can contain personal or system-identifying information (PII), I suggest that you do not upload or share these files here. Instead, it might be beneficial to analyze the crash dumps (Minidump or C:\Windows\MEMORY.DMP) locally using a debugging tool like WinDbg. This can help pinpoint which kernel module or WDDM component in the display stack is faulting. Additionally, in Event Viewer, you can filter the System logs for "BugCheck" (Event ID 1001) or "Display" (Event ID 4101) to trace the moment the driver resets.

As a final thought, because this behavior started right after a clean installation, it suggests that Windows Update might have installed a generic display driver that differs slightly from the one you had on your previous setup. It might be helpful to manually download and perform a clean installation of the latest graphics driver directly from your iGPU manufacturer (Intel or AMD) to see if that resolves the presentation pacing failure and crashes.

I hope this information points you in the right direction. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Answer 2

Thank you for posting your question. We're working with the appropriate team to look into this further and will respond as soon as we have an update.