PC se congela jugando pero pasa los stress tests: metodología de diagnóstico paso a paso

El fallo que los tests no ven

Tienes un equipo con un Ryzen 7 5800X y una RTX 4060. Juegas un rato a Counter-Strike 2, a Valorant, o a lo que sea, y en algún momento la pantalla se queda negra, el audio a veces sigue unos segundos y el equipo acaba reiniciando o aterrizando directamente en la BIOS. Sin aviso, sin pantalla azul, sin mensaje de error útil.

Lo has probado todo: reinstalación limpia de Windows 11, cambio de perfil de RAM de DOCP 3600 MHz a automático, has movido físicamente la GPU, has revisado el Event Viewer y has encontrado un Event ID 161 de volmgr que no te lleva a ningún lado claro. Has ejecutado stress tests de CPU, GPU y sistema entero. Todo pasa. El equipo funciona perfectamente en cualquier otra tarea.

Esto no es un fallo raro. Es un patrón concreto con causas concretas. El problema es que los stress tests genéricos no replican exactamente las condiciones de carga que provoca el gaming: combinación de accesos rápidos a disco, picos de demanda al PSU en milisegundos, latencia de memoria bajo patrones de acceso irregulares y drivers interactuando en tiempo real. La metodología importa más que la herramienta.

Orden de diagnóstico: de lo más probable a lo más oscuro

Antes de tocar nada ni gastar un euro, sigue este orden. Cada paso tiene una prueba específica y un criterio de decisión claro.

1. RAM: el primer sospechoso cuando el fallo sobrevive a reinstalar Windows

Si el problema persiste después de una instalación limpia del sistema operativo, la causa más probable es hardware. Y dentro del hardware, la RAM con perfil XMP o DOCP activado en placas B450 es el culpable más frecuente en configuraciones similares.

El motivo es técnico: los perfiles de alta velocidad (3600 MHz DDR4) dependen de que la placa base los soporte correctamente a nivel de BIOS. Una placa B450 puede declarar compatibilidad con esa velocidad y aun así presentar inestabilidad en cargas con patrones de acceso específicos, exactamente el tipo de acceso que genera un juego. Un test genérico de memoria llena los módulos con patrones repetitivos y uniformes; el gaming no funciona así.

Prueba diagnóstica: entra en la BIOS y fija manualmente la RAM a 2133 MHz, la velocidad base JEDEC. Sin XMP, sin DOCP, sin ningún perfil automático. Juega durante varias sesiones. Si el problema desaparece, la causa es la configuración de memoria, no los módulos en sí. El siguiente paso sería buscar una actualización de BIOS específica para tu combinación de placa y procesador, o ajustar manualmente los timings y el voltaje en lugar de usar el perfil automático.

Si quieres confirmar que los módulos físicos son defectuosos (no solo mal configurados), ejecuta Memtest86 desde USB, fuera del sistema operativo, durante al menos un ciclo completo. Errores en Memtest indican módulos dañados; cero errores con congelamientos en gaming indican problema de configuración o de otra causa.

Respecto a si existe una versión de BIOS garantizada para B450 + Ryzen 5800X + DDR4 3600: la respuesta honesta es que no hay garantía universal. La estabilidad depende de la marca y revisión concreta de la placa, del kit de memoria y de la revisión del procesador. Siempre es validación empírica. Lo que sí puedes hacer es buscar en el foro oficial del fabricante de tu placa los hilos específicos para esa combinación antes de actualizar a ciegas.

2. Cable DisplayPort: el fallo que nadie espera

Hay un problema concreto con ciertos cables DisplayPort que merece mención propia porque parece absurdo hasta que lo ves. Algunos cables DP transfieren corriente parásita a través del pin 20, lo que puede causar inestabilidad en la GPU con síntomas casi idénticos a los de RAM inestable: congelamientos aleatorios, pantalla negra, reinicio sin log claro.

Prueba diagnóstica: cambia el cable de DisplayPort a HDMI, o directamente desconecta el cable DP y usa otro. Es la prueba más rápida del diagnóstico entero y no cuesta nada. Si el problema desaparece, el cable era el culpable.

3. Event ID 161 de volmgr: revisa el almacenamiento

El Event ID 161 de volmgr en el registro de eventos indica que el sistema intentó escribir un volcado de memoria durante el crash y no pudo, normalmente porque el disco estaba momentáneamente offline o porque hay corrupción. Esto no siempre apunta a un disco moribundo, pero sí justifica una comprobación inmediata.

Prueba diagnóstica: revisa los SMART stats del SSD o HDD con una herramienta como CrystalDiskInfo. Presta atención especialmente a los indicadores de sectores reasignados, errores de lectura sin corregir y horas de uso. Un SSD con sectores problemáticos puede funcionar perfectamente en uso normal y fallar bajo la presión de un juego cargando assets continuamente en segundo plano.

4. MSI Afterburner y la configuración corrupta

