En resumen
Cuando cada pantallazo azul trae un código distinto y culpa a un controlador diferente, lo más probable es la memoria RAM. Se confirma con MemTest86 durante varias horas y probando cada módulo por separado. Un solo error basta para descartar el módulo.
El síntoma
Un equipo lleva semanas, o meses, con pantallazos azules. No siempre con el mismo programa abierto, no siempre a la misma hora y cada vez con un código diferente:
MEMORY_MANAGEMENT
IRQL_NOT_LESS_OR_EQUAL
PAGE_FAULT_IN_NONPAGED_AREA
KMODE_EXCEPTION_NOT_HANDLED
SYSTEM_SERVICE_EXCEPTIONSe han actualizado los controladores, se ha pasado el antivirus e incluso se ha reinstalado Windows. Durante unos días parece arreglado, y vuelve.
Nos encontramos exactamente este caso en un equipo que llevaba meses así. La causa era un módulo de memoria SO-DIMM DDR4 defectuoso.
Por qué apunta a la memoria
Cuando el fallo es de software, como un controlador concreto o una actualización, los pantallazos se repiten con el mismo código y señalan al mismo archivo. Cuando la memoria corrompe datos al azar, el error salta en el componente que estuviera usando esa zona de memoria en ese momento. Por eso cada pantallazo culpa a algo distinto.
La variedad es la pista: códigos distintos, controladores distintos y ninguna relación con lo que se estaba haciendo.
Diagnóstico paso a paso
1. Reúne el historial de fallos
En el Visor de eventos → Registros de Windows → Sistema, filtra por los identificadores 41 (Kernel-Power: apagado inesperado) y 1001 (BugCheck: el pantallazo con su código). Así tienes las fechas y la frecuencia reales, no las que recuerda el usuario.
2. Lee los volcados
Windows guarda un volcado pequeño de cada pantallazo en C:\Windows\Minidump. Con WinDbg, gratuito en la Microsoft Store, se abre cada archivo y se ejecuta:
!analyze -vFíjate en BUGCHECK_CODE y en MODULE_NAME o IMAGE_NAME. Si en cinco volcados aparecen cinco módulos distintos, deja de buscar un controlador culpable.
3. Prueba la memoria de verdad
El Diagnóstico de memoria de Windows (mdsched.exe) sirve como primer vistazo, pero se le escapan muchos fallos intermitentes. La prueba fiable es MemTest86: se graba en un USB, se arranca el equipo desde él y se deja trabajar varias horas, idealmente una noche, con al menos cuatro pasadas completas.
La regla es sencilla: un solo error es suficiente. Una memoria sana no da ninguno.
4. Aísla el módulo
Si el equipo tiene dos módulos, prueba cada uno por separado y en la misma ranura. Si falla uno y el otro no, el problema es el módulo. Si los dos fallan en una ranura y pasan en la otra, la sospecha pasa a la ranura o a la placa base.
En equipos de sobremesa con la memoria configurada por un perfil XMP o EXPO, desactiva el perfil y repite la prueba: a veces el módulo está bien y lo que falla es la velocidad forzada.
5. Sustituye y verifica
Cambia el módulo por uno compatible: mismo tipo (DDR4, DDR5), mismo formato (SO-DIMM en portátiles y equipos todo en uno, DIMM en sobremesa), misma velocidad y misma tensión. Después, otra pasada larga de MemTest86 antes de devolver el equipo a su usuario.
Cómo detectarlo antes
- Un pantallazo aislado puede ser casualidad. Dos en la misma semana ya merecen una visita al Visor de eventos.
- Con monitorización del registro de eventos, los apagados inesperados (evento 41) generan un aviso antes de que el usuario tenga que contarlos.
- Al ampliar memoria, usa módulos del mismo tipo y velocidad que los existentes y pasa MemTest86 antes de dar el trabajo por terminado.
¿Te está pasando en tu empresa?
Si prefieres no hacerlo tú, llámanos o escríbenos. Lo revisamos, en remoto siempre que se pueda, y te decimos qué tiene y qué cuesta arreglarlo antes de tocar nada.