VK_ERROR_DEVICE_LOST in Vulkan: real causes, diagnostics, and fixes

If you have encountered the message VK_ERROR_DEVICE_LOST While playing games or designing applications with Vulkan, you're not alone: ​​it's a common issue that can manifest itself as crashes, unexpected shutdowns, or even loops where the program won't fully close. Although it's frightening, it usually has an explanation and, most importantly, ways to mitigate or resolve it.

In this guide you will find Real-life cases on Windows and Linux, with games and tools, clues to diagnose the source, settings that have helped other users (such as a specific setting in the NVIDIA Control Panel for Detroit: Become Human with an RTX 3080), and Reliable resources to better understand VulkanThe idea is that you don't waste time jumping from forum to forum and have, at a glance, the solutions that really have possibilities. Let's learn everything about the error VK_ERROR_DEVICE_LOST. 

What does VK_ERROR_DEVICE_LOST mean and why does it appear?

In Vulkan, the VK_ERROR_DEVICE_LOST error indicates that the logical device has ceased to be operational: the GPU driver has restarted it, there was a driver hang, a TDR occurred due to a blocking or queue timeout, or the application sent something that the hardware/driver couldn't handle. It doesn't always end in a crash; sometimes, as we'll see, the application gets stuck in a loop and has to be closed by force.

Although the pattern varies depending on the equipment and software, the usual triggers are Unstable drivers, very new extensions, layers/overlays, system time limits and sometimes, just unfortunate combinations of graphics settings. Knowing some real-life cases helps reproduce and address the problem.

Real cases: what happened and what was done

Detroit: Become Human on Windows, RTX 3080, and a decisive adjustment at NVIDIA

A user with a GeForce RTX 3080 was constantly experiencing game crashes with VK_ERROR_DEVICE_LOST despite doing the typical: Update drivers, test compatibility mode, and review optionsThe solution that worked for me was to go to the NVIDIA Control Panel and change a specific preference related to Vulkan/OpenGL at the program level.

The route, formulated in another way, was: NVIDIA Control Panel > Manage 3D Settings > Program Settings > select Detroit: Become Human. In the Vulkan/OpenGL preset method option, the setting that made the difference was setting it to "Prefer by layers in DXGI Swapchain«. With that change, repeated closures disappeared associated with VK_ERROR_DEVICE_LOST.

This example illustrates that sometimes, a compatibility adjustment or how the swapchain is managed with layers it can be the key, especially when the title has a particular render pipeline or when there is interaction with other layers in the system.

Dota 2 on Linux: Looping and Seemingly Random Instability

Another significant case is that of Dota 2 running natively on LinuxThe reported pattern was puzzling: the VK_ERROR_DEVICE_LOST error would pop up both during real-time matches and when watching replays, sometimes simply by watching a fight or even typing in the chat. Instead of closing completely, the game stayed in a Infinite loop and had to be “killed” manually.

In that specific experience no contributions were made No Match ID or screenshots ("No response" was indicated in both fields), which makes it difficult to correlate exact moments. Even so, the symptom (freezing without a complete crash) points to an unrecoverable device state from the application perspective. In Linux, this pattern can be related to the driver, presentation queue and timing management, or some composer/graphical environment interaction.

In such scenarios it is advisable to review system logs (dmesg, journalctl), check Mesa/NVIDIA versions depending on the GPU, and disable third-party layers. These are tips that, while generic, become relevant in a render-intensive Vulkan title like Dota 2.

Unstable screenshots with RenderDoc and VK_EXT_shader_object

The use of plotting tools adds its own set of variables. It has been observed Instabilities with RenderDoc when capturing applications that use the extension VK_EXT_shader_objectIncluding Recovered driver crashes, application freezes, and lost device errors. It's not surprising: we're talking about a recent extension and an inherently delicate situation (grafting a capture layer into an advanced pipeline).

To reproduce the problem consistently, the example "shaderobjects» from the repository of Sascha Willems/VulkanThe procedure was: Run the shaderobjects.exe binary under RenderDoc, capture a frame and select the second vkQueueSubmit() event. At that moment, the error report dialog appeared of the tool.

In addition, to reduce confounding factors, the following were removed before capture: .bin files that the example generates (shader caches), and the error still occurred. The specific environment was: RenderDoc_2024_07_02_0406d376_64, Windows 10 (10.0.19045.4529), Vulkan 1.3.275, GeForce GTX 1080 y driver 566.12This data is very useful if you're reporting or comparing similar issues.

Game and Steam crashes, and even blue screens

A particularly annoying scenario was also reported: The game would crash frequently, sometimes Steam too, and even a BSOD would appear. (blue screen). Basic actions such as Update drivers, adjust graphics quality, force full screen mode, disable overlays y limit FPS to 60, but the closures continued every few minutes of the game.