Hay un comportamiento documentado en Afterburner que explica directamente el patrón que describes: el problema desaparece temporalmente al reducir el power limit, incluso después de restaurarlo al 100%. Esto sugiere que no es el límite de potencia en sí el que resuelve el problema, sino el acto de reinstalar la herramienta y reescribir el archivo de configuración desde cero.

Los archivos de configuración de Afterburner pueden corromperse, especialmente si el equipo ha sufrido cierres abruptos previos. Una configuración corrupta puede hacer que la herramienta aplique límites o perfiles de una forma que no corresponde con lo que muestra en pantalla.

Prueba diagnóstica: desinstala Afterburner completamente, borra manualmente su carpeta de datos en AppData, reinicia y vuelve a instalar desde la página oficial de MSI. No importes configuraciones antiguas. Ajusta el power limit manualmente desde cero. En cuanto a qué versión usar: no existe una versión declarada como libre de este problema de forma oficial, así que la recomendación es siempre usar la más reciente disponible en la web del fabricante y no mantener versiones antiguas instaladas.

5. Registro de Windows: drivers desincronizados

Este es uno de los fallos más difíciles de detectar porque no genera logs capturables. Lo que ocurre es que el registro de Windows puede desincronizarse con los drivers realmente instalados, especialmente si ha habido varias actualizaciones o reinstalaciones parciales. El caso más frecuente en gaming es GameInput: si las entradas del registro apuntan a una versión antigua del componente mientras el sistema tiene instalada una más nueva, el conflicto puede provocar crashes sin pantalla azul y sin volcado de memoria.

Prueba diagnóstica: busca en el registro de Windows entradas relacionadas con GameInput y, si encuentras versiones duplicadas o entradas huérfanas, elimínalas manualmente. Luego reinstala el componente desde su fuente oficial en GitHub. Es un paso que requiere algo de cuidado en el editor de registro, pero el proceso está bien documentado y no entraña riesgo si se hace con atención.

6. PSU: el culpable que los tests no cazan bien

Los fallos de fuente de alimentación son especialmente traidores porque un test de carga sostenida no replica los picos de demanda que ocurren en milisegundos durante gaming: carga de nivel, explosiones de partículas, cambios de escena. Una PSU que entrega correctamente bajo carga estable puede fallar en esos picos transitorios.

Hay casos documentados donde equipos con hardware de alto rendimiento presentaban exactamente este síntoma y el cambio de PSU resolvió completamente el problema sin que ningún test previo hubiera señalado la fuente como culpable.

Sin equipo de medición, la forma más fiable de diferenciar entre PSU defectuosa, cable GPU defectuoso y mala conexión en los conectores de la GPU es por exclusión:

• Primero, revisa que los conectores de alimentación de la GPU usen el mismo raíl de 12V. Si tu PSU tiene cables modulares con dos conectores de 8 pines que salen del mismo cable, intenta separarlos usando dos cables independientes si la PSU lo permite (muchas PSU modulares tienen los conectores marcados con contornos blancos en el panel trasero para identificar los raíles).
• Segundo, inspecciona físicamente los cables dentro de la caja. Un cable de GPU que roza contra un ventilador que no gira correctamente puede causar throttling o interrupciones intermitentes que no aparecen en ningún log. Parece improbable, pero es un fallo real con casos documentados: rewiring completo del cableado interno resolvió el problema después de meses de diagnóstico infructuoso.
• Si todos los pasos anteriores no revelan nada y el equipo sigue fallando, el reemplazo de PSU es el siguiente paso lógico, especialmente si la fuente tiene varios años de uso intensivo.

Resumen del orden de actuación

• RAM a 2133 MHz como primera prueba. Si se resuelve, buscar actualización de BIOS o ajuste manual de timings.
• Cambiar cable DisplayPort a HDMI o desconectar DP. Prueba de cinco minutos que descarta un culpable real.
• Revisar SMART stats del SSD/HDD. Si el Event ID 161 de volmgr aparece en los logs, esto no es opcional.
• Reinstalar MSI Afterburner desde cero si lo tienes instalado. No importar configuraciones anteriores.
• Limpiar entradas de GameInput en el registro y reinstalar el componente desde fuente oficial.
• Inspección física de cables internos y revisión de raíles de PSU. Si todo lo anterior falla, valorar reemplazo de PSU.

Por qué este orden importa en un entorno de trabajo

Este tipo de fallo, congelamientos aleatorios en carga gráfica con el resto del sistema funcionando bien, suele acabar en una llamada al servicio técnico o en el reemplazo de componentes que no eran el problema. El orden de diagnóstico que describe esta guía está pensado para descartar causas baratas o gratuitas antes de llegar a las caras.

En un parque de varios equipos similares, el valor de documentar este proceso es doble: si el fallo aparece en una máquina y se resuelve correctamente, tienes el protocolo listo para el resto. La diferencia entre un diagnóstico metódico y uno por intuición no es solo económica; también es la diferencia entre resolver el problema en dos días o en dos meses.

Si tienes equipos en tu empresa con síntomas parecidos (congelamientos en cargas específicas, sin logs claros, que pasan todos los tests), vale la pena recorrer esta secuencia antes de asumir que hay que reemplazar hardware.