¿Tu PC no arranca? Microsoft confirma fallo en Windows 11

Microsoft confirma que KB5074109 en Windows 11 puede dejar el PC sin arrancar; con error UNMOUNTABLE_BOOT_VOLUME y parches OOB de enero 2026.

Microsoft ha confirmado que la actualización de seguridad de Windows 11 del 13 de enero de 2026 puede provocar, en algunos equipos, el peor escenario posible para un sistema operativo: que el PC no arranque. El síntoma que se está repitiendo es muy concreto y muy desagradable, por lo simple: pantalla negra, reinicios, y en determinados casos el temido UNMOUNTABLE_BOOT_VOLUME, un código que suena a latín de hospital y que, traducido al mundo real, significa que Windows no logra acceder al volumen desde el que debe iniciarse. La actualización señalada es la KB5074109, distribuida para Windows 11 24H2 y 25H2, asociada a las compilaciones 26100.7623 y 26200.7623.

Cuando ocurre, no hay margen para “arreglarlo desde dentro”, porque no hay dentro: el escritorio no llega. En los casos descritos, la salida más habitual está siendo entrar en el Entorno de Recuperación de Windows (WinRE) y desinstalar la actualización para recuperar el arranque. Y todo esto se suma a una cadena poco fina de incidencias en el Patch Tuesday de enero, con parches fuera de banda incluidos y un clima raro: el de un mes que empezó con prisa, siguió con remiendos, y ha terminado con algunos equipos literalmente fuera de juego.

El parche del 13 de enero que ha encendido las alarmas

La historia empieza con un gesto rutinario. Patch Tuesday, segundo martes del mes, Windows Update haciendo de mayordomo silencioso, reinicio a una hora mala… y, para la mayoría, vida normal. Pero en enero de 2026, ese guion se ha torcido varias veces y en distintos frentes. La actualización de seguridad del 13 de enero para Windows 11, identificada como KB5074109, se instaló como un paquete acumulativo: no es un parche “pequeño”, sino un bloque que concentra correcciones de seguridad y ajustes de calidad. En Windows 11 24H2 y Windows 11 25H2, ese bloque empuja el sistema a las compilaciones 26100.7623 y 26200.7623.

Hasta ahí, manual de instrucciones del mundo moderno. Lo que ha obligado a levantar la ceja es lo que Microsoft ha reconocido después: que hay informes de equipos que, tras instalar esa actualización, se quedan sin arranque. No hablamos de un fallo cosmético ni de un menú que parpadea; hablamos de un PC que se convierte en un pisapapeles caro hasta que se interviene con herramientas de recuperación. En paralelo, el debate ha saltado a foros y comunidades técnicas, con Hacker News como uno de los termómetros más ruidosos: no aporta “pruebas” por sí mismo, pero sí deja una sensación clara, casi física, de hartazgo cuando un fallo te rompe el día sin pedir permiso.

Cuando el PC no pasa del logo: el error UNMOUNTABLE_BOOT_VOLUME

El código UNMOUNTABLE_BOOT_VOLUME tiene nombre de villano, pero apunta a un momento muy concreto del arranque. Windows necesita acceder al disco —o al SSD— donde vive el sistema, leer los elementos mínimos, cargar controladores críticos, levantar servicios esenciales, y entonces sí, ya llegará la pantalla de inicio. Si en ese tramo inicial el sistema no puede “montar” el volumen de arranque, se produce la caída. La máquina puede entrar en bucle de reinicios o mostrar la pantalla de error; a veces, ni eso, solo negro y silencio con ventiladores girando como si nada.

Es importante no mezclar conceptos: este mensaje también puede aparecer en situaciones clásicas, como corrupción del sistema de archivos, problemas con el disco o cambios delicados en la configuración de arranque. Lo llamativo aquí es la correlación temporal y el reconocimiento de Microsoft de que, tras la instalación de KB5074109, el fallo aparece en ciertos equipos. Y lo que de verdad lo vuelve serio es que rompe el pacto básico entre usuario y sistema operativo: “yo actualizo, tú arrancas”.

Qué equipos están en el foco: 24H2 y 25H2, con número y apellidos

