Cómo detectar y solucionar fugas de recursos y fallos gráficos en Windows

Si Windows empieza funcionando con normalidad y, después de varias horas, las ventanas dejan de dibujarse correctamente o las aplicaciones pierden estabilidad, puede haber una acumulación de recursos que no se liberan. Sin embargo, una pantalla negra o un consumo elevado de memoria no bastan para confirmar una fuga.

Para investigar una posible fuga de recursos gráficos en Windows, conviene distinguir los objetos de la interfaz, la memoria utilizada por la GPU y la memoria de las aplicaciones. Cada categoría requiere mediciones diferentes. El objetivo es encontrar un crecimiento repetible y relacionarlo con un proceso o una operación concreta.

Identifica qué recurso crece: GDI, memoria gráfica o RAM

La expresión «recursos gráficos» puede referirse a elementos distintos. Antes de cambiar controladores, comprueba qué indicador aumenta:

Recurso	Qué representa	Dónde empezar
Objetos GDI	Recursos de dibujo, como mapas de bits, fuentes y contextos de dispositivo.	Recuento de objetos GDI por proceso.
Objetos USER	Objetos de la interfaz, como ventanas, menús y cursores.	Recuento de objetos USER por proceso.
Memoria de la GPU	Memoria dedicada y memoria del sistema compartida con la GPU.	Administrador de tareas, apartados Rendimiento y Detalles.
Memoria privada de una aplicación	Memoria comprometida que no comparte con otros procesos.	Contador Private Bytes del proceso.
Pools paginado y no paginado	Recursos de memoria del kernel utilizados por Windows y los controladores.	Contadores globales de memoria y, si hace falta, PoolMon.

El agotamiento de objetos de la interfaz puede provocar fallos aunque todavía quede memoria disponible. Por eso, observar únicamente el porcentaje de RAM o los gigabytes de VRAM puede dejar fuera una parte importante del problema.

Comprueba los objetos GDI y USER por proceso

En Windows 11 puedes comenzar con el Administrador de tareas:

1. Ábrelo con Ctrl + Mayús + Esc.
2. Entra en Detalles.
3. Haz clic derecho sobre el encabezado de las columnas y abre Seleccionar columnas.
4. Añade las columnas de objetos GDI, objetos de usuario o USER, identificadores y tamaño de confirmación que estén disponibles.
5. Anota el nombre del proceso, su PID y los valores iniciales.

Los nombres pueden variar según el idioma y la versión. Los identificadores generales o handles son otra medición: no equivalen al número de objetos GDI ni al de objetos USER.

Después, reproduce la operación que parece causar el fallo: abrir y cerrar un panel, generar vistas previas o repetir una acción de dibujo. Comprueba si el recuento crece en cada ciclo y si llega a estabilizarse.

Un valor alto aislado no confirma una fuga. Resulta más significativo que la misma secuencia provoque incrementos continuos sin estabilización, especialmente si coincide con errores de la interfaz.

También puedes utilizar Process Explorer de Microsoft Sysinternals para ampliar la inspección de procesos e identificadores.

Reproduce el problema y compara antes y después

Una prueba controlada suele aportar más información que dejar el ordenador encendido sin registrar qué ocurre:

1. Abre la aplicación y espera a que termine su carga inicial.
2. Anota los contadores que estás siguiendo.
3. Repite la misma operación varias veces con un documento o proyecto comparable.
4. Cierra los paneles o documentos utilizados y observa la evolución.
5. Guarda el trabajo, cierra la aplicación desde su menú y repite la prueba en una sesión nueva.

Si cada repetición añade recursos y el comportamiento vuelve a empezar al abrir la aplicación, tendrás un indicio útil para investigar ese programa, sus complementos o las funciones que utiliza.

La liberación no siempre es inmediata: algunas aplicaciones conservan cachés y reutilizan recursos. Un crecimiento inicial que después se mantiene estable tiene una interpretación diferente de un aumento sostenido durante ciclos equivalentes.

Usa PerfMon para registrar la memoria a lo largo del tiempo

Abre Ejecutar con Windows + R, escribe perfmon y pulsa Intro. En el Monitor de rendimiento puedes añadir contadores para observar procesos concretos y el estado global de la memoria.

Estos nombres en inglés sirven como referencia; Windows puede mostrarlos traducidos:

Contador	Para qué sirve
Process\Private Bytes	Seguir la memoria privada comprometida de una aplicación.
Process\ID Process	Relacionar la instancia del contador con su PID.
Process\Handle Count	Observar el número de identificadores abiertos.
Memory\Pool Paged Bytes	Seguir el tamaño del pool paginado del kernel.
Memory\Pool Nonpaged Bytes	Seguir el tamaño del pool no paginado.
Memory\Available MBytes	Observar la memoria física disponible.

Selecciona las instancias de los procesos que quieres investigar. Comprueba el PID cuando existan varias instancias con el mismo nombre o reinicies la aplicación.

Para conservar una captura larga:

