Bloqueos aleatorios sin BSOD: el registro que revela al culpable

febrero 17, 2026 • febrero 17, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Conoces el tipo de “bloqueo”. El ratón deja de moverse. El audio se repite como una cinta embrujada. Caps Lock deja de alternar. Sin pantalla azul. Sin volcado de memoria. Simplemente una máquina que decidió tomarse el día libre en silencio.

Cuando la gente dice “aleatorio”, yo oigo “no miramos en el lugar correcto”. Ese lugar suele no ser tu controlador de GPU, no suele ser la RAM (aunque sí, a veces), y tampoco ese optimizador que prometió “aumentar el rendimiento”. El lugar correcto es el registro que anota timeouts y reinicios de almacenamiento: el momento en que el sistema intentó leer o escribir y el dispositivo… no respondió a tiempo.

El registro culpable: donde los bloqueos realmente dejan huellas

Los bloqueos duros sin BSOD suelen atribuirse a la “gráfica” porque eso es lo que se ve. Pero lo que ves es solo la fachada. La parte trasera de la casa es I/O: almacenamiento, enlaces PCIe, firmware del controlador y decisiones de gestión de energía que parecían geniales en una presentación.

El “registro único” que repetidamente revela al culpable es el que registra timeouts de almacenamiento y reinicios:

Windows: Visor de eventos → registro System, especialmente eventos de StorPort, stornvme, disk y WHEA-Logger alrededor del momento del bloqueo. Los clásicos: Event ID 129 (“Reset to device, \Device\RaidPortX, was issued”) y Event ID 153 (operación de E/S reintentada).
Linux: búfer de anillo del kernel: dmesg / journalctl -k, especialmente mensajes como blk_update_request: I/O error, timed out, nvme ... controller is down; will reset, resetting controller, ataX: hard resetting link y advertencias del sistema de archivos.

Por qué esto funciona: las pilas de almacenamiento son conservadoras. Cuando el SO no obtiene respuesta del dispositivo, lo registra. Incluso cuando todo lo demás está atascado. Incluso cuando la interfaz está muerta. Incluso cuando el sistema “se recupera” y crees que no pasó nada.

El bloqueo suele ser la manifestación visible de que el kernel espera I/O en un estado no interrumpible (D-state en Linux) o de que un controlador de puerto de almacenamiento de Windows intenta reinicios y reintentos mientras tu escritorio deja de funcionar educadamente.

Una cita que vale la pena tener en tu monitor:

John Allspaw: “El fracaso es una parte normal de los sistemas complejos.” (idea parafraseada)

Qué es realmente un “bloqueo sin BSOD” a nivel del sistema operativo

Un BSOD es un fallo con parada controlada: el SO sabe que algo es irrecuperable y corta la energía con un volcado. Un bloqueo es peor en otro sentido: el SO sigue “vivo”, pero el progreso se detiene porque algún hilo crítico está bloqueado, hay una tormenta de interrupciones, o el sistema está trabado en un nivel donde no puede programar el trabajo que le permitiría recuperarse.

En la práctica, la mayoría de los “bloqueos aleatorios” caen en unas pocas categorías:

1) Timeouts de I/O de almacenamiento y reinicios de controladora

Este es el grande. Los dispositivos NVMe pueden colgar, los enlaces SATA pueden oscilar, el almacenamiento USB puede perder alimentación, el firmware RAID/HBA puede comportarse como si estuviera de vacaciones, y los estados de energía del controlador pueden fallar. El SO entonces hace reintentos, reinicios y espera. Durante ese tiempo, cualquier cosa que toque el disco afectado queda bloqueada. Si el disco es tu unidad del SO, felicitaciones: todo lo toca.

2) Casos límite de PCIe / gestión de energía

ASPM, subestados L1, políticas de inactividad agresivas y combinaciones de firmware con errores pueden crear comportamientos de “funciona durante días y luego se bloquea bajo el timing exacto equivocado”. No es místico. Es una máquina de estados con una mala transición.

3) Inestabilidad de memoria y CPU

