Cómo diagnosticar fallos de caché y HMB que provocan pérdida de datos en Windows

Inicio » Hardware » Cómo diagnosticar fallos de caché y HMB que provocan pérdida de datos en Windows

Cuando aparecen pérdidas de datos aparentemente inexplicables en Windows, uno de los sospechosos habituales son los problemas con la caché (tanto de archivos como de aplicaciones) y, en sistemas modernos, con el uso de memoria HMB (Host Memory Buffer) asociado sobre todo a SSD NVMe. Estos fallos no siempre se traducen en pantallazos azules: a menudo se manifiestan como ralentizaciones, cuelgues intermitentes o corrupción silenciosa de datos en disco, servidores de archivos lentos o aplicaciones que consumen memoria sin parar.

Para poder poner orden hace falta algo más que “limpiar la caché” o reiniciar. Es clave entender qué tipos de caché hay en Windows, cómo se gestionan y qué patrones indican un fallo real que pueda desembocar en pérdida de datos. A partir de ahí, se puede diagnosticar con contadores de rendimiento, herramientas como RAMMAP, WPR/WPA o VMMap y, sobre todo, con una buena dosis de método para no empeorar la situación al intentar recuperarla.

Qué es la caché en Windows y por qué influye en la pérdida de datos

En Windows, la caché no es una única cosa sino un conjunto de mecanismos que intentan acelerar el acceso a datos y reducir I/O en disco. Tenemos la caché de archivos del sistema, la memoria usada por SSD con HMB, cachés de aplicaciones (navegadores, servidores web, WordPress, etc.) y la propia estructura de memoria virtual y montones (heaps) de cada proceso.

Cuando todo va bien, esta caché hace que el sistema sea más ágil: los datos leídos o escritos recientemente se mantienen en memoria para que los siguientes accesos sean casi inmediatos. El problema llega cuando uno de estos niveles de caché crece sin control, se gestiona mal o interactúa con un hardware lento o defectuoso. En ese punto es cuando empiezan las condiciones de memoria baja, tiempos de espera remotos y corrupción de datos.

En equipos con SSD NVMe que usan HMB, una parte del rendimiento del disco depende de cómo el controlador utiliza la RAM del sistema para sus tablas internas. Un comportamiento anómalo (firmware defectuoso, controlador mal diseñado o carga muy agresiva) puede provocar que la memoria asignada desde HMB no se libere correctamente, sature la caché o eleve el consumo de memoria virtual y termine en errores de escritura o pérdida de datos.

En servidores de ficheros, otra fuente típica de problemas son las escrituras remotas intensivas: un cliente rápido volcándote gigas de datos a un almacenamiento lento puede forzar la caché del sistema hasta el límite, disparar las páginas desfasadas (dirty pages) y generar retrasos enormes o incluso tiempos de espera que se traducen en fallos de aplicaciones y corrupción de datos en el lado del cliente.

Contadores y herramientas clave para detectar fallos de caché

Antes de culpar a la caché o al HMB, conviene apoyarse en contadores de rendimiento y utilidades de análisis de memoria. En entornos Windows Server 2012 en adelante (y equivalentes de cliente) hay unos medidores y pasos bastante claros.

Para la caché de archivos del sistema, interesa vigilar sobre todo:

• Memory\Long-Term Average Standby Cache Lifetime (s): si suele estar por debajo de unos 1800 segundos (media a largo plazo), indica que las páginas en caché se reciclan demasiado rápido.
• Memory\Available (Mbytes/KBytes/Bytes): la memoria disponible real para el sistema; si cae muy bajo de forma sostenida, algo está acaparando RAM.
• Memory\System Cache Resident Bytes: tamaño real de la caché del sistema que reside en memoria física.

Cuando ves que Memory\Available está bajo al mismo tiempo que System Cache Resident Bytes se lleva una porción grande de la RAM física, es momento de acudir a RAMMAP. Esta herramienta de Sysinternals te permite ver con lupa qué está haciendo la caché de archivos: cuántas páginas del sistema son de metarchivos NTFS, cuántas de archivos mapeados, etc.

