Acer Aspire 6920g con reinicios aleatorios sin BSOD

Estoy un 90% seguro de que ha sido un caso aislado, pero recuerdo que otro portátil de este exacto modelo me dio problemas “random” anteriormente, allá por enero.

En su momento no conseguí averiguar qué le pasaba. Lo apañé como pude con un XP, estable pero sin ACPI y se lo entregué al cliente.

Estas son las pruebas:
– Test de disco duro: OK
– Test de RAM (memtest86+, 4h): OK
– Reinstalación de Windows: OK.
– Test idle en Windows 7 (1h): Fallo, se reinicia sin pantallazo azul
– Test idle en Linux LiveCD (12h): No se reinicia.
– Test de temperatura: OK. 56ºC estables.

Hasta aquí podemos pensar las siguientes opciones:
– Algún fallo de Windows 7. Muy improbable.
– El disco duro (por que con LiveCD no falla). Confirmado que no es el caso.
– Fallo de placa base que por algún motivo Linux no dispara. No tendría solución.
– Cualquier otra cosa.

Viendo que en Linux no ocurría el error, se me ocurrió probar con Windows en modo a prueba de fallos. Lo dejé toda una noche, y cuando volví por la mañana el equipo seguía funcionando perfectamente.

Tenemos un portátil que se reinicia aleatoriamente sin BSOD pero que en modo a prueba de fallos funciona perfectamente. Pues vamos a recortar cosas:
– Deshabilito drivers: T. Gráfica, Modem, Redes, Webcam, Fingerprint, etc…
– Test idle en Windows 7 (1h): Fallo, se reinicia sin pantallazo azul

Es bastante desconcertante. Sólo quedaban activos algunos drivers del chipset, por lo que pruebo.
– Deshabilito drivers: SMBus Intel, Controladora LPC, …
– Test idle en Windows 7 (1h): Fallo, se reinicia sin pantallazo azul

Ya empiezo a suponer que tiene que ser un problema relacionado con ACPI. ACPI es una cosa muy misteriosa que gestiona la energía del ordenador, sus componentes, y un millón de cosas más.
En Windows XP se podía desactivar la comunicación entre ACPI y Windows, pero en Windows Vista/7/8 ya no existe esa opción.

De todas formas, durante la instalación de Windows 7 ya estaba activa la comunicación ACPI y no dio ningún problema. Además, en Linux también estaba activada y tampoco dio ningún problema.

Pues nada, no queda otra que mirar las diferencias de servicios noPnP entre el modo seguro y el arranque normal. Reviso c:\windows\ntbtlog.txt… Me sale una buena lista de servicios, pero habiendo desactivado todos los drivers no queda mucha base por quitar.

Aunque hay un driver que me llama la atención: IntelPPM.
IntelPPM se encarga de que tu procesador baje su velocidad cuando no es necesaria tanta potencia.
¿Podría ser el causante? Desactivo el driver, reinicio y pruebo…
– Test idle en Windows 7 (12h): OK.
– Test rendimiento 100% en Windows 7 (12h): OK.

He salvado un portátil de una muerte segura. Si le hubiera sugerido al cliente utilizarlo en modo a prueba de fallos o en Linux, no le habría convencido.

Haber desactivado ese driver le provocará que le dure menos la batería, pero por otro lado aún puede utilizar el portátil bien 🙂

¿Por qué habrá fallado? A saber.
Probablemente la placa base ya no esté funcionando tal como debería, y no es capaz de mandar los bajos voltajes/amperajes que requieren los modos de ahorro de energía del procesador.

Un saludo 🙂

Publicado en