Caídas repentinas de FPS en juegos: cómo encontrar la causa real

Iba a 140. Ahora va a 70 y se queda ahí hasta que reinicias el juego — o hasta que paras, dejas que la máquina se enfríe y vuelves para encontrártelo bien.

Ese es un problema distinto de un tirón, y confundir los dos le cuesta semanas a la gente. Un tirón es un fotograma que llega tarde dentro de una ejecución por lo demás sana — si es eso lo que tienes, la página que buscas es por qué los juegos dan tirones en Windows 11. Una caída es un cambio sostenido en cuánto trabajo saca adelante la máquina por segundo, y casi todo lo de abajo se anuncia solo si miras los números correctos mientras ocurre.

Primero, la frase honesta. Nada de esta página hace más rápido un juego. Muestra tres rastros que Windows ya guarda — los reinicios del driver de pantalla, el firmware que mantiene abajo el reloj del procesador y los techos del procesador en tu plan de energía activo —, que el escaneo de tirones de w0a lee por ti, y cómo leer esos mismos tres tú mismo en un par de minutos.

Las tres preguntas que dividen todo el terreno

Antes de tocar ningún ajuste, responde a estas — cada una elimina más o menos la mitad de la lista.

1. ¿Se recupera sola? Una caída que se va después de un minuto quieto apunta al calor o a un trabajo en segundo plano. Una que persiste hasta que reinicias el juego apunta al estado del propio juego o a un suceso del driver.
2. ¿Pasa en todos los juegos o en uno? En todos apunta a la máquina. En uno solo apunta a los ajustes de ese juego, a su actualización o a sus servidores.
3. ¿Va con el rato que llevas jugando o con un sitio del mapa? El tiempo significa calor y energía. Un sitio significa que la escena se puso más dura, o que algo se está cargando.

Después mira los relojes y las temperaturas mientras está pasando, no a posteriori. Una caída que es invisible en retrospectiva es obvia en directo: o un reloj bajó, o no bajó.

El calor y el techo de potencia

Una causa que hay que descartar cuando «se me cae a los veinte minutos».

Los chips no fallan cuando se calientan: van más despacio. Cuando se alcanza una temperatura o un límite de potencia, el reloj se baja y se mantiene ahí mientras dure la condición. Esa decisión la toma el firmware por su cuenta — la protección de la propia placa o del propio procesador, no la de Windows — así que nada del Administrador de tareas lo explica. Del lado gráfico, el driver dice el motivo si se lo preguntas bajo carga: protección térmica, un límite de potencia puesto por debajo del de fábrica, un programa pidiéndole al driver que vaya más despacio, o un conector de alimentación PCIe que no está bien encajado.

Cómo lo sabes: va con el rato que llevas jugando y con la temperatura de la habitación, y el reloj está visiblemente más bajo durante la caída que al principio.

Qué haces: el montaje del disipador, el polvo, el flujo de aire de la caja. Después comprueba si alguien bajó un límite de potencia a propósito — en el firmware, en una utilidad del fabricante o en un perfil guardado de la tarjeta gráfica.

La máquina cambió de estado de energía

En los portátiles esto es lo más evidente: desenchufas el cargador y la plataforma pasa a otro conjunto de límites. En los sobremesa también pasa — un plan de energía cambiado, el aparcado de núcleos o un techo de estado del procesador que dejó atrás un script de ajuste antiguo, un plan que volvió atrás después de una actualización de Windows.

Cómo lo sabes: la caída empieza en un suceso — desenchufar, cerrar la tapa, volver de suspensión, un reinicio — no en una temperatura.

Qué haces: devuelve los valores por defecto del propio plan en vez de inventarte valores nuevos. La página Fix tiene tarjetas para el plan de energía y para los ajustes de energía del procesador, y cada una escribe el valor por defecto de Windows sin condiciones, sea cual sea la herramienta que lo cambió.

Un reinicio del controlador

La pantalla se pone en negro un segundo o dos, vuelve, y todo va más lento — o el juego se ha cerrado. Windows registró que el driver de pantalla se colgó y fue reiniciado.

Cómo lo sabes: esto deja un rastro claro, y el escaneo de tirones reporta cuántos reinicios hubo en el último día. El rastro suele apuntar a un overclock o a la refrigeración, no al software.

Qué haces: si tienes aplicado un offset de memoria o de núcleo, redúcelo a la mitad y prueba una partida; ponlo a cero y prueba otra vez. Recuperación ante bloqueo de la GPU cubre el resto, incluido devolver el valor por defecto de Windows si una herramienta antigua subió el tiempo de espera en vez de arreglar la causa.