RAM defectuosa, overclocks inestables, undervolting o PSU marginales pueden congelar un equipo sin dejar registros claros. Pero aun entonces, los registros de almacenamiento a menudo muestran “timeouts” porque la CPU dejó de atender interrupciones. Eso no significa que el almacenamiento lo causara, pero te dice dónde el sistema dejó de responder.

4) Bloqueos del sistema de archivos / integridad

Los sistemas de archivos pueden quedarse esperando a que las escrituras concluyan o a que se confirmen commits del journal. ZFS puede bloquearse en el TXG sync si el dispositivo subyacente se comporta mal. NTFS puede parecer “bien” mientras el almacenamiento debajo no lo está.

Broma #1: Un “bloqueo aleatorio” nunca es aleatorio; es solo que tu ordenador se niega a redactar un informe de incidente detallado.

Hechos interesantes y contexto histórico (la versión corta y útil)

StorPort de Windows existe porque el almacenamiento es complicado. Microsoft introdujo StorPort para reemplazar el comportamiento antiguo de SCSIport, buscando mayor rendimiento y arquitecturas de almacenamiento modernas.
Event ID 129 es un reinicio, no un diagnóstico. Te dice que el SO forzó un reinicio porque el dispositivo no respondió; el “por qué” está en otro lugar (energía, firmware, cableado, PCIe).
NVMe trajo rendimiento y nuevos modos de falla. NVMe es un protocolo con muchas colas sobre PCIe, lo que significa que los estados de enlace y el timing del firmware importan más de lo que muchos esperan.
Los mensajes de “reset de enlace” ATA/SATA existen desde hace décadas. El registro de Linux como “hard resetting link” es el equivalente moderno de “el cable o el controlador está teniendo un momento”.
Las SSD de consumo están optimizadas para benchmarks, no para la latencia en el peor caso. Un disco puede tener buena puntuación y aun así congelar un sistema cuando la recolección de basura ocurre en el momento equivocado.
Las políticas de caché de escritura fueron una trampa recurrente. Desde los primeros días del IDE hasta NVMe moderno, “habilitar caché de escritura” ha mejorado el rendimiento y a veces ha empeorado el radio de desastre ante fallos de energía o bugs de firmware.
SMART fue diseñado para predicción, no para absolutos. Los discos pueden fallar con SMART “perfecto”, y los discos pueden arrastrarse con contadores preocupantes. Usa SMART como pista, no como veredicto.
Los registros del kernel suelen ser lo último que funciona. Incluso cuando el espacio de usuario está congelado, el kernel puede seguir registrando reintentos y reinicios en el ring buffer, que sobreviven hasta el reinicio.
Los equipos de almacenamiento empresariales hablan más de “latencia de cola” que de throughput. El stall en el percentil 99.9 de la I/O es lo que hace que los sistemas se sientan congelados, no los MB/s promedio.

Guía rápida de diagnóstico (primero/segundo/tercero)

Este es el camino más corto que conozco desde “mi máquina se bloquea” hasta “puedo señalar el subsistema responsable”. Síguelo en orden. No improvises.

Primero: establece si el I/O de almacenamiento se atascó en el momento del bloqueo

Windows: busca eventos en el registro System (StorPort/stornvme/disk) dentro de unos minutos del bloqueo y al arrancar después del ciclo de energía forzado.
Linux: revisa journalctl -k -b -1 (arranque anterior) en busca de timeouts, reinicios y errores del sistema de archivos.

Si ves reinicios/timeouts, trata la estabilidad de la ruta de almacenamiento como sospechosa hasta demostrar lo contrario.

Segundo: correlaciona con la topología de hardware y la gestión de energía

Identifica si el dispositivo afectado es NVMe en PCIe, SATA, USB o está detrás de un RAID/HBA.
Comprueba ajustes de enlace/energía (Windows PCI Express Link State Power Management; Linux ASPM).
Revisa versiones de firmware (SSD, BIOS/UEFI) y controladores (chipset/almacenamiento).

Tercero: reproduce bajo carga controlada y mide la latencia en cola

