Windows 10 v1903 se reinicia tras pantallazo azul "MACHINE_CHECK_EXCEPTION" (hal.dll)

Archivado
Recapitulo, antes de esta historia estaba funcionando a las mil maravillas y con total estabilidad en la v1903 de Windows. Actualizo casi todo mi hardware y al tener que volver a instalar Windows, aprovecho e instalo la 1909 que acababa de salir hacia apenas unos días en ese momento, (esto fue hace un par de meses). Total, que de repente sin mas, empiezo a sufrir reinicios aleatorios así sin motivo alguno.

Expuse el problema en otro hilo y tras ver que algunos otros usuarios tenían problemas similares con esta nueva versión de Windows, instale la 1903 y todo volvió a funcionar de maravilla.

PD: si queréis ver el tema mas a fondo, podéis echar un ojo al hilo aquí:
hilo_windows-se-reinicia-muy-aleatoriamente-tras-cambiar-placa-cpu-y-actualizar-a-windows-10-v1909_2356881#p1748745083


El caso es que tras un mes y pico funcionando A LA PERFECCIÓN, de repente, así sin mas... sin instalar ningún programa, ni actualizar ningún driver ni nada raro... (solo me salia en Windows update disponible la actualización 1909 que por los antecedentes, por supuesto no instalo... pero nada mas con respecto a la 1909...) de repente desde hace 4 o 5 días... ZAS!, otra vez los pantallazos azules con el mensaje "MACHINE_CHECK_EXCEPTION".

Mosca con el tema, reviso los volcados de memoria y según el programita "bluescreenview", parece que el problema viene por el archivo dll "hal.dll", ya que aparece en rojo, como que ha causado el problema, en teoría... y ademas debe ser si, porque en los 4 volcados que llevo, SIEMPRE aparece el mismo.

He buscado en google y no veo apenas info, lo poco que hay está en ingles y no veo nada que se refiera a este tema, no tengo nada claro, ¿alguien que entienda sabría decirme que puede estar mal?

Decir que no soy precisamente novato, llevo currando con la informática 18 años, aunque no he escarvado nunca con estos temas tan "profundos" de Windows ya que gracias a Dios nunca habia sufrido estas cosas, pero bueno, a lo que voy, es que la BIOS está actualizada, drivers actualizados, instalación limpia y totalmente optimizada vamos, está todo mas que mirado.. trabajo con apps actualizadas y siempre de confianza con las que llevo currando toda la vida, licencia original, etc etc, no tengo ni idea de como solucionar el dichoso problema de los pantallazos azules.

Ah, y se me pasaba, mi hardware es:
- Placa MSI MPG Z390 GAMING EDGE AC
- CPU i7 9700K
- RAM G.skill DDR4 16GB (2x8) 3600Mhz CL16
- VGA RTX 2080 Gigabyte
- 2 x SSD Samsung 970 EVO 500GB PCIe Nvme (Raid 0 de 1TB)
- HDD 1TB WD 7200rpm
- HDD 8TB WD 5400rpm
- Fuente alimentacion EVGA 1000W con certificado Gold Plus

Por supuesto he pasado un test con BurnIn Test y todo perfecto también.
Por si acaso, he hecho un test al procesador y otro a la RAM con "intel Extreme Tuning Utility" y ambos han salido satisfactorios, aunque solo durante 20 minutos cada uno, supongo que será suficiente...

Una cosa curiosa también es que en el visor de eventos algunas veces aparecía un error justo antes del reinicio que decía en los detalles algo de "\Device\HarddiskVolume7", como si fuera algún disco, pero es raro porque yo no tengo tantos volúmenes... de hecho me voy a diskpart y el máximo es el "volume4".... así que no se, no tengo ni idea, no me cuadra nada.

En definitiva, ¿alguien puede abrirme un poco los ojos?, le estaría eternamente agradecido.

Muchas gracias de antemano.
@potis

¿Todos los controladores son aptos para W10?. Prueba a actulizarlos [beer] [beer]
Jhonny_palillo escribió:@potis

¿Todos los controladores son aptos para W10?. Prueba a actulizarlos [beer] [beer]