1. Expande Conjuntos de recopiladores de datos > Definidos por el usuario.
2. Crea un nuevo conjunto y selecciona la creación manual avanzada.
3. Elige crear registros de datos y marca Contador de rendimiento.
4. Añade los contadores y configura el intervalo de muestreo.
5. Selecciona la carpeta de destino y termina el asistente.
6. Inicia la recopilación antes de reproducir el problema y detenla al finalizar.

Adapta el intervalo a la velocidad del fallo. Un muestreo cada diez minutos puede servir para una evolución lenta, pero perder cambios que ocurren en segundos. Tampoco es obligatorio registrar 24 horas: captura el tiempo necesario para reproducir el comportamiento.

Interpreta los contadores sin confundir RAM y memoria del kernel

El crecimiento sostenido de Private Bytes puede orientar la investigación hacia una aplicación. Sin embargo, también puede reflejar trabajo pendiente, documentos más grandes o cachés. Compara cargas equivalentes antes de concluir que existe una fuga.

El aumento del pool paginado no identifica automáticamente una fuga en modo usuario. Tanto este como el pool no paginado pertenecen a los recursos del kernel, y sus totales no señalan por sí solos qué componente está acumulando memoria.

Si la tendencia apunta a uno de estos pools, PoolMon, incluido en el Windows Driver Kit, permite investigar las asignaciones por etiqueta. Es un paso de análisis más avanzado que puede ayudar a relacionar el crecimiento con un componente o controlador.

El porcentaje de uso del archivo de paginación aporta contexto, pero no identifica al responsable de una fuga ni sustituye las mediciones por proceso.

Comprueba la memoria de la GPU y descarta lecturas engañosas

En el Administrador de tareas, abre Rendimiento > GPU para consultar el consumo global. En Detalles puedes añadir las columnas de memoria GPU dedicada y compartida para observar los procesos.

En una gráfica dedicada, la memoria dedicada corresponde a su VRAM. La memoria compartida utiliza RAM del sistema. En las GPU integradas, parte de la memoria dedicada también puede proceder de una reserva de RAM.

Los recursos compartidos entre procesos pueden aparecer contabilizados en varios de ellos. Por eso, sumar todas las filas no equivale necesariamente al consumo físico total. Esto también afecta a la interpretación de procesos que comparten superficies con otras aplicaciones, como DWM.

Microsoft documenta además un problema de contadores en determinados sistemas Windows 10 que puede simular una fuga de memoria GPU por proceso. En los casos afectados, la pestaña Rendimiento y las herramientas WPR o WPA ofrecen la referencia recomendada.

Si tu duda se limita al compositor del escritorio, consulta el artículo específico sobre el consumo de VRAM de dwm.exe.

Qué puede hacer el atajo Windows + Ctrl + Mayús + B

Microsoft incluye Windows + Ctrl + Mayús + B entre las opciones de recuperación ante problemas de pantalla negra o parpadeo. Si funciona, puedes oír un pitido o ver un parpadeo; la pantalla no tiene que ponerse necesariamente blanca.

Úsalo como medida de recuperación de imagen. Que el escritorio vuelva a responder no confirma que hubiera una fuga ni demuestra que su origen haya quedado corregido.

Windows también dispone de mecanismos de recuperación ante bloqueos de la GPU. Si aparece un aviso de que el controlador dejó de responder y se recuperó, anota la hora y revisa los eventos relacionados. Ese aviso acredita una recuperación del subsistema gráfico, pero no identifica por sí solo una fuga de memoria.

Investiga la aplicación y el controlador implicados

Cuando el fallo se reproduce en un programa concreto, empieza por actualizarlo y revisar sus complementos. Si permite desactivar temporalmente la aceleración gráfica, compara el resultado con la misma operación.

Por ejemplo, Adobe propone en Photoshop desmarcar Edición > Preferencias > Rendimiento > Usar procesador gráfico, reiniciar la aplicación y comprobar el comportamiento. Una mejora dirige la investigación hacia la ruta gráfica, pero no distingue automáticamente entre un error de la aplicación, del controlador o del hardware.

Si el problema comenzó inmediatamente después de actualizar el controlador, revisa las incidencias conocidas y la posibilidad de volver a la versión anterior. Windows ofrece Administrador de dispositivos > Adaptadores de pantalla > Propiedades > Controlador > Revertir al controlador anterior cuando conserva una versión disponible.

Cambia un elemento cada vez y repite la prueba. Así podrás comprobar qué modificación afecta al crecimiento de recursos, en lugar de perder la referencia tras realizar varios cambios simultáneos.

Qué datos guardar para corregir el problema

Conserva el nombre y la versión de la aplicación, la compilación de Windows, el modelo de GPU, la versión del controlador y los pasos necesarios para reproducir el fallo. Añade los valores iniciales y finales o el registro de PerfMon.

Una descripción como «cada vez que abro y cierro este panel aumentan los objetos GDI del proceso y no se estabilizan» resulta más útil que indicar únicamente que Windows va lento.

Cerrar y volver a abrir la aplicación puede aliviar temporalmente el problema. La corrección duradera dependerá del componente responsable: una actualización del programa, un complemento corregido o un controlador que resuelva la incidencia identificada.