Usa fio en Linux o una herramienta comparable para generar I/O mixto sostenido y vigila errores/timeouts.
Observa distribuciones de latencia (iostat -x, nvme smart-log, contadores de PerfMon en Windows).

Si logras desencadenar el bloqueo con carga de I/O, convertiste “aleatorio” en “diagnosticable”. Esa es la victoria.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

A continuación hay tareas prácticas. Cada una incluye un comando, salida de ejemplo, qué significa y qué decides después. Los comandos se muestran en formato shell de Linux; si estás en Windows, lo equivalente es “Visor de eventos + PowerShell”. Te doy los comandos de Linux porque son precisos y reproducibles, y porque muchos “bloqueos de escritorio Windows” acaban siendo “firmware + NVMe” que aparecen idénticos en un live de Linux.

Task 1: Check the previous boot’s kernel log for timeouts

cr0x@server:~$ journalctl -k -b -1 | egrep -i 'timeout|reset|nvme|ata|i/o error|blk_update_request|hung'
Jan 12 09:41:02 host kernel: nvme nvme0: I/O 123 QID 7 timeout, aborting
Jan 12 09:41:02 host kernel: nvme nvme0: controller is down; will reset: CSTS=0x3
Jan 12 09:41:03 host kernel: blk_update_request: I/O error, dev nvme0n1, sector 1953525168

Qué significa: El kernel emitió I/O, no obtuvo finalización y reinició el controlador. Eso no es normal. Un evento puede ocurrir; repeticiones son un patrón.

Decisión: Trata NVMe/controladora/gestión de energía PCIe como sospechosos principales. Procede a verificar salud NVMe y enlace PCIe. También planifica una actualización de firmware.

Task 2: Identify whether processes were stuck in uninterruptible I/O (D-state)

cr0x@server:~$ ps -eo state,pid,comm,wchan:32 | awk '$1 ~ /D/ {print}' | head
D  1423  postgres         nvme_poll
D  2210  jbd2/nvme0n1-8   __flush_work

Qué significa: Los procesos en D-state están esperando I/O. Cuando suficientes hilos críticos quedan en D-state, el sistema parece congelado.

Decisión: Enfócate en el dispositivo de almacenamiento que respalda esas esperas (aquí: nvme0n1). No pierdas horas en soluciones de escritorio/UI.

Task 3: Check block layer and device errors in dmesg (current boot)

cr0x@server:~$ dmesg -T | egrep -i 'nvme|ata|I/O error|resetting|link is down|frozen|AER' | tail -n 30
[Mon Jan 13 10:12:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 13 10:12:44 2026] nvme 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
[Mon Jan 13 10:12:44 2026] nvme nvme0: controller reset

Qué significa: Errores PCIe (incluso “Corrected”) más reinicios del controlador son un olor. Los problemas en la capa física pueden ser energía, integridad de la señal, firmware o transiciones de estado ASPM.

Decisión: Revisa estado del enlace PCIe y ASPM; considera actualizar BIOS, volver a asentar el dispositivo, probar otra ranura (desktop) o otro backplane/cable (servidor).

Task 4: Inspect PCIe link speed/width and error counters

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta|ASPM|AER|DevSta' -n
45:        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
47:        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
63:        DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

Qué significa: El enlace está negociado a velocidad/anchura completas, pero CorrErr+ indica que ocurrieron errores corregidos. No es automáticamente fatal, pero correlacionado con bloqueos es accionable.

Decisión: Si los errores aumentan con el tiempo, prueba con ASPM deshabilitado y/o velocidad de enlace más baja (configuración BIOS) para confirmar estabilidad. Si es estable, has encontrado el eje de falla.

Task 5: Check NVMe SMART/health and error log

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 45 C
available_spare                     : 100%
percentage_used                     : 7%
media_errors                        : 12
num_err_log_entries                 : 98

Qué significa: media_errors y el aumento de num_err_log_entries no son “normales”. Incluso si el disco “funciona”, te está diciendo que tiene problemas.

Decisión: Haz copia de seguridad inmediatamente, planifica reemplazo o actualización de firmware. Si es la unidad del SO en laptop/desktop: trátalo como urgente, no como “algún día”.