Si en RAMMAP observas una cantidad muy elevada de páginas activas de metarchivo, es posible que estés ante el comportamiento clásico de servidores llenos de millones de archivos donde el metarchivo NTFS (MFT y asociados) se queda “clavado” en caché. En versiones anteriores a Windows Server 2012 esto era relativamente habitual y se solía mitigar con herramientas como DynCache. A partir de 2012, Microsoft rediseñó la arquitectura de gestión de caché para reducir al mínimo este problema.

Otra situación es que la caché de archivos del sistema esté plagada de páginas activas de archivos mapeados. En RAMMAP esto suele indicar que alguna aplicación está abriendo muchos ficheros grandes con la API CreateFile usando la marca FILE_FLAG_RANDOM_ACCESS. Esta bandera le dice al administrador de caché que mantenga las vistas mapeadas del archivo en memoria el máximo tiempo posible y, además, que desactive la lectura anticipada (prefetch). El resultado puede ser un sobredimensionamiento brutal de la caché del sistema.

Caché de archivos, FILE_FLAG_RANDOM_ACCESS y su impacto real

La combinación de archivos enormes y accesos genuinamente aleatorios es especialmente peligrosa si la aplicación abusa de FILE_FLAG_RANDOM_ACCESS. Aunque en teoría es una pista para optimizar, en la práctica puede impedir que la caché se recorte con normalidad y comerse la RAM del sistema, dejando sin memoria a otros procesos y disparando la paginación.

En Windows Server 2012 y versiones posteriores se introdujeron mejoras importantes en el recorte de espacios de trabajo, lo que alivia parcialmente el problema. Aun así, Microsoft recomienda con bastante claridad que los proveedores de aplicaciones eviten usar FILE_FLAG_RANDOM_ACCESS salvo que sea estrictamente necesario y que, si lo hacen, adopten estrategias adicionales.

Una alternativa es configurar una prioridad de memoria baja en los hilos que acceden a los archivos mediante la API SetThreadInformation. Las páginas a las que se accede con prioridad de memoria baja se eliminan de los espacios de trabajo de forma mucho más agresiva, reduciendo el riesgo de que un único proceso ahogue la memoria disponible del sistema.

Desde Windows Server 2016, el administrador de caché va todavía un paso más allá: ignora la marca FILE_FLAG_RANDOM_ACCESS a la hora de decidir qué recortar, tratándola como cualquier otro archivo en términos de trimming (aunque sigue respetando la desactivación de la lectura anticipada). Eso no significa que desaparezca el problema; si tienes un montón de archivos abiertos con esa marca y el patrón de acceso es realmente aleatorio, la caché del sistema puede seguir inflándose más de lo sano.

Por todo esto, para diagnósticos serios de pérdida de datos o ralentizaciones ligadas a la caché, es fundamental revisar con el proveedor de la aplicación cómo están abriendo los archivos, qué flags usan y qué tamaño de conjuntos de trabajo manejan. A veces el origen de un “misterioso” fallo de caché está en una simple opción mal elegida en una librería de acceso a disco.

Escrituras remotas, páginas desfasadas y tiempos de espera

En servidores de ficheros que reciben datos de clientes remotos rápidos (por ejemplo, copias de seguridad o flujos masivos de datos) hacia un almacenamiento relativamente lento, aparece otro bicho: el umbral de páginas desfasadas de archivos remotos. Aquí el problema ya no es tanto la lectura, sino la cantidad de datos pendientes de escribir en disco que se van acumulando en la caché.

En versiones anteriores a Windows Server 2016, cuando se alcanzaba el umbral de dirty pages en caché durante una oleada de escrituras remotas, el sistema trataba las escrituras subsiguientes como si fueran simultáneas y desencadenaba un vaciado masivo al disco. Si el almacenamiento era lento, las colas de escritura se disparaban, aparecían grandes latencias y los clientes podían sufrir tiempos de espera en las conexiones, lo que se traduce fácilmente en errores de copia o ficheros corruptos.