Tres rastros que Windows ya guarda

1. Un reinicio del driver de pantalla (evento 4101)

Cuando el driver de pantalla deja de responder y se reinicia, Windows escribe el evento 4101 en el registro de eventos System. El escaneo de tirones cuenta los de las últimas 24 horas y los reporta como su único hallazgo crítico; por encima de diez dice «10+» en lugar de fingir que sabe el número exacto. Si no se puede leer el propio registro de eventos, el escaneo dice que la comprobación no pudo ejecutarse en lugar de dar la máquina por limpia.

Para mirarlo tú mismo, en PowerShell:

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Display'] and (EventID=4101) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 10

Si no hay ninguno, PowerShell responde con un error que dice que ningún evento coincide con los criterios de selección: esa es la respuesta «ninguno en el último día». Si dice que no puede leer el registro de eventos, ejecuta PowerShell como administrador y vuelve a intentarlo.

La vuelta atrás es la de la sección de arriba: baja o quita un overclock, revisa la refrigeración y recuperación ante bloqueo de la GPU si una herramienta antigua subió el tiempo de espera del driver. w0a no va a subir ese tiempo de espera por su cuenta: un watchdog más largo solo alarga cada congelación, y desactivar la recuperación la elimina por completo.

2. El firmware mantuvo el reloj abajo (evento 37)

El evento 37 de Microsoft-Windows-Kernel-Processor-Power es el firmware dejando constancia de que bajó el reloj del procesador y lo mantuvo ahí durante segundos enteros seguidos; el propio texto del evento dice cuánto tiempo. Importa porque una lectura de temperatura solo muestra el momento en que miras: una máquina que redujo la frecuencia hace una hora y se ha enfriado desde entonces parece perfectamente sana, y este evento es el único rastro de esa hora que le queda.

El escaneo los cuenta de las últimas 24 horas, solo con alimentación de red — con batería, el mismo evento es la plataforma haciendo su trabajo — y avisa a partir de tres. Uno o dos son habituales en los primeros segundos después del arranque, mientras la placa asienta sus límites de potencia.

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Processor-Power'] and (EventID=37) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 20

Deja el nombre del proveedor en el filtro. Otros componentes usan el número 37 para eventos que no tienen nada que ver, y un recuento sin el proveedor no significa nada.

Si encuentras un reguero de estos, la causa es el calor o un límite de potencia, como en la sección del calor de arriba; temperaturas de CPU y GPU al jugar explica qué leer, y en un portátil portátil gaming más lento de lo que debería trata el cargador y los modos de energía.

3. El plan activo limita el procesador

El nombre de un plan no es lo que se ejecuta. Un plan de alto rendimiento con el estado máximo del procesador al 80% es una máquina limitada con la etiqueta correcta. El escaneo lee cuatro ajustes de la sección del procesador del plan que esté activo, con alimentación de red:

El escaneo los lee a través de la interfaz de energía de Windows y no con powercfg, porque en una instalación estándar dos de ellos están ocultos y powercfg no imprime absolutamente nada para ellos. Si no puede leer ninguno de los cuatro, el escaneo dice que no pudo medir, no que el plan está limpio.

Para mirarlo tú mismo, en el símbolo del sistema o en PowerShell:

powercfg /getactivescheme
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMAX
powercfg /query SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR CPMINCORES

Cómo leer las respuestas:

• El valor está en las dos últimas líneas de la respuesta, en hexadecimal: la primera es el valor con alimentación de red (AC), la segunda el valor con batería (DC). 0x00000064 es 100, 0x00000050 es 80, 0x00000001 es 1, 0x00000000 es 0.
• Los nombres de los ajustes alrededor de los números se imprimen en el idioma de tu Windows; los alias que escribes (SUB_PROCESSOR, PROCTHROTTLEMAX) son los mismos en todos los idiomas.
• Si toda la respuesta es una sola línea con el GUID del plan y nada debajo, el comando está preguntando por un ajuste que Windows oculta en esta instalación. Eso no dice nada de su valor; el escaneo de tirones es la forma de leerlo.

La vuelta atrás, ajuste por ajuste:

