VK_ERROR_DEVICE_LOST en Vulkan: causas reales, diagnósticos y arreglos

Si te has topado con el mensaje VK_ERROR_DEVICE_LOST mientras juegas o trazas aplicaciones con Vulkan, no eres la única persona: es un fallo frecuente que puede manifestarse como cuelgues, cierres inesperados o incluso bucles en los que el programa no termina de cerrar. Aunque asusta, suele tener explicación y, lo más importante, caminos para mitigarlo o resolverlo.

En esta guía vas a encontrar casos reales en Windows y Linux, con juegos y herramientas, pistas para diagnosticar el origen, configuraciones que han ayudado a otros usuarios (como un ajuste concreto en el Panel de control de NVIDIA para Detroit: Become Human con una RTX 3080) y recursos fiables para entender mejor Vulkan. La idea es que no pierdas tiempo saltando de foro en foro y tengas, de un vistazo, las soluciones que realmente tienen posibilidades. Vamos a aprender todo sobre el error VK_ERROR_DEVICE_LOST. 

Qué significa VK_ERROR_DEVICE_LOST y por qué aparece

En Vulkan, el error VK_ERROR_DEVICE_LOST indica que el dispositivo lógico ha dejado de estar operativo: el controlador de la GPU lo ha reiniciado, se produjo un cuelgue del driver, un TDR por bloqueo o exceso de tiempo en una cola, o la aplicación envió algo que el hardware/driver no ha podido gestionar. No siempre termina con un crash; en ocasiones, como veremos, la aplicación queda en un bucle y hay que cerrarla a la fuerza.

Aunque el patrón varía según el equipo y el software, los detonantes habituales son drivers inestables, extensiones muy nuevas, capas/overlays, límites de tiempo del sistema y, a veces, simples combinaciones desafortunadas de ajustes gráficos. Conocer algunos casos reales ayuda a reproducir y atacar el problema.

Casos reales: qué pasó y qué se hizo

Detroit: Become Human en Windows, RTX 3080, y un ajuste decisivo en NVIDIA

Un usuario con una GeForce RTX 3080 se topaba con cierres constantes del juego con VK_ERROR_DEVICE_LOST pese a haber hecho lo típico: actualizar los drivers, probar el modo de compatibilidad y revisar opciones. La solución que le funcionó fue ir al Panel de control de NVIDIA y cambiar una preferencia específica relacionada con Vulkan/OpenGL a nivel de programa.

La ruta, formulada de otra manera, fue: Panel de control de NVIDIA > Administrar la configuración 3D > Configuración de programa > seleccionar Detroit: Become Human. En la opción del método preestablecido para Vulkan/OpenGL, el ajuste que marcó la diferencia fue ponerlo en «Preferir por capas en DXGI Swapchain«. Con ese cambio, desaparecieron los cierres repetidos asociados a VK_ERROR_DEVICE_LOST.

Este ejemplo ilustra que, a veces, un ajuste de compatibilidad o de cómo se gestiona el swapchain con las capas puede ser la clave, sobre todo cuando el título tiene una canalización de render particular o cuando hay interacción con otras capas del sistema.

Dota 2 en Linux: cuelgue en bucle e inestabilidad aparentemente aleatoria

Otro caso significativo es el de Dota 2 ejecutado de forma nativa en Linux. El patrón reportado fue desconcertante: el error VK_ERROR_DEVICE_LOST emergía tanto durante partidas en tiempo real como al ver repeticiones, a veces simplemente al mirar una pelea o hasta al escribir en el chat. En lugar de cerrarse del todo, el juego se quedaba en un bucle infinito y había que “matarlo” manualmente.

En esa experiencia concreta no se aportaron Match ID ni capturas (se indicaba «No response» en ambos campos), lo que complica correlacionar momentos exactos. Aun así, el síntoma (bloqueo sin crash completo) apunta a un estado del dispositivo irrecuperable desde la perspectiva de la aplicación. En Linux, este patrón puede estar relacionado con el driver, con la cola de presentación y la gestión de tiempos, o con alguna interacción del compositor/entorno gráfico.

En escenarios así conviene revisar logs del sistema (dmesg, journalctl), comprobar versiones de Mesa/NVIDIA según GPU, y desactivar capas de terceros. Son pistas que, si bien genéricas, cobran relevancia en un título Vulkan con uso intensivo del render como Dota 2.

Capturas inestables con RenderDoc y VK_EXT_shader_object