Desde Windows Server 2016, la cosa se ha afinado: existe un umbral independiente de páginas desfasadas para las escrituras remotas y se aplica un vaciado en línea cuando ese umbral se supera. Esto no elimina por completo las ralentizaciones durante picos de escritura intensiva, pero sí reduce muchísimo la probabilidad de alcanzar tiempos de espera fatales.

Por defecto, el umbral remoto se fija en 5 GB de páginas sucias por archivo. Dependiendo de la carga de trabajo y del hardware de almacenamiento, este valor puede ser demasiado conservador o demasiado generoso. Microsoft recomienda ajustar el límite en incrementos de 256 MB hasta encontrar el punto en el que el rendimiento sea aceptable sin generar timeouts constantes.

El valor se controla mediante el Registro en la clave HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, nombre de valor RemoteFileDirtyPageThreshold (tipo DWORD). El dato debe expresarse como número de páginas (bytes deseados / 4096). Lo conveniente, según la documentación, es mantenerlo entre 128 MB y el 50 % de la memoria disponible. Es posible deshabilitarlo poniendo -1, pero eso se considera una mala idea porque aumenta notablemente el riesgo de tiempos de espera en conexiones remotas.

Fallos de caché a nivel de aplicación: el caso de WordPress

Más allá del sistema operativo, muchas pérdidas de rendimiento y errores que acaban afectando a los datos proceden de cachés mal configuradas en aplicaciones web. Un caso típico son los sitios WordPress con plugins de caché mal ajustados o con políticas de purgado agresivas.

En este contexto, un “fallo de caché” significa que los datos solicitados no se encuentran en la memoria caché, de modo que el servidor tiene que ir a la base de datos o al backend de disco en cada petición. Se contrapone al “acierto de caché”, donde la información se sirve directamente desde memoria o desde una versión estática precalculada.

Las causas de estos fallos son variadas: datos que nunca se han almacenado en la caché, entradas que se han expulsado por falta de espacio, purgados completos demasiado frecuentes, caducidad (TTL) muy corta o plugins que borran y regeneran la caché de forma poco eficiente. Cada vez que ello pasa, se incrementa la latencia de la respuesta y se multiplica la carga sobre el servidor y el almacenamiento.

Durante una pérdida de caché, el sistema intenta localizar los datos comenzando por los niveles más rápidos (L1, L2, etc.). Si no encuentra nada, recurre al origen de verdad (base de datos o disco), copia los datos y los vuelve a meter en caché. Este recorrido genera una penalización por fallo que se hace muy evidente cuando la tasa de fallos de caché es alta.

Para reducir estos problemas, una estrategia razonable es alargar la vida útil de las entradas de caché (TTL) siempre que el contenido no cambie con demasiada frecuencia. Por ejemplo, en un WordPress poco dinámico podría tener sentido un TTL de varios días o semanas, mientras que en un sitio con cambios diarios conviene un tiempo de expiración más corto, de uno o dos días.

Buenas prácticas de configuración de caché y RAM

A la hora de diseñar o corregir un sistema, hay varias palancas que ayudan a minimizar los fallos de caché y, por extensión, a reducir el riesgo de corrupción o pérdida de datos por saturación:

Por un lado, está el tamaño de la caché y de la memoria física (RAM). Una caché ridícula obliga a expulsar entradas continuamente, provoca fallos constantes y castiga el almacenamiento. Aumentar la RAM o el tamaño asignado a la caché puede ser caro, pero en muchos casos es la forma más directa de estabilizar un entorno sometido a mucha carga de I/O.

Por otro lado, influyen mucho las políticas de reemplazo de caché. Aunque el sistema operativo tiene sus propios algoritmos, a nivel de aplicación se pueden implementar estrategias como FIFO (First In First Out), LIFO (Last In First Out), LRU (Least Recently Used) o MRU (Most Recently Used). Según el patrón de acceso a los datos, una u otra política puede ofrecer una tasa de aciertos mucho mayor sin necesidad de aumentar memoria.

En entornos gestionados, como algunos hostings especializados, es habitual combinar estas políticas con mecanismos avanzados que purgan sólo ciertas partes de la caché cuando hay cambios (por ejemplo, purga selectiva de páginas modificadas en lugar de limpiar todo el sitio). Esta aproximación limita drásticamente el número de fallos posteriores a un despliegue o actualización.