Los reportes que han ido tomando forma señalan de manera recurrente a Windows 11 24H2 y Windows 11 25H2. En esos sistemas, la actualización de enero se identifica como KB5074109, y el salto de compilación queda fijado en 26100.7623 para 24H2 y 26200.7623 para 25H2. Esto no es un detalle de frikis: es la forma más fiable de saber si un equipo está en la “foto” del problema sin depender de percepciones. La historia, tal como se está contando, no es “Windows 11 en general”, sino este tramo concreto del calendario y estas versiones concretas.

También hay un matiz que Microsoft ha deslizado en comunicaciones sobre problemas similares: en algunos incidentes previos, el origen real no estaba en el parche, sino en una combinación mala con firmware o BIOS desactualizados, especialmente versiones tempranas. Dicho con una imagen sencilla: a veces el parche es la chispa, pero la gasolina ya estaba en el garaje.

El susto no viene solo: por qué enero huele a taller mecánico

Si este fuera un caso aislado, el relato sería más simple. El problema es que enero ha sido un mes de varias averías a la vez, y eso altera el contexto. Antes de que se hablara del arranque roto, Microsoft ya había tenido que lidiar con incidencias derivadas del mismo Patch Tuesday: fallos de inicio de sesión en conexiones remotas, comportamientos raros al apagar o hibernar en ciertos equipos, y aplicaciones que se quedaban colgadas al trabajar con archivos en almacenamiento “respaldado por la nube”. Con ese paisaje, el bug de arranque no se interpreta como un rayo en cielo despejado, sino como otra grieta en una pared que ya tenía marcas.

La semana de los parches fuera de banda: 17 y 24 de enero

En este enero, Microsoft no se quedó solo en el parche del 13. Hubo, como mínimo, dos momentos clave de reacción con actualizaciones fuera de banda, esas que no esperan al siguiente martes porque el problema es demasiado molesto —o demasiado visible— como para aguantar.

El 17 de enero de 2026 llegó la KB5077744 para Windows 11 24H2 y 25H2, elevando el sistema a las compilaciones 26100.7627 y 26200.7627. El objetivo principal era corregir fallos de autenticación en Remote Desktop, que afectaban a distintos clientes y, en particular, a la Windows App, muy usada en entornos donde se trabaja contra escritorios remotos, servicios gestionados o infraestructuras tipo Azure Virtual Desktop y Windows 365. En paralelo, para Windows 11 23H2, Microsoft publicó KB5077797 (compilación 22631.6494) con un arreglo añadido que sonaba casi surrealista: en dispositivos con Secure Launch activado, algunas máquinas reiniciaban en lugar de apagarse o entrar en hibernación. Apagar y que el PC te conteste “no” con un reinicio automático: así de literal.

La segunda fecha es el 24 de enero de 2026, con otro movimiento de emergencia. Para 24H2 y 25H2, Microsoft lanzó KB5078127, que sube a 26100.7628 y 26200.7628 y que, además de acumular lo anterior, buscaba apagar un incendio especialmente antipático: aplicaciones que se quedaban bloqueadas o mostraban errores al abrir o guardar archivos en almacenamiento en la nube como OneDrive o Dropbox. En determinadas configuraciones, Outlook se convertía en protagonista involuntario cuando los archivos PST estaban ubicados en OneDrive: podía quedarse colgado y no volver a abrir bien sin forzar el cierre del proceso o reiniciar el sistema. Para Windows 11 23H2, el equivalente llegó como KB5078132 (compilación 22631.6495), con el mismo tipo de correcciones alrededor de archivos en nube y cuelgues.

Lo importante, lo que se repite en las coberturas técnicas, es que estos parches fuera de banda están pensados para arreglar problemas concretos del ciclo de enero, pero no parecen resolver el caso del arranque roto asociado a KB5074109. Es la paradoja de las semanas con demasiados incendios: apagas uno y aparece otro, y no siempre es el mismo.

Remote Desktop, Windows App y el trabajo que se corta en seco

El fallo de Remote Desktop tiene su propio peso porque afecta a una parte del mercado que no suele hacer ruido en redes sociales, pero sí mueve empresas enteras: trabajadores que entran a su escritorio remoto cada mañana, administradores que gestionan equipos dispersos, gente que depende de una sesión remota para operar. Que falle la autenticación en un cliente como la Windows App no es solo “no me entra”; es un atasco en la puerta principal. Y en enero, ese atasco existió, se reconoció y se corrigió con una OOB.