El uso de herramientas de trazado añade su propio conjunto de variables. Se han observado inestabilidades con RenderDoc al capturar aplicaciones que emplean la extensión VK_EXT_shader_object, incluyendo crashes del driver recuperados, bloqueos de la aplicación y errores de dispositivo perdido. No es extraño: hablamos de una extensión reciente y de una situación intrínsecamente delicada (injertar una capa de captura en una canalización avanzada).

Para reproducir el problema de forma consistente se usó el ejemplo «shaderobjects» del repositorio de SaschaWillems/Vulkan. El procedimiento fue: ejecutar el binario shaderobjects.exe bajo RenderDoc, capturar un frame y seleccionar el segundo evento vkQueueSubmit(). En ese momento, aparecía el diálogo del reporte de error de la herramienta.

Además, para reducir factores de confusión, antes de la captura se eliminaron los archivos .bin que genera el ejemplo (cachés de shaders), y aun así el fallo se reproducía. El entorno concreto era: RenderDoc_2024_07_02_0406d376_64, Windows 10 (10.0.19045.4529), Vulkan 1.3.275, GeForce GTX 1080 y driver 566.12. Estos datos son muy útiles si vas a reportar o comparar problemas de la misma naturaleza.

Cierres de juego y de Steam, e incluso pantallazos azules

También se reportó un escenario especialmente molesto: se cerraba el juego con frecuencia, a veces también Steam, e incluso aparecía un BSOD (pantalla azul). Se habían probado ya acciones básicas como actualizar drivers, ajustar la calidad gráfica, forzar el modo pantalla completa, desactivar overlays y limitar los FPS a 60, pero los cierres continuaban cada pocos minutos de partida.

Cuando hay pantallazos azules en la ecuación, cobra peso la sospecha de inestabilidad a nivel de kernel/driver o del propio hardware. Aunque VK_ERROR_DEVICE_LOST es un error de Vulkan, si el sistema entero se tambalea, conviene complementar con pruebas de memoria, chequeo de discos, y monitorización térmica para descartar que la GPU o su alimentación estén al límite.

Posibles causas: técnicas y del día a día

Aunque cada caso es un mundo, hay un ramillete de causas frecuentes que conviene considerar. Aquí tienes un mapa para orientarte con lo más habitual en VK_ERROR_DEVICE_LOST:

• Drivers gráficos inestables o con regresiones: versiones recientes pueden arreglar unos títulos y romper otros; lo contrario también pasa.
• Extensiones nuevas o cambiantes: como VK_EXT_shader_object, que aún está madurando y puede exponer casos límite con herramientas de captura.
• Timeouts y TDR (Windows): si un trabajo en la GPU se eterniza, el sistema puede reiniciar el driver y dejar al dispositivo lógico “perdido”.
• Overlays y capas: inyectores de FPS, chat, streaming o trazadores pueden interferir con el swapchain o el pipeline.
• Configuraciones particulares del swapchain: determinados modos de presentación, sincronización o composición pueden disparar fallos en hardware/driver concretos.
• Shader cache corrupta o desincronizada: limpiar cachés (como los .bin del ejemplo) puede eliminar inconsistencias sutiles.
• Hardware al límite: temperaturas, picos de consumo o un leve overclock/undervolt pueden hacer aparecer el error de forma intermitente.

Cómo diagnosticar sin perder la calma

Antes de cambiar veinte cosas a la vez, es mejor seguir un orden. El objetivo es aislar el factor que dispara el VK_ERROR_DEVICE_LOST en tu caso concreto, apoyándote en señales que objetivamente puedas medir o reproducir.

1. Reproduce el fallo en una secuencia corta: una pelea concreta en Dota 2, un menú en Detroit o el mismo paso de captura en RenderDoc (p.ej., seleccionar el segundo vkQueueSubmit()).
2. Anota versión de SO, driver y GPU: datos como Windows 10 build 19045.4529, GeForce GTX 1080 y driver 566.12 ayudan a comparar informes.
3. Desactiva overlays y capas: Steam, GeForce Experience, Discord, etc. Comprueba si el comportamiento cambia sin ellas.
4. Vuelve a valores “stock”: sin overclock de GPU/CPU/RAM, con límites de potencia por defecto y sin undervolt agresivo.
5. Recrea under tracing sólo si es necesario: si RenderDoc o herramientas similares agravan el problema, prueba primero sin capturar.
6. Limpia cache de shaders: tanto la del juego como la del driver si procede. El caso de los .bin del ejemplo lo respalda.
7. Revisa registros del sistema: en Linux, dmesg y journalctl; en Windows, Visor de eventos y minidumps si hay BSOD.