Conviene también evitar prácticas como vaciar manualmente toda la caché a la mínima duda o sobrerreaccionar a pequeños retrasos detonando borrados completos. La experiencia demuestra que lanzar purgas masivas aumenta diametralmente la probabilidad de fallos de caché en los minutos siguientes y, por tanto, el estrés sobre discos y bases de datos.

Diagnóstico de pérdidas de memoria relacionadas con la caché

Otro frente importante son las pérdidas de memoria (memory leaks) en procesos de Windows que consumen caché de forma indirecta. Cuando un servicio o aplicación empieza a reservar memoria sin liberarla correctamente, puede disparar el uso de memoria virtual y desencadenar una condición de agotamiento de recursos que acaba afectando tanto a la caché como al rendimiento general del sistema.

En estos casos, Windows suele registrar eventos con identificador 2004 en el registro del sistema, procedentes de Microsoft-Windows-Resource-Exhaustion-Detector. En la descripción del evento aparecen los procesos que en ese momento están consumiendo más memoria virtual (por ejemplo, wpa.exe, msedgewebview2.exe, EngHost.exe, etc.).

No basta con mirar la columna de memoria “de siempre” en el Administrador de tareas, porque esa mide sobre todo la memoria privada respaldada por RAM física (conjunto de trabajo). Lo que importa aquí es el tamaño de confirmación (commit size), que refleja la memoria virtual que el sistema tiene comprometida, ya sea respaldada por RAM o por el archivo de paginación.

Para un análisis profundo se puede recurrir a herramientas como VMMap y Windows Performance Toolkit (WPR/WPA). VMMap ayuda a clasificar el tipo de memoria (datos privados, heaps, imágenes, etc.) y a detectar si el crecimiento viene de asignaciones virtuales directas o del montón. WPR y WPA permiten capturar y diseccionar trazas de asignación de memoria a lo largo del tiempo para ver qué módulos y funciones están detrás de la fuga.

Cuando la pérdida procede de asignaciones virtuales, VMMap lo muestra como “Private Data”. En un volcado de memoria, el comando !address -summary de WinDbg etiquetará gran parte de esa memoria como <unknown>. Si, por el contrario, el problema reside en el montón (heap), VMMap marcará los bloques correspondientes como “Heap” y en WinDbg aparecerán bajo esa categoría en el resumen de dirección.

Recopilación de trazas con WPR para aislar el problema

Una vez que tienes claro qué proceso está fugando memoria y si la pérdida es de asignación virtual o de heap, el siguiente paso es recoger datos reproducibles con Windows Performance Recorder (WPR) para poder analizarlos en WPA.

Para pérdidas ligadas a asignaciones virtuales basta con arrancar un rastreo con privilegios de administrador usando:

wpr -start VirtualAllocation — ejecuta desde un símbolo de sistema con permisos elevados

Después se deja que la aplicación funcione durante un tiempo, vigilando cómo se incrementa el tamaño de confirmación en el Administrador de tareas. El archivo de seguimiento no suele crecer en exceso si sólo se rastrea VirtualAllocation, así que puedes permitir que corra algunos minutos. Cuando veas que se ha acumulado suficiente memoria perdida, detienes el rastreo con:

wpr -stop virtalloc.etl — guarda el archivo ETL resultante

Para pérdidas en el heap, el procedimiento es similar pero requiere un paso adicional en el Registro: hay que activar el heap tracing para el ejecutable afectado. Se puede hacer a mano o ejecutando algo como:

wpr -heaptracingconfig NombreProceso.exe enable — añade la configuración de tracing para ese proceso

Esto crea una clave en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\NombreProceso.exe con el valor DWORD Tracing Flags = 1.

Una vez habilitado, se lanza el rastreo con:

wpr -start Heap — inicia la captura de asignaciones de heap

Se deja correr mientras el proceso muestra el patrón de fuga y luego se detiene con:

wpr -stop Heap.etl — conserva el ETL para análisis