Este contexto es clave para entender por qué el problema del arranque se ha leído con tanta ansiedad. Cuando ya vienes de un mes en el que apagar no apagaba, y conectarte en remoto no conectaba, que de pronto algunos equipos ni arranquen suena a escalada. No necesariamente lo es en número, pero sí en percepción: lo que antes era molestia se convierte en pérdida total de acceso.

El lío de OneDrive, Dropbox y Outlook: la nube como punto débil

El otro bloque de incidencias de enero tiene un patrón moderno, de oficina híbrida: guardar en la nube, abrir desde la nube, trabajar en la nube, y que eso se convierta en el talón de Aquiles. Microsoft reconoció que, tras la actualización del 13 de enero y las correcciones posteriores, algunas aplicaciones podían quedar sin respuesta o mostrar errores al abrir o guardar archivos en almacenamiento cloud. OneDrive y Dropbox aparecen como ejemplos claros, pero el fenómeno es más amplio: cualquier flujo en el que una aplicación intente leer o escribir en ubicaciones “cloud-backed” puede quedar afectado.

En Outlook, el problema tomaba una forma especialmente irritante si se usaban ciertos esquemas de almacenamiento con archivos PST en OneDrive. No es la configuración más recomendable para muchos administradores, pero existe, y cuando existe y falla, duele. Outlook podía quedarse colgado y no recuperarse sin intervención, y en algunos casos se describieron fenómenos extraños como elementos enviados que “desaparecen” momentáneamente o correos que vuelven a descargarse. Es el tipo de fallo que, aunque no destruya datos, genera pánico, porque toca correo, y el correo es casi siempre un sistema nervioso.

Qué significa “no arranca” en 2026: entre UEFI, drivers y ese disco que no ves

Un PC que no arranca es una experiencia bastante primaria, casi infantil: botón, logo, nada. Pero por debajo hay una secuencia compleja donde conviven piezas que rara vez miras: UEFI, el gestor de arranque, controladores de almacenamiento, políticas de seguridad, cifrado, firmware del SSD, y una colección de decisiones tomadas por fabricantes y por Microsoft durante años.

Cuando aparece UNMOUNTABLE_BOOT_VOLUME, la sospecha técnica se mueve alrededor del acceso al disco y al sistema de archivos en un momento muy temprano. Puede ser una interacción con un controlador de almacenamiento, un cambio en cómo se inicializa cierto hardware, una incompatibilidad rara con firmware, o una combinación que solo se manifiesta en máquinas concretas. Por eso cuesta tanto señalar un “culpable único” sin datos de telemetría y sin reproducibilidad clara. Y por eso, también, la respuesta inmediata suele ser pragmática: revertir el cambio que introdujo el fallo, es decir, desinstalar el parche.

Aquí entra una palabra que aparece siempre, como el “ojo” del radar: firmware. No es un término bonito, pero es decisivo. El firmware es la capa de software que vive pegada al hardware, una especie de manual interno del SSD, de la placa, del controlador, que decide cómo se comporta la pieza en situaciones críticas. Si el firmware tiene un bug o una interpretación diferente de algo que Windows espera, el choque puede aparecer justo al arrancar. Y en incidentes anteriores, Microsoft ha sugerido que algunos problemas que parecían “culpa del parche” terminaron siendo culpa de firmware/BIOS antiguos que no se llevaban bien con cambios recientes.

También hay otra palabra que, cuando aparece en mitad de una recuperación, impone respeto: BitLocker. El cifrado es una gran idea hasta el día en que el sistema no arranca y te pide una clave de recuperación en un entorno de emergencia. No es un error: es seguridad funcionando. Pero en mitad del caos, puede sentirse como un candado extra. Por eso, en incidentes de arranque, BitLocker no causa el problema por sí mismo en la mayoría de escenarios, pero sí puede complicar el camino de vuelta si no se tiene la clave disponible o si la organización no tiene bien gestionada esa parte.

El bucle de reinicios: cuando la reparación automática se convierte en pasillo