When blue screens are involved in the equation, the suspicion of instability at the kernel/driver level or in the hardware itself. Although VK_ERROR_DEVICE_LOST is a Vulkan bug, if the entire system is wobbly, it is advisable to supplement with memory tests, disk check, and thermal monitoring to rule out that the GPU or its power supply is at its limit.

Possible causes: technical and everyday

Although each case is unique, there are a number of common causes that are worth considering. Here's a map to help you navigate. The most common in VK_ERROR_DEVICE_LOST:

• Unstable or regressed graphics drivers: Recent versions may fix some titles and break others; the opposite also happens.
• New or changing extensions: as VK_EXT_shader_object, which is still maturing and can expose edge cases with capture tools.
• Timeouts and TDR (Windows): If a job on the GPU takes forever, the system may restart the driver and leave the logical device “lost.”
• Overlays and layers: FPS injectors, chat, streaming, or tracers can interfere with the swapchain or pipeline.
• Particular swapchain configurations: Certain presentation, timing, or composition modes may trigger crashes on specific hardware/drivers.
• Shader cache corrupted or out of sync: clearing caches (like the .bin files in the example) can remove subtle inconsistencies.
• Hardware on the edge: Temperatures, power surges or slight overclocking/undervoltage may cause the error to appear intermittently.

How to diagnose without losing your cool

Before changing twenty things at once, it's better to follow an order. The goal is to isolate the factor that triggers VK_ERROR_DEVICE_LOST In your specific case, relying on signals that you can objectively measure or reproduce.

1. Reproduce the bug in a short sequence: a specific fight in Dota 2, a menu in Detroit, or the same capture step in RenderDoc (e.g., selecting the second vkQueueSubmit()).
2. Note the OS, driver, and GPU versions.: Data such as Windows 10 build 19045.4529, GeForce GTX 1080, and driver 566.12 help compare reports.
3. Disable overlays and layers: Steam, GeForce Experience, Discord, etc. Check if the behavior changes without them.
4. Returns to “stock” values: No GPU/CPU/RAM overclocking, with default power limits and no aggressive undervolting.
5. Recreates under tracing Only if necessary: ​​If RenderDoc or similar tools aggravate the problem, try without capturing first.
6. Clear shader cache: both the game and the driver, if applicable. The .bin files in the example support this.
7. Check system logs: On Linux, dmesg and journalctl; on Windows, Event Viewer and minidumps if there is a BSOD.

If in the process you come across a step that always precipitates the error (as it happened with the second vkQueueSubmit in the shader objects example), you already have half a diagnosis: try change only one variable (driver, swapchain setting, presentation mode) to see if the trigger disappears.

Practical solutions and adjustments that have worked

There is no universal magic wand, but there are actions with a good success rateBelow is a series of measures ordered from least to most intrusive.

Windows (NVIDIA/AMD) and Vulkan games

• NVIDIA-specific tuning for Detroit: Become Human: In Control Panel > Manage 3D Settings > Program Settings > select the game executable, locate the Vulkan/OpenGL preset, and set it to "Prefer Layers on DXGI Swapchain." This has eliminated repeated crashes with the RTX 3080.
• Limit FPS and synchronization: Maintaining 60 FPS and exclusive full screen can stabilize certain drivers, although it is not always sufficient on its own.
• Disable overlays: Steam, NVIDIA, Discord, etc. If you notice improvement, reintroduce them one by one to identify the culprit.
• “Known good” driverIf the error appears after updating, try a previous stable version; if you haven't updated in a while, install the latest WHQL version.

Linux and native titles with Vulkan (e.g. Dota 2)

• Check the graphics stack: : Mesa/NVIDIA version appropriate for your kernel and environment. A version bump may fix the infinite loop.
• Check composer and windows: Test with and without compositor, full screen vs. borderless window, and adjust the presentation mode if the game allows it.
• Logs in detail: Identify the time of the crash and look at dmesg/journalctl at that time. A GPU error or reset will be logged.

Capture and Debugging Tools (RenderDoc)

• Avoid problematic steps: If selecting a specific event (such as the second vkQueueSubmit()) triggers the crash, limit the analysis to steps before or after it.
• Reduce confusion: Clear shader caches (like the .bin ones in the example) before capturing and use “clean” builds of the project.
• Update or change version: both RenderDoc and the driver/GPU; with new extensions, a newer build may contain key fixes.

When Steam also crashes or a BSOD appears