• PROCTHROTTLEMAX o CPMINCORES escritos en los planes propios de Windows: la tarjeta ajustes de energía del procesador devuelve el estado mínimo y máximo del procesador y el aparcado de núcleos al valor por defecto que declara cada plan, y luego vuelve a aplicar el plan activo, porque Windows lee los valores de un plan cuando se activa.
• Un techo que vive en un plan que creó alguna herramienta: la tarjeta plan de energía y batería cambia primero al plan Equilibrado, para que ese plan deje de ser el que se ejecuta, y borra los planes propios de w0a.
• PERFBOOSTMODE o IDLEDISABLE: hoy ninguna tarjeta de reparación restablece estos dos por su nombre. La vuelta atrás es el propio plan, con powercfg, al valor que el plan declara como predeterminado.

Pasó justo después de una actualización

Aquí se esconden dos cosas muy distintas.

Una actualización del juego o del driver invalida la caché de shaders, y el juego recompila mientras juegas. La tasa de fotogramas es realmente más baja durante un rato y luego deja de serlo. Se va apagando; esa es la firma. Tirones por compilación de shaders explica por qué, y por qué no deberías hacer benchmark dentro de esa ventana.

Una regresión de una rama de driver no se va apagando. Los fabricantes sí las admiten por escrito — las notas de versión traen entradas del tipo «menor rendimiento en este título en ramas más nuevas que X». No bajes de versión por reflejo: termina tus actualizaciones, mide en tu propia máquina, y solo plantéate otra versión si puedes documentar tú mismo la regresión.

Empezó a ejecutarse otra cosa

Un análisis programado, un proceso de actualización descomprimiendo, un archivo extrayéndose, una exportación de vídeo. Se pone en cola por los mismos núcleos que el juego y, a diferencia de un tirón puntual, no desaparece entre fotogramas — muchas veces se puede reproducir a cierta hora del día. El uso total de CPU es el número equivocado que mirar: un solo núcleo saturado en una máquina de ocho núcleos se lee como un total modesto. Espera a que pase, o mueve ese trabajo.

La tasa de fotogramas no cayó de verdad

Un tope. Si el número en el que te quedas es exactamente tu frecuencia de actualización, tu límite dentro del juego o un límite del lado del driver, no hay ningún cuello de botella — estás en el techo que pediste.

Resolución dinámica. Un juego que escala su propia resolución de renderizado para sostener una tasa de fotogramas objetivo muestra un contador estable mientras lo que se mueve es la calidad de imagen.

Es un solo juego, y el contador se ve bien

Entonces puede que la caída no esté en tu máquina en absoluto. Una partida en línea se degrada para todos los del servidor a la vez, y un problema de red no es un problema de tasa de fotogramas: los paquetes que llegan tarde hacen que el mundo dé tirones a tu alrededor mientras tu máquina sigue dibujando a toda velocidad. Si los tiempos de fotograma están sanos durante el suceso, deja de mirar el PC.

Si lo que pasa en cambio es que la tasa de fotogramas es sencillamente más baja de lo que debería mientras la tarjeta gráfica está parada, ese es un diagnóstico aparte con su propia lista: la GPU no llega al 100% la recorre en orden.

Una prueba que produce una respuesta

1. Graba una captura de una sesión normal antes de que nada vaya mal, y guárdala. Leer el resultado del benchmark explica cómo, y por qué la media es el número menos útil de ahí.
2. Cuando llegue la caída, apunta los relojes y las temperaturas durante ella, no después.
3. Cambia una sola cosa, y después reproduce la misma escena y la misma duración de sesión.
4. Júzgalo contra tu propia variación entre ejecuciones. Si tres ejecuciones sin cambios varían más que la diferencia que te ha alegrado, lo que encontraste es ruido.

Qué no hacer ante una caída

No subas el tiempo de espera de recuperación del driver gráfico para esconder un reinicio del controlador: convierte una recuperación corta en un congelamiento más largo y borra las pruebas. No desactives núcleos ni el multihilo simultáneo apoyándote en una guía sin fuentes — estarías cambiando capacidad multinúcleo conocida por una ganancia cuyo método nadie ha publicado. Y no apliques valores de gestión de memoria del kernel como arreglo de rendimiento; este producto se niega a escribirlos, y no hay ninguna medición que los respalde.

Lo mismo vale para los ajustes de energía: ninguno de los cuatro de arriba es un interruptor de «rendimiento» que haya que girar al revés. Con el turbo desactivado, el procesador se queda en su reloj nominal, y el propio escaneo de w0a también marca los estados de reposo desactivados como límite, dondequiera que los encuentre.

Relacionado

• Por qué los juegos dan tirones en Windows 11
• La GPU no llega al 100%
• Tirones por compilación de shaders
• Recuperación ante bloqueo de la GPU
• Qué busca el escaneo de tirones
• Temperaturas de CPU y GPU al jugar