Hay equipos que, tras varios arranques fallidos, entran en la Reparación automática y ofrecen acceso a opciones avanzadas. Otros no llegan ni ahí y obligan a forzar el proceso, apagando durante el inicio para “convencer” al sistema de que algo va mal. Es una escena muy común ya: el equipo intenta arrancar, falla, intenta otra vez, y al final aparece ese menú sobrio, casi de hospital, donde todo es texto y opciones con nombres poco amigables.

Ese entorno es WinRE, y es el lugar al que están yendo muchos casos para deshacer la instalación de la actualización problemática. No es glamuroso, pero es efectivo cuando lo es. En la práctica, se trata de localizar las opciones de recuperación, entrar en el apartado de desinstalar actualizaciones, y eliminar la última actualización de calidad, que en este contexto suele corresponder a la acumulativa de enero. La clave es que el sistema vuelva a una versión inmediatamente anterior del estado de arranque, la última que funcionaba.

Si hay algo que define este tipo de incidentes es lo poco que perdonan los detalles. A veces el equipo arranca tras la desinstalación como si nada hubiera pasado. Otras veces, la vuelta es más lenta, con reinicios adicionales, comprobaciones automáticas del disco, o la necesidad de revisar el orden de arranque en UEFI si se ha usado un medio externo. En esa incertidumbre vive la noticia: no es un fallo “bonito”, es un fallo áspero.

La respuesta de Microsoft y el margen real de quienes lo sufren

Microsoft ha reconocido la existencia del problema y está investigándolo. En la información que se ha movido en medios especializados, la compañía ha hablado de un número limitado de informes. Esa frase, “limitado”, es cómoda y desesperante a la vez: significa que no es un apagón global, pero también significa que no hay una lista clara que permita decir “esto te va a pasar” o “esto no te va a pasar”. Lo que sí existe es un patrón: instalación de KB5074109 en Windows 11 24H2/25H2, fallo de arranque, y recuperación manual como salida.

En el mundo profesional, esto se traduce en horas. Horas de soporte, de máquinas que no entran, de técnicos que deben ir puesto por puesto o guiar por teléfono, de equipos que quedan parados. Y en el mundo doméstico, se traduce en otra cosa más simple y más dolorosa: sensación de indefensión. Un ordenador es, para mucha gente, banca, trabajo, estudios, fotos, documentos. Si no arranca, la vida digital se queda al otro lado de un muro.

Además, enero ha dejado una idea muy clara: incluso con parches de emergencia, el ciclo no quedó “cerrado”. Las OOB del 17 y del 24 solucionaron problemas reales y documentados, pero el bug del arranque juega en una categoría diferente porque corta el acceso antes de que Windows pueda hacer nada por sí mismo. Es como si, en medio de una reforma, la puerta se quedara bloqueada y tuvieras que entrar por una ventana.

La letra pequeña de “acumulativa”: cuando un paquete lo toca todo

Las actualizaciones acumulativas son cómodas porque simplifican: una sola instalación pone al día muchas cosas. El reverso es evidente cuando algo sale mal: una sola instalación puede tocar lo suficiente como para desestabilizar una configuración concreta. En enero, esto se ha visto con claridad en varios ámbitos: autenticación remota, gestión de energía en equipos con Secure Launch, estabilidad de aplicaciones al usar almacenamiento en la nube, y ahora, en algunos casos, el arranque.

Ese mosaico de fallos no implica necesariamente un único origen, pero sí dibuja un problema de calendario: demasiadas correcciones, demasiado rápido, con dependencias cruzadas. El ciclo de parches de Windows es enorme, y cada mes conviven millones de combinaciones de hardware, controladores y configuraciones. Aun así, cuando un mes acumula parches de emergencia, la conversación cambia: la gente deja de hablar de “actualizar por seguridad” y pasa a hablar de “actualizar con miedo”. Es un cambio cultural, y cuesta revertirlo.

Lo que se sabe y lo que sigue en el aire

Se sabe que KB5074109 está relacionada con informes de fallo de arranque en determinados equipos con Windows 11 24H2 y 25H2. Se sabe que el error visible puede ser UNMOUNTABLE_BOOT_VOLUME y que la recuperación más repetida es usar WinRE para desinstalar la actualización. Se sabe que los parches fuera de banda de enero, como KB5077744 y KB5078127, abordaron otras incidencias del mismo ciclo, pero no se han presentado como solución directa para este problema de arranque.