• System integrity: Runs memory tests, monitors temperatures, and checks power supplies. VK_ERROR_DEVICE_LOST may be a visible symptom of a deeper problem.
• Kernel-level drivers: Cleanly reinstall the GPU driver. If the BSOD persists, collect minidumps to identify the exact module.

Little things that make a difference

There are seemingly minor adjustments that, in practice, completely change stability of a specific title. The "Prefer layers in DXGI Swapchain" setting for Detroit: Become Human is a clear example. These types of options modulate how layers, swapchain and the driver interact, and can bypass a specific bug.

Another useful detail is the clearing the shader cache before making major changes or analyzing screenshots, as was done with the .bin files in the shader object example. This reduces inconsistencies and old states that drag on between sessions and cloud diagnoses.

Finally, when a game It doesn't close but stays in a loop After the error, it's a clue that the logical device has become unusable without the application fully managing it. In those cases, it's worth testing. other execution routes (different backend if it exists, change screen mode, or disable advanced features like certain shadows or effects) to avoid the state that triggers the crash.

Resources to understand Vulkan (and debug better)

Learning more about Vulkan helps you interpret errors like VK_ERROR_DEVICE_LOST without jumping in blind. One community member recommended official Khronos resources with beginner-friendly approaches and curated lists. They are a good base whether you are programming or just want to understand what's going on.

• Beginners Guide to Vulkan (Khronos): A collection of introductory resources to help you get started and understand the API philosophy.
• Khronos Vulkan resources on GitHub: the listing indicates that the resources have been moved to vulkan.org, where you will find updated documentation.

If you don't know where to start, These guides will save you trial and error messy and will give you criteria to address issues such as device loss, timeouts, synchronization problems, and more.

Community signals: interaction and comments

In addition to detailed reports, there were light interactions like a “Like” in a comment, and conversations where they were asked learning resources. Although they seem like minor details, they reflect that the topic is alive and shared, and that many solutions are born from the sum of experiences.

Quick checklist for your case

If this is happening to you right now, try this one. short list of checks, inspired by the previous cases:

• Update or roll back driverIf you just updated and it started to fail, try the previous stable version; if you haven't updated in months, install the latest WHQL.
• Disable overlays: Steam, Discord, GeForce Experience, etc. and see if the error changes frequency.
• NVIDIA tuning per game: In Detroit: Become Human, setting the Vulkan/OpenGL preset to “Prefer Layers in DXGI Swapchain” resolved crashes.
• Screen mode and FPS: Force exclusive fullscreen and moderately limit FPS to stabilize rendering queues.
• Clear shader caches: Deletes game cache files and, if applicable, the driver.
• System logs: dmesg/journalctl on Linux or Event Viewer on Windows to detect driver resets or errors.

When to report and what to include

If the problem persists despite everything, report it to Accurate information Speed ​​up help. Avoid “No Responses” in key fields: include Game ID and timestamp If it is a game with replays, and attach screenshots or logs when it is possible.

Don't forget to add complete technical environment: OS version (e.g. Windows 10 build 19045.4529), Exact GPU (GeForce GTX 1080, RTX 3080), driver version (like 566.12), and whether you use tools like RenderDoc, its concrete version (e.g. RenderDoc_2024_07_02_0406d376_64). This data is gold to reproduce.

FAQs

Why doesn't the game crash and just loop after the error? Because the application enters a state where the logical device is lost, but the output logic is not fully executed. In practice, you have to force the closure and check what event or setting triggers that state.

Does clearing the shader cache help? In several scenarios yes, especially when there are inconsistencies between builds and caches (like the .bin files in the shader objects example). This is a quick way to discard corrupted states.

Should I capture with RenderDoc if I suspect the driver? Capture can help understand the pipeline, but it can also introduce instability if the extension or driver is green. Test first without capturing, and if you capture, do so with versions of the tool. that you know stable for your case.

Can overlays cause VK_ERROR_DEVICE_LOST? Yes, sometimes the injected layers interfere with the swapchain or with synchronization. Disabling them is one of the first tests to perform.

What if I also see BSOD in Windows? That suggests problems at the kernel/driver or hardware levelIn addition to the Vulkan steps, it performs memory tests, checks temperatures, inspects the power supply, and analyzes minidumps to locate the faulty module.

You have a clear roadmap: Identify the pattern, isolate the trigger, and apply adjustments with proven effectivenessFrom the preset change in the NVIDIA Control Panel that saved games in Detroit: Become Human on an RTX 3080, to RenderDoc capture guidelines and monitoring logs on Linux for Dota 2, there are concrete solutions that greatly reduce VK_ERROR_DEVICE_LOST-type crashes. If you also rely on Khronos resources to understand the basis of Vulkan, each attempt will be more accurate and you will waste less time on blind tests.