Task 6: Check NVMe controller error log for timeouts/resets

cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 20
Error Log Entries for device:nvme0 entries:64
 Entry[ 0]
  error_count     : 98
  sqid            : 7
  cmdid           : 0x0012
  status_field    : 0x4004
  parm_error_loc  : 0x0000
  lba             : 1953525168

Qué significa: El disco registró errores vinculados a comandos/colas. Esto complementa los timeouts del kernel. Juntos forman una historia: “el SO pidió, el disco no respondió correctamente”.

Decisión: Confirma la versión de firmware y verifica si tu plataforma tiene problemas conocidos con APST/ASPM. Si puedes reproducir, desactiva APST para probar.

Task 7: On SATA systems, check SMART for reallocated/pending sectors

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_On_Hours'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       45
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       18765

Qué significa: Sectores pendientes y errores CRC son combustible clásico para “bloqueos y reintentos”. Los CRC suelen implicar cableado/backplane; los sectores pendientes implican la superficie del disco o el nivel de traducción de flash.

Decisión: Si UDMA_CRC_Error_Count aumenta, reemplaza cable/backplane primero. Si hay sectores pendientes, programa reemplazo de la unidad.

Task 8: Check filesystem for corruption signals after forced reboots

cr0x@server:~$ journalctl -b | egrep -i 'EXT4-fs error|xfs_repair|I/O error|journal|buffer i/o error' | tail
Jan 13 10:18:11 host kernel: EXT4-fs warning (device nvme0n1p2): ext4_end_bio:345: I/O error 10 writing to inode 262402 starting block 12345678)

Qué significa: El sistema de archivos se queja de escrituras fallidas. Esto es daño descendente por el problema de I/O, no la causa raíz.

Decisión: Arregla la estabilidad del almacenamiento primero. Luego ejecuta las comprobaciones del sistema de archivos apropiadas durante una ventana de mantenimiento (y con backups confirmados).

Task 9: Measure tail latency and saturation with iostat

cr0x@server:~$ iostat -x 1 5
Linux 6.5.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          2.10    0.00    1.20   35.40    0.00   61.30

Device            r/s     w/s   r_await   w_await  aqu-sz  %util
nvme0n1         120.0   300.0     3.20   220.50   18.40  99.80

Qué significa: w_await en 220 ms con %util ~100% es generador de stalls. Tu sistema “se congela” porque todo espera detrás de esas escrituras.

Decisión: Determina si esto es saturación esperada de la carga (necesitas almacenamiento más rápido / mayor profundidad de cola / diseño distinto) o latencia patológica (firmware, GC, errores). Si los picos de latencia se correlacionan con reinicios/errores, es patología.

Task 10: Reproduce under controlled I/O with fio (without destroying data)

cr0x@server:~$ fio --name=latcheck --filename=/var/tmp/fio.test --size=2G --direct=1 --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=1 --time_based --runtime=120 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=3210: Mon Jan 13 10:30:10 2026
  read: IOPS=12.3k, BW=48.0MiB/s (50.3MB/s)
    slat (usec): min=4, max=420, avg=12.5, stdev=5.3
    clat (usec): min=75, max=850000, avg=240.1, stdev=9200.4
  write: IOPS=5, BW=20.0KiB/s
    clat (msec): min=2, max=12000, avg=980.0, stdev=2100.0

Qué significa: La latencia máxima de finalización llegando a segundos (o peor) es donde vive el “bloqueo”. También fíjate en el colapso del rendimiento de escritura—a menudo señal de housekeeping interno del disco o problemas.

Decisión: Si fio puede provocar el stall, tienes una prueba reproducible. Úsala para validar arreglos (actualización de firmware, ajustes de energía, driver diferente) y justificar reemplazo.

Task 11: Check ZFS-specific stalls (if you run ZFS)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          nvme0n1   ONLINE       0     3     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/guest01.img

Qué significa: ZFS te está diciendo que vio errores de escritura; eso concuerda con los bloqueos. El “archivo con errores” es la víctima.