Lo que sigue en el aire es lo más importante para entender el alcance: si hay un factor común en el hardware afectado, si el fallo depende de controladores de almacenamiento específicos, si hay una interacción con firmware y BIOS en determinadas marcas, o si se trata de un caso raro que solo aparece bajo ciertas configuraciones internas. Microsoft, de momento, no ha publicado una explicación técnica completa ni una lista exhaustiva. Y esa ausencia, en tecnología, pesa más que un comunicado tranquilizador.

El día después: recuperar el sistema y evitar que el susto se repita

Cuando el arranque vuelve, el mundo parece normal, pero queda un poso. Porque enero también ha recordado algo que suele olvidarse hasta que hace falta: el ecosistema de recuperación de Windows no es un accesorio, es un salvavidas. WinRE, los medios de instalación, la posibilidad de entrar en UEFI o en el menú de arranque para lanzar un entorno de recuperación, todo eso suena a jerga hasta que un parche se cruza y te deja fuera.

En muchos casos, la vuelta al escritorio pasa por desinstalar la actualización, reiniciar, y comprobar que el sistema regresa a un estado estable. Pero incluso ahí hay matices. Si el equipo usa cifrado con BitLocker, la recuperación puede pedir una clave y, si no aparece, el proceso se complica. Si se ha recurrido a un USB de instalación para acceder a herramientas avanzadas, puede ser necesario ajustar temporalmente el orden de arranque o usar una tecla de acceso rápido del fabricante. Y si el fallo ha dejado rastros, como comprobaciones automáticas del sistema de archivos, el primer arranque puede tardar más de lo habitual, como si Windows estuviera pasando lista.

En paralelo, enero ha dejado una especie de mapa de daños colaterales que conviene tener presente para no confundir síntomas. Si un equipo arranca pero va raro, puede estar afectado por otra parte del mismo ciclo: autenticación remota que falla tras el parche del 13 y se arregla con KB5077744; aplicaciones que se cuelgan al trabajar con archivos en OneDrive o Dropbox y se corrigen con KB5078127; en 23H2, reinicios en lugar de apagado con Secure Launch, corregidos con KB5077797 y consolidado con KB5078132. Es el mismo mes, pero no siempre es la misma avería.

El debate se ha movido también hacia algo más incómodo: la confianza. No tanto en “Windows” como concepto, sino en el mecanismo que lo mantiene seguro. Porque un parche de seguridad tiene una misión clara, cerrar vulnerabilidades. Pero si, a cambio, existe el riesgo —aunque sea limitado— de dejar un equipo sin arranque, el equilibrio se vuelve político en el sentido amplio: qué se sacrifica, cuándo, y quién paga el coste del error. En enero, el coste lo han pagado quienes han tenido que entrar en un entorno de recuperación para desinstalar un parche que, en teoría, venía a proteger.

Volver a arrancar, volver a respirar

La fotografía de este enero queda marcada por una fecha y un número: 13 de enero de 2026, KB5074109, y la posibilidad de que, tras instalar la actualización, algunos equipos con Windows 11 24H2 y 25H2 caigan en un fallo de arranque con UNMOUNTABLE_BOOT_VOLUME. A su alrededor se apilan otras piezas del mismo mes, como los parches fuera de banda del 17 de enero y del 24 de enero, con nombres que ya forman parte del vocabulario del soporte técnico de 2026: KB5077744, KB5078127, y en 23H2 KB5077797 y KB5078132, desplegados para arreglar problemas de Remote Desktop, de apagado e hibernación en equipos con Secure Launch, y de cuelgues al guardar o abrir archivos en OneDrive, Dropbox y, en ciertas configuraciones, Outlook con PST en la nube.

Microsoft investiga el fallo de arranque y lo ha reconocido como un fenómeno real, aunque no masivo. La industria lo observa con lupa porque aquí no hay medias tintas: o arrancas o no arrancas. Y, mientras llega una explicación técnica más completa o una corrección específica, la imagen que se queda es muy concreta, casi cinematográfica: el logo de Windows, una pausa, y después el vacío. En tecnología, ese vacío pesa más que cualquier bug pequeño, porque no se debate en foros desde el escritorio; se debate desde el silencio de una pantalla negra.