Claro, ya lo dije ahi mas arriba, "todos los controladores actualizados", por supuesto que si, eso es lo primero que revisé ademas porque como dije, tengo ya mucha carrera y se que cosas al menos no hay que dejar pasar, como esta.. el problema es que nunca he tenido este caso concreto y por ello ya no se por donde tirar :_(
potis escribió:
Jhonny_palillo escribió:@potis

¿Todos los controladores son aptos para W10?. Prueba a actulizarlos [beer] [beer]


Claro, ya lo dije ahi mas arriba, "todos los controladores actualizados", por supuesto que si, eso es lo primero que revisé ademas porque como dije, tengo ya mucha carrera y se que cosas al menos no hay que dejar pasar, como esta.. el problema es que nunca he tenido este caso concreto y por ello ya no se por donde tirar :_(


Pues como no reinstales el W10 de nuevo... :-? :-?
Jhonny_palillo escribió:
potis escribió:
Jhonny_palillo escribió:@potis

¿Todos los controladores son aptos para W10?. Prueba a actulizarlos [beer] [beer]


Claro, ya lo dije ahi mas arriba, "todos los controladores actualizados", por supuesto que si, eso es lo primero que revisé ademas porque como dije, tengo ya mucha carrera y se que cosas al menos no hay que dejar pasar, como esta.. el problema es que nunca he tenido este caso concreto y por ello ya no se por donde tirar :_(


Pues como no reinstales el W10 de nuevo... :-? :-?


jajaja, que vaa, si tuvieramos que hacer eso cada vez que surja un problema apaga y vamonos... xD.

Eso para mi es lo último porque reinstalar todo me lleva casi un dia entero!, y no es coña, porque no es solo el equipo donde juego y tengo mis cosas personales... que ya tiene tela, si no el equipo en el que trabajo.... asi que te podrás imaginar, tengo "millones" de cosas configuradas y tal y cada vez que me toca reinstalar pues eso, pierdo muchísimo tiempo, y ademas parte de ese gran tiempo estoy inhabilitado para currar, y eso tambien tiene su historia... asi que en fin, a intentar solucionarlo que es lo suyo. Además, estoy en instalaciones distintas, recuerda lo que dije en el primer mensaje, y con los mismos sintomas, esto tiene que ser alguna gilipollez del sistema que si se retoca se soluciona fijo, ahora a saber que es...
@potis

Cualquier pego será seguro [toctoc] [toctoc]
ATENCION, tengo mas info..

Por otro sitio me comentaban como listar los volumenes de ese tipo para identificarlo y tal, y aunque despues finalmente he visto que venia del disco C, dudo mucho que sea un fallo físico, ya que los discos del raid 0 son nuevos y ademas antes tenia el mismo problema con otro SSD que tenia 2 años funcionando a la perfeccion.

El caso, es que mirando el tema justo me ha crasheado, y mosqueadisimo con el tema he vuelto a mirar y mirar info, y he visto una forma de sacar informacion mas precisa de los volcados de memoria, y eso me ha llevado a analizar los volcados con un programa de microsoft llamado "WinDBG" y muy curiosa la info que me ha sacado.. os copio el resultado, sorry porque es un poco largo pero asi podreis analizar mejor que ocurre:


Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\minidump\122819-9234-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows 8 Kernel Version 18362 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff800`67a00000 PsLoadedModuleList = 0xfffff800`67e48130
Debug session time: Sat Dec 28 01:36:45.713 2019 (UTC + 1:00)
System Uptime: 1 days 3:17:26.465
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
................................................................
..............................
Loading User Symbols
Loading unloaded module list
.......................................

************* Symbol Loading Error Summary **************
Module name Error
ntoskrnl The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
*** WARNING: Unable to verify timestamp for hal.dll
*** ERROR: Module load completed but symbols could not be loaded for hal.dll
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, ffff9a8fecf1b028, b2000000, 30005}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
Unable to load image \SystemRoot\system32\PSHED.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for PSHED.dll
*** ERROR: Module load completed but symbols could not be loaded for PSHED.dll
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: pshed!_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: pshed!_WHEA_ERROR_RECORD_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : GenuineIntel

Followup: MachineOwner




En definitiva... algo de INTEL? no me lo puedo creer... algo del procesador?, rarisimo no lo siguiente.. pero tendría sentido porque los problemas empezaron cuando reinstale el sistema, precisamente por cambiar la placa y EL PROCESADOR... pero.. si os soy sincero, no creo que físicamente esté mal, porque rinde divinamente y eso... creo que será algún tipo de incompatibilidad de algún driver del chipset o a saber que, no tengo ni idea, pero la cosa es, como intentar solucionar algo así?, el procesador en si no tiene drivers concretos, que leches puedo hacer?

Saludos y gracias de antemano.
6 respuestas
Archivado
Volver a General