Decisión: Reemplaza/repara el dispositivo o la ruta subyacente. Haz un scrub después de restaurar la estabilidad. Si esto es un pool de un solo disco, acepta que necesitas redundancia si valoras tus fines de semana.

Task 12: Check for kernel soft lockups and RCU stalls (CPU not making progress)

cr0x@server:~$ journalctl -k -b | egrep -i 'soft lockup|hard lockup|RCU stall|watchdog' | tail
Jan 13 10:14:22 host kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [kworker/u32:1:842]

Qué significa: La CPU no se programó normalmente durante mucho tiempo. Esto puede ser causado por controladores que entran en bucle, tormentas de interrupciones o problemas de hardware. Los timeouts de almacenamiento pueden ser causa y efecto aquí.

Decisión: Si los soft lockups se correlacionan con PCIe/AER o reinicios NVMe, sospecha plataforma/firmware/gestión de energía. Si aparecen solos, amplía a pruebas de CPU/RAM.

Task 13: Test whether ASPM is enabled (common NVMe freeze contributor)

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Qué significa: El sistema está gestionando activamente los estados de energía PCIe de forma agresiva.

Decisión: Para diagnóstico, cambia a modo rendimiento (o desactiva ASPM) y comprueba si los bloqueos desaparecen. Si lo hacen, encontraste una solución temporal estable y un problema de compatibilidad/firmware para arreglar correctamente.

Task 14: Confirm whether NVMe APST is active (Linux)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/default_ps_max_latency_us
25000

Qué significa: La política APST (Autonomous Power State Transition) está activa. Algunos discos/plataformas se comportan mal bajo ciertos presupuestos de latencia.

Decisión: Para probar, establece una política más conservadora mediante parámetro de kernel en el cargador de arranque (por ejemplo, nvme_core.default_ps_max_latency_us=0) y mira si el problema desaparece. Si lo hace, busca actualizaciones de firmware o deja la configuración como arreglo pragmático.

Broma #2: El firmware de almacenamiento es como el café de la oficina—generalmente está bien, ocasionalmente es catastrófico, y nunca mejora fingir que no existe.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición incorrecta

Una empresa mediana tenía una flota de estaciones Windows usadas para CAD y procesamiento de datos. La gente informaba “bloqueos aleatorios” varias veces por semana. TI persiguió controladores de GPU porque los bloqueos ocurrían al rotar modelos o arrastrar ventanas. La suposición de trabajo era: “Si la pantalla se detiene, es gráfico”.

El equipo reemplazó algunas GPU. Reinstalaron imágenes. Incluso culparon a una actualización de Windows. El problema siguió ocurriendo, y el único detalle consistente era la ausencia de BSODs. La dirección lo llamó “error de usuario” con la elocuencia habitual de la dirección.

Durante una semana especialmente mala, alguien finalmente revisó el registro System justo después de un bloqueo y reinicio forzado. Los mismos dos eventos se repetían: reinicios de StorPort (ID 129) y eventos de reintento de disco (ID 153). Estaban agrupados cerca del momento del bloqueo.

La suposición incorrecta no era “los controladores GPU nunca causan bloqueos”. Pueden. La suposición incorrecta fue tratar el síntoma visible por el usuario como el límite del subsistema. Cuando el equipo pivoteó a almacenamiento, emergió el patrón: un modelo NVMe concreto + una revisión BIOS de laptop específica + gestión de energía de enlace agresiva. Una actualización de BIOS y un cambio de política de energía detuvieron los bloqueos, y los casos restantes se resolvieron con actualizaciones de firmware del SSD.

La lección: trata el registro de timeouts de almacenamiento como primer respondedor. Es el que te muestra dónde el SO dejó de confiar en un dispositivo, no dónde el usuario dejó de confiar en el ordenador.

Mini-historia 2: La optimización que salió mal

Una empresa de servicios tenía un appliance analítico basado en Linux entregado a clientes. Para exprimir rendimiento, un ingeniero activó ahorros de energía más profundos en el BIOS y afinó el SO para menor consumo en reposo. En laboratorio funcionó bien: los benchmarks eran fuertes, las temperaturas bajaron, todos se sintieron responsables.

En campo, los dispositivos empezaron a “congelarse” durante trabajos por lotes nocturnos. Sin logs de pánico, sin fallos limpios. Solo necesidad de ciclo de energía forzado. Los trabajos escribían intensamente en espacio NVMe local.

La primera respuesta fue optimizar la carga: menos fsyncs, buffers mayores, más concurrencia. Eso lo empeoró. La latencia en cola subió y los sistemas se volvieron más frágiles. Cuanto más “optimizaban”, más empujaban el dispositivo al estado exacto donde dejaría de responder y requeriría reinicio del controlador.

Cuando alguien finalmente extrajo los logs del kernel del arranque anterior, la historia fue clara: timeouts NVMe, reinicios de controladora y errores PCIe corregidos ocasionales. La “optimización” había empujado la plataforma a un caso límite de estado de energía bajo I/O sostenido. La solución fue aburrida: deshabilitar el estado de energía problemático (combinación ASPM/APST) y desplegar una actualización de firmware. El rendimiento apenas cambió, pero la estabilidad sí.

Las optimizaciones que salen mal son comunes porque cambian el timing. Y el timing es donde viven los bugs de firmware.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un pequeño equipo de infraestructura corría cargas mixtas: un clúster virtualizado y algunos nodos de bases de datos bare-metal. Tenían una regla estricta y poco glamorosa: cada host recopilaba y conservaba logs del kernel/sistema entre reinicios, y cada ticket de incidente requería adjuntar los logs del último arranque.

Un nodo de base de datos comenzó a “congelarse” una vez cada par de semanas. La caída fue corta (alguien lo ciclo de energía), pero el impacto en el negocio era alto por alojar un sistema crítico interno. Los primeros incidentes se atribuyeron a “Linux siendo raro”. Eso no es diagnóstico; es rendirse.

Porque los logs se preservaban, el equipo pudo comparar múltiples eventos de bloqueo. Cada vez, el mismo patrón: aumento de errores CRC SATA seguido por reset de enlace y un largo stall de I/O. SMART no mostraba sectores realocados, así que el disco parecía “saludable” si solo mirabas los contadores equivocados.

Reemplazaron un único cable en el chasis durante una ventana de mantenimiento. Los bloqueos se detuvieron. Sin depuración heroica a medianoche. Sin reemplazar medio servidor “por si acaso”. Solo un hábito disciplinado: conservar logs, comparar incidentes, seguir la evidencia.

La práctica se siente aburrida hasta que te salva la semana. Entonces se siente como profesionalismo.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente específica. Si te reconoces en alguna, bien. Los arreglos son más baratos que el orgullo.

1) “Se congela solo jugando” → suposición “controlador GPU” → realidad almacenamiento/PCIe

Síntoma: Bloqueo duro bajo carga, sin BSOD, audio en bucle.
Probable causa raíz: Timeouts NVMe durante escrituras de cache de shaders, streaming de assets del juego o actividad de pagefile; o problemas de enlace PCIe que aparecen como errores AER corregidos.
Solución: Revisa logs por reinicios/timeouts NVMe; actualiza BIOS y firmware del SSD; prueba desactivar ASPM/APST; asegúrate de controladores de chipset/almacenamiento actualizados; valida la refrigeración del SSD.

2) “Sin errores en SMART, así que el disco está bien” → ignorar los contadores relevantes

Síntoma: El sistema se atasca y luego se recupera; con el tiempo los bloqueos empeoran.
Probable causa raíz: Errores CRC (cable/backplane), entradas en el log de errores NVMe, o stalls a nivel de firmware no reflejados en el estado básico SMART “PASSED”.
Solución: Revisa UDMA_CRC_Error_Count (SATA) y logs de error NVMe; reemplaza cables; vuelve a asentar dispositivos; valida errores PCIe.

3) “Activar caché de escritura lo hizo más rápido” → latencia de cola y riesgo por pérdida de energía

Síntoma: Mejores números en benchmarks, peores bloqueos en el mundo real, especialmente durante escrituras intensas.
Probable causa raíz: Políticas de caché interactuando con garbage collection del firmware o comportamiento de flush; el aumento de colas oculta problemas hasta que deja de hacerlo.
Solución: Usa pruebas centradas en latencia (fio con percentiles de clat); mantén ajustes de caché conservadores salvo que tengas protección contra pérdida de energía y validación.

4) “Es el sistema de archivos” → tratar la corrupción como causa en vez de consecuencia

Síntoma: Advertencias del sistema de archivos tras reinicio forzado.
Probable causa raíz: Fallos de I/O subyacentes que provocan escrituras incompletas.
Solución: Estabiliza la ruta de almacenamiento primero; luego repara el sistema de archivos; restaura desde backups si hay errores permanentes.

5) “Aumentemos concurrencia para terminar antes” → saturar el dispositivo hasta fallo

Síntoma: La frecuencia de bloqueos aumenta cuando “aceleras” la carga.
Probable causa raíz: Profundidad de cola y escrituras sostenidas desencadenan el peor comportamiento del firmware o throttling térmico que conduce a timeouts.
Solución: Limita concurrencia/iodepth; mejora refrigeración; valida con iostat y fio; considera SSDs de gama superior diseñados para escrituras sostenidas.

6) “No hay logs porque se congeló” → no preservar logs del arranque anterior

Síntoma: Nada útil después del reinicio; todo el mundo adivina.
Probable causa raíz: Logs rotados, journal volátil, sin persistencia de fallos.
Solución: Habilita journaling persistente, aumenta retención, exporta logs. Si no puedes ver el último arranque, no puedes hacer forense.

Listas de verificación / plan paso a paso

Usa esto como tu plan operativo. Imprímelo. Ejecútalo como un incidente, no como un pasatiempo.

Checklist A: Primeros 30 minutos tras un bloqueo

Registra la hora aproximada del bloqueo y qué estaba haciendo el sistema (copiando archivos, actualizando, jugando, compilando, backup de VM).
Tras reiniciar, extrae inmediatamente los logs del arranque anterior:
- Linux: journalctl -k -b -1
- Windows: registro System alrededor del momento del bloqueo y en el siguiente arranque
Busca: timeouts, reinicios, errores de I/O, eventos AER/WHEA.
Captura el contexto de hardware: modelo SSD, firmware, versión de BIOS, versiones de controladores de almacenamiento.
Si existen errores de almacenamiento: haz backup ahora. No “esperes otro bloqueo”.

Checklist B: Reproducción controlada e aislamiento

Ejecuta carga de I/O controlada (fio o equivalente) y monitoriza:
- iostat -x 1 para await/utilización
- logs del kernel por reinicios/timeouts
Prueba una variable a la vez:
- Deshabilita ASPM (dependiente de plataforma) y vuelve a probar
- Desactiva/reduce NVMe APST (parámetro kernel) y vuelve a probar
- Actualiza firmware del SSD y vuelve a probar
- Actualiza BIOS/UEFI y vuelve a probar
Si es SATA: intercambia cable/puerto del backplane; vuelve a probar.
Si solo es reproducible en caliente: mide temperaturas del SSD; mejora refrigeración; vuelve a probar.

Checklist C: Si no puedes reproducir, pero los bloqueos continúan

Aumenta la observabilidad:
- Habilita logs persistentes (almacenamiento persistente de journald)
- Habilita configuración de dump de núcleo/kernel (donde aplique)
Busca señales de desgaste:
- Aumento de entradas en el log de errores NVMe
- Aumento de contadores CRC
- Incremento de errores PCIe corregidos
Programa una ventana de mantenimiento para asentar hardware y actualizar firmware.
Establece un umbral de reemplazo: si los reinicios ocurren más de una vez por semana, deja de debatir y reemplaza el dispositivo/ruta.

Preguntas frecuentes

1) ¿Por qué no hay BSOD? ¿No debería Windows/Linux caer si el almacenamiento muere?

No. Ambos SO intentan recuperarse de los fallos de almacenamiento usando reintentos y reinicios. Un bloqueo puede ser el SO esperando I/O, no una excepción fatal.

2) Veo Event ID 129 en Windows. ¿Eso significa que mi SSD está malo?

Significa que Windows reinició el dispositivo de almacenamiento porque dejó de responder. El SSD puede estar malo, pero también puede ser firmware, gestión de energía PCIe, una ranura inestable o un problema de controlador. Trátalo como “inestabilidad en la ruta de almacenamiento”.

3) Linux muestra “controller is down; will reset.” ¿Es eso siempre hardware?

A menudo, pero no siempre. Puede ser un bug de firmware desencadenado por APST/ASPM, throttling térmico o problemas de enlace PCIe. Reemplazar hardware a veces es la solución más rápida, pero valida con pruebas de firmware y estados de energía.

4) ¿Un cable SATA malo puede realmente congelar un sistema?

Sí. Los errores CRC provocan reintentos; los reintentos provocan stalls; los stalls hacen que el SO parezca congelado—especialmente si ese disco está ocupado o aloja el SO/journal.

5) Mi estado SMART dice “PASSED”. ¿Por qué sigues sospechando del almacenamiento?

Porque “PASSED” no es una garantía. Mira contadores específicos (sectores pendientes, errores CRC, logs de error NVMe) y los logs de timeouts del kernel/SO. Esos están más cerca de la realidad.

6) ¿Podría ser inestabilidad de RAM o CPU en su lugar?

Absolutamente. Si ves soft lockups del watchdog sin errores de almacenamiento, o errores en subsistemas no relacionados, ejecuta pruebas de memoria y elimina overclocks/undervolts. Pero no omitas los logs de almacenamiento—a menudo muestran la primera ruptura visible en la cadena.

7) Si desactivar ASPM/APST lo arregla, ¿es eso “la solución final”?

Puedes usarlo como workaround aceptable, especialmente en escritorios. La “solución final” suele ser una actualización de BIOS/firmware del SSD o reemplazo de hardware que permita gestión de energía segura sin colgar.

8) ¿Cómo dejo de perder evidencia tras un ciclo de energía forzado?

En Linux, asegúrate de que journald sea persistente y los logs no se almacenen solo en memoria. En Windows, asegúrate de que los registros de eventos se retengan lo suficiente y no se sobrescriban. Además, anota las horas de bloqueo para poder correlacionar.

9) ¿Qué pasa si el bloqueo ocurre antes de que el SO pueda registrar nada?

Entonces dependes de lo que sobrevive: logs de firmware (cuando estén disponibles), indicadores de hardware y evidencia entre arranques (logs del arranque previo, contadores SMART/NVMe que aumentan). También intentas reproducir bajo carga controlada y cambias una variable a la vez.

10) ¿Los discos externos USB también causan bloqueos?

Sí, especialmente dispositivos alimentados por el bus o cajas defectuosas. Los timeouts de almacenamiento USB pueden bloquear I/O y crear stalls del sistema, dependiendo de qué esté montado y cómo lo maneje el SO.

Próximos pasos que puedes ejecutar hoy

Deja de tratar “sin BSOD” como “sin pista”. La pista suele estar en tus registros de timeouts de almacenamiento, documentando en silencio cada vez que el sistema tuvo que reiniciar un dispositivo para seguir adelante.

Haz lo siguiente:

Extrae los logs del arranque anterior del kernel/sistema y busca timeouts/reinicios (NVMe/SATA/AER/WHEA).
Si los encuentras, haz copia de seguridad inmediatamente y empieza por actualizaciones de firmware/BIOS y pruebas de gestión de energía (ASPM/APST).
Mide la latencia cola bajo carga. Si tu latencia máxima llega a segundos, ese es el generador de bloqueos.
Si la evidencia apunta a una unidad o ruta concreta, reemplázala. Esto no es un fallo moral; es mantenimiento.

El objetivo no es ganarle una discusión a la máquina. El objetivo es hacer que los bloqueos sean aburridamente imposibles. Los registros te llevan allí—si lees los correctos.