Es importante recordar eliminar después la clave del Registro o poner el valor a 0 para no dejar el heap tracing activo permanentemente, ya que podría impactar en el rendimiento normal del proceso.

Análisis en WPA: encontrando el módulo culpable

Con las trazas ETL en la mano, toca abrirlas con Windows Performance Analyzer (WPA), que forma parte del Windows Performance Toolkit incluido en el ADK. Para que los datos sean legibles conviene configurar bien las rutas de símbolos (por ejemplo, con srv*C:\LocalPubSymbols*https://msdl.microsoft.com/download/symbols) y cargar los símbolos antes de empezar a explorar.

En el caso de las asignaciones virtuales, la vista interesante es la de Virtual Allocations filtrada por el proceso en cuestión. Hay que asegurarse de que la columna “Commit Stack” quede antes de la línea dorada en el panel. Al expandir las pilas de llamadas verás la función desde la que se realizan las asignaciones; el módulo que aparece justo por encima suele ser el responsable de esa reserva de memoria.

Para las pérdidas en el heap, se utiliza la vista correspondiente, añadiendo las columnas “Handle” y “Stack” a la izquierda de la línea dorada. De nuevo, al profundizar en la pila de llamadas, se identifica la función que realiza las asignaciones de heap y el módulo (DLL, EXE o controlador) que está originando la fuga.

En procesos de Microsoft puedes aprovechar el almacén de símbolos público para ver nombres de funciones reales; en procesos de terceros es posible que sólo identifiques el módulo, pero eso ya es suficiente para trasladar el problema al proveedor con datos bastante precisos.

Factores externos que también llevan a pérdida de datos

Más allá de la caché y la memoria, las estadísticas de recuperación de datos muestran que muchos incidentes graves se deben a fallos físicos de hardware, errores humanos y malware. Entender estas causas ayuda a contextualizar cuándo tiene sentido buscar culpables en la caché y cuándo el origen es otro.

Los fallos de hardware (especialmente en HDD, SSD, RAM, placa base, CPU o fuente de alimentación) representan un porcentaje altísimo de los casos de pérdida de datos. Un disco que empieza a fallar puede provocar lecturas incoherentes que la caché reusa creyendo que son correctas, y eso dispara la corrupción. Ante signos de fallo de disco, lo razonable es detener el uso, no desmontar nada por tu cuenta salvo que seas especialista, y acudir a un servicio profesional.

En segundo lugar tenemos el error humano: borrados accidentales, formateos de la partición equivocada, sobrescrituras de ficheros o intentos de “reparación” con herramientas no adecuadas (como un CHKDSK lanzado a lo loco). Estas acciones pueden convertir una incidencia relativamente menor en una pérdida irreversible, especialmente si provocan sobrescritura de áreas donde estaban los datos.

Los fallos de software (aplicaciones de copia de seguridad que fallan, editores que corrompen ficheros al guardar, antivirus que borran archivos buenos o convertidores que se rompen a mitad de proceso) añaden otra capa de riesgo. Junto con los virus y ransomware, que pueden cifrar o destruir datos de forma masiva, completan el panorama de amenazas que pueden interactuar muy mal con una caché ya tensionada.

Por último, hay que considerar el robo de dispositivos o de datos y los desastres naturales (inundaciones, incendios, terremotos…). Aunque su frecuencia es menor, cuando ocurren suelen tener un impacto devastador y dejan claro por qué es tan crítico contar con copias de seguridad externas y sistemas de protección adecuados.

Diagnosticar fallos de caché y problemas relacionados con HMB que acaban en pérdida de datos en Windows exige mirar el sistema desde varios ángulos: contadores de memoria, patrón de uso de la caché, comportamiento de aplicaciones, salud del hardware y acciones previas realizadas sobre los datos. Sólo así puedes separar lo que es un simple fallo de rendimiento de un escenario real de riesgo para la integridad de la información y aplicar las herramientas correctas (RAMMAP, VMMap, WPR/WPA, ajustes de Registro, cambios en la configuración de caché y políticas de acceso) sin aumentar el daño.