Introducción
Un equipo de soporte de una pyme en Buenos Aires detectó que las copias automáticas de los perfiles de usuario hacia un NAS no se ejecutaban desde hacía seis días. Al revisar el Event Viewer, encontraron crashes recurrentes de FileHistory.exe y KERNELBASE.dll que coincidían exactamente con la fecha de instalación del parche de seguridad de septiembre 2026. No era un problema de hardware ni de conectividad VPN hacia el almacenamiento de red: era un bug introducido por Microsoft en su propio update mensual. El escenario se repite en organizaciones que dependen de File History como capa mínima de protección contra borrado accidental o ransomware de bajo nivel, y que ahora enfrentan una ventana de exposición donde los respaldos más recientes simplemente no existen.
Qué ocurrió
Microsoft publicó un service alert el sábado confirmando que los updates de seguridad de septiembre 2026 provocaban que File History dejara de crear o actualizar respaldos hacia unidades externas y ubicaciones de red. El fallo se manifiesta con crashes de FileHistory.exe registrados en Event Viewer, acompañados de referencias a KERNELBASE.dll. En los sistemas afectados, el usuario ve una alerta persistente de «Reconnect your drive» aunque la unidad USB o el volumen NAS estén correctamente montados y accesibles. Archivos que previamente tenían versiones previas muestran el mensaje «No previous version available» y el timestamp de «Last Backup» deja de actualizarse.
Las versiones impactadas incluyen Windows 10 21H2 o superior, Windows 10 Enterprise LTSC 2016 y 2019, y Windows 11 23H2 o superior. Microsoft liberó la corrección el martes como parte de las actualizaciones acumulativas opcionales KB5124006 para Windows 11 26H1 y KB5124010 para Windows 11 24H2 y 25H2. Para quienes prefieren esperar, el fix se incorpora al Patch Tuesday del 13 de octubre. No obstante, esta no es la única regresión del ciclo de septiembre: Microsoft también publicó updates out-of-band para resolver fallos en Hyper-V, Remote Desktop Services, audio USB y un bug que impedía el inicio de sesión con credenciales de dominio válidas en Windows 11.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de infraestructura que gestionan flotas de estaciones de trabajo Windows, este bug genera un problema operativo silencioso: la política de respaldo aparenta funcionar porque el servicio está activo, pero los datos más recientes no llegan al destino. En entornos donde File History complementa una estrategia de backup centralizada hacia servicios cloud o NAS sobre VPN, la degradación pasa inadvertida hasta que alguien intenta una recuperación. Si la última versión disponible en el respaldo tiene semanas de antigüedad, el RPO (Recovery Point Objective) prometido en el SLA interno queda incumplido sin que exista un evento de fallo explícito en los dashboards de monitoreo.
El componente KERNELBASE.dll involucrado en los crashes es parte del núcleo del sistema operativo Windows y gestiona funciones base de manejo de memoria y excepciones. Un fallo en esta capa puede extenderse a otros procesos que dependan de la misma ruta de código, aunque en este caso el impacto se circunscribe al servicio de File History. Para organizaciones que operan cargas de trabajo en AKS (Azure Kubernetes Service) o EKS (Amazon Elastic Kubernetes Service) con agentes de respaldo que se comunican con endpoints Windows vía VPN o ExpressRoute, la interrupción del respaldo local no afecta directamente la orquestación en cloud, pero sí elimina la capa de protección ante borrado accidental de volúmenes persistentes mapeados desde estaciones de trabajo.
Detalles técnicos
El vector del fallo reside en la interacción entre las modificaciones introducidas en los parches de seguridad de septiembre y el mecanismo de enumeración de dispositivos de almacenamiento extraíble y de red que utiliza FileHistory.exe. Cuando el servicio intenta resolver la ruta del destino de respaldo —ya sea una unidad USB montada o un share SMB accesible a través de una VPN—, la llamada a KERNELBASE.dll que valida la disponibilidad del volumen devuelve un estado inconsistente, provocando que el proceso aborte con una excepción no controlada.
Los eventos de crash en Event Viewer se registran bajo la fuente Application Error con el siguiente patrón observable:
Faulting application name: FileHistory.exe
Faulting module name: KERNELBASE.dll
Exception code: 0xc0000006 (IN_PAGE_ERROR)
Fault offset: 0x0000000000034b90
El código 0xc0000006 indica que el proceso intentó leer una página de memoria respaldada en disco que ya no estaba disponible, lo que sugiere que la ruta del destino de respaldo se resolvió como válida durante la fase de init pero se invalidó antes de la escritura efectiva. Microsoft corrigió la lógica de validación del volumen en las builds incluidas en KB5124006 y KB5124010. Las versiones de Windows 10 afectadas (21H2, LTSC 2016, LTSC 2019) reciben el fix directamente en el ciclo de Patch Tuesday del 13 de octubre, sin actualización opcional anticipada.
Qué deberían hacer los administradores y equipos técnicos
Primero, verificar la integridad real de los respaldos. No confiar en que el indicador «Last Backup» en el panel de Control Panel > System and Security > File History sea fidedigno. Ejecutar en cada estación afectada:
# Verificar timestamp real del último respaldo en el destino
Get-ChildItem «\\backup-server\filehistory\$env:USERNAME» -Recurse |
Sort-Object LastWriteTime -Descending |
Select-Object -First 5 FullName, LastWriteTime
Si el LastWriteTime más reciente es anterior al 9 de septiembre de 2026, el respaldo está roto.
Segundo, aplicar la corrección. En Windows 11 24H2/25H2, instalar KB5124010; en Windows 11 26H1, instalar KB5124006. Desde un servidor WSUS o SCCM, aprobar estas actualizaciones acumulativas opcionales y forzar el escaneo:
# Desde el cliente, forzar búsqueda de updates opcionales
usoclient StartInteractiveScan
En Windows 10, esperar al 13 de octubre o aplicar el workaround temporal: desactivar y reactivar File History desde el panel de control, o reiniciar el servicio fhsvc con Restart-Service fhsvc -Force.
Tercero, validar la conectividad del destino. Si el NAS o la unidad de red se accede vía VPN, confirmar que el túnel no interfiere con la resolución SMB:
# Verificar que el share es accesible sin intervención de File History
net use \\nas-01\backups /persistent:yes
dir \\nas-01\backups\%USERNAME%
Cuarto, revisar las otras regresiones de septiembre. Verificar que Hyper-V no presenta fallos en las VMs de desarrollo, que RDS funciona correctamente en los servidores de terminal y que las credenciales de dominio permiten el login en Windows 11. Microsoft publicó updates out-of-band específicos para cada uno de estos problemas.
Conclusión
Este incidente ilustra una vulnerabilidad operativa que trasciende el bug puntual: la dependencia de un mecanismo de respaldo que no emite alertas cuando deja de funcionar. Los equipos de infraestructura deben tratar la verificación de integridad de respaldos como una tarea programada con verificación activa, no como una configuración que se establece una vez y se olvida. La corrección de Microsoft llega como update opcional, pero la ventana de exposición para quienes no la apliquen hasta el 13 de octubre es de casi tres semanas sin copias actualizadas. En un contexto donde el ransomware y el borrado accidental siguen siendo amenazas cotidianas, tres semanas de brecha en el RPO no es un detalle menor.
Fuentes
- https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-windows-backup-feature-broken-by-september-updates/