Si en el proceso das con un paso que siempre precipita el error (como ocurría con el segundo vkQueueSubmit en el ejemplo de shader objects), ya tienes medio diagnóstico: intenta cambiar sólo una variable (driver, ajuste de swapchain, modo de presentación) para ver si el trigger desaparece.

Soluciones prácticas y ajustes que han funcionado

No existe una varita mágica universal, pero sí acciones con buena tasa de éxito. A continuación, una batería de medidas ordenadas de menos a más intrusivas.

Windows (NVIDIA/AMD) y juegos Vulkan

• Ajuste específico en NVIDIA para Detroit: Become Human: en Panel de control > Administrar configuración 3D > Configuración de programa > elige el ejecutable del juego, localiza el método preestablecido para Vulkan/OpenGL y establece «Preferir por capas en DXGI Swapchain». Ha eliminado cierres repetidos con RTX 3080.
• Limitar FPS y sincronización: mantener 60 FPS y pantalla completa exclusiva puede estabilizar ciertos drivers, aunque no siempre es suficiente por sí solo.
• Desactiva overlays: Steam, NVIDIA, Discord, etc. Si notas mejora, reintroduce uno a uno para identificar al culpable.
• Driver “bueno conocido”: si el error aparece tras actualizar, prueba una versión anterior estable; si llevas tiempo sin actualizar, instala la última WHQL.

Linux y títulos nativos con Vulkan (ej. Dota 2)

• Comprueba la pila gráfica: versión de Mesa/NVIDIA adecuada para tu kernel y entorno. Un salto de versión puede arreglar el bucle infinito.
• Revisa compositor y ventanas: prueba con y sin compositor, pantalla completa vs. ventana sin bordes, y ajusta el modo de presentación si el juego lo permite.
• Logs al detalle: identifica el momento del cuelgue y mira dmesg/journalctl en esa marca temporal. Un error de GPU o un reset quedarán registrados.

Herramientas de captura y depuración (RenderDoc)

• Evita pasos problemáticos: si seleccionar un evento concreto (como el segundo vkQueueSubmit()) dispara el crash, limita el análisis a pasos previos o posteriores.
• Reduce confusores: borra cachés de shaders (como los .bin del ejemplo) antes de capturar y usa builds “limpias” del proyecto.
• Actualiza o cambia de versión: tanto de RenderDoc como del driver/GPU; con extensiones nuevas, una build más reciente puede contener arreglos clave.

Cuando también cae Steam o aparece un BSOD

• Integridad del sistema: ejecuta pruebas de memoria, monitoriza temperaturas y revisa fuentes de alimentación. VK_ERROR_DEVICE_LOST puede ser el síntoma visible de un problema más profundo.
• Controladores a nivel kernel: reinstala con limpieza el driver de la GPU. Si sigue el BSOD, recoge minidumps para identificar el módulo exacto.

Pequeños detalles que marcan la diferencia

Hay ajustes aparentemente menores que, en la práctica, cambian por completo la estabilidad de un título concreto. El ajuste de «Preferir por capas en DXGI Swapchain» para Detroit: Become Human es un ejemplo claro. Ese tipo de opciones modulan cómo interactúan capas, swapchain y el driver, y pueden esquivar un bug específico.

Otro detalle útil es la limpieza de la caché de shaders antes de grandes cambios o de analizar capturas, como se hizo con los .bin del ejemplo de shader objects. Esto reduce inconsistencias y estados antiguos que se arrastran entre sesiones y enturbian los diagnósticos.

Por último, cuando un juego no se cierra pero se queda en bucle tras el error, es una pista de que el dispositivo lógico quedó inservible sin que la aplicación lo gestionara del todo. En esos casos vale la pena probar otras rutas de ejecución (diferente backend si existe, cambiar modo de pantalla, o desactivar funciones avanzadas como ciertas sombras o efectos) para evitar el estado que dispara el fallo.

Recursos para entender Vulkan (y depurar mejor)

Aprender más sobre Vulkan ayuda a interpretar errores como VK_ERROR_DEVICE_LOST sin ir a ciegas. Un miembro de la comunidad recomendó recursos oficiales de Khronos con enfoques para principiantes y listados curados. Son una buena base tanto si programas como si simplemente quieres comprender qué está pasando.

• Beginners Guide to Vulkan (Khronos): recopilación de recursos introductorios para empezar con buen pie y entender la filosofía de la API.
• Khronos Vulkan resources en GitHub: el listado indica que los recursos se han trasladado a vulkan.org, donde encontrarás documentación actualizada.

Si no sabes por dónde empezar, estas guías te evitarán el ensayo y error desordenado y te darán criterio para abordar fallos como device lost, timeouts, problemas de sincronización y demás.

Señales de la comunidad: interacción y comentarios

Además de reportes detallados, hubo interacciones ligeras como un “Me gusta” en un comentario, y conversaciones donde se pedían recursos de aprendizaje. Aunque parecen detalles menores, reflejan que el tema es vivo y compartido, y que muchas soluciones nacen de la suma de experiencias.

Checklist rápido para tu caso

Si ahora mismo te está ocurriendo, prueba esta lista corta de comprobaciones, inspirada en los casos anteriores:

• Actualiza o retrocede driver: si acabas de actualizar y empezó a fallar, prueba la versión anterior estable; si no actualizas desde hace meses, instala la última WHQL.
• Desactiva overlays: Steam, Discord, GeForce Experience, etc. y comprueba si el error cambia de frecuencia.
• Ajuste de NVIDIA por juego: en Detroit: Become Human, poner el preset Vulkan/OpenGL en «Preferir por capas en DXGI Swapchain» resolvió cierres.
• Modo de pantalla y FPS: fuerza pantalla completa exclusiva y limita FPS moderadamente para estabilizar colas de presentación.
• Limpia cachés de shader: elimina archivos de caché del juego y, si procede, del driver.
• Registros del sistema: dmesg/journalctl en Linux o Visor de eventos en Windows para detectar reseteos o errores del driver.

Cuándo reportar y qué incluir

Si a pesar de todo el problema persiste, reportarlo con información precisa acelera la ayuda. Evita los “No response” en campos clave: incluye ID de partida y timestamp si es un juego con replays, y adjunta capturas o logs cuando sea posible.

No olvides añadir entorno técnico completo: versión del SO (por ejemplo, Windows 10 build 19045.4529), GPU exacta (GeForce GTX 1080, RTX 3080), versión del driver (como 566.12), y si usas herramientas como RenderDoc, su versión concreta (por ejemplo, RenderDoc_2024_07_02_0406d376_64). Estos datos son oro para reproducir.

Preguntas frecuentes

¿Por qué el juego no se cierra y se queda en bucle tras el error? Porque la aplicación entra en un estado donde el dispositivo lógico está perdido, pero la lógica de salida no se ejecuta por completo. En la práctica, hay que forzar el cierre y revisar qué evento o ajuste dispara ese estado.

¿Sirve de algo limpiar la caché de shaders? En varios escenarios sí, especialmente cuando hay inconsistencias entre builds y cachés (como los .bin del ejemplo de shader objects). Es una forma rápida de descartar estados corruptos.

¿Debería capturar con RenderDoc si sospecho del driver? Capturar puede ayudar a entender el pipeline, pero también puede introducir inestabilidad si la extensión o el driver están verdes. Prueba primero sin capturar y, si capturas, hazlo con versiones de la herramienta que sepas estables para tu caso.

¿Pueden los overlays causar VK_ERROR_DEVICE_LOST? Sí, a veces las capas inyectadas interfieren con el swapchain o con la sincronización. Desactivarlas es de las primeras pruebas a realizar.

¿Qué pasa si además veo BSOD en Windows? Eso sugiere problemas a nivel de kernel/driver o hardware. Además de los pasos de Vulkan, realiza pruebas de memoria, verifica temperaturas, revisa la fuente de alimentación y analiza minidumps para localizar el módulo que falla.

Tienes una hoja de ruta clara: identificar el patrón, aislar el gatillo y aplicar ajustes con probada eficacia. Desde el cambio de preset en el Panel de control de NVIDIA que salvó partidas en Detroit: Become Human con una RTX 3080, hasta las pautas para capturas con RenderDoc y la vigilancia de logs en Linux para Dota 2, hay soluciones concretas que reducen mucho los cuelgues tipo VK_ERROR_DEVICE_LOST. Si además te apoyas en recursos de Khronos para comprender la base de Vulkan, cada intento será más certero y perderás menos tiempo en pruebas a ciegas.