Se connecter avec
S'enregistrer | Connectez-vous

problème - Machine Check Exception - BSOD

Dernière réponse : dans Matériel

Coucou, j'ai des BSOD aléatoires sur une nouvelle config. Ca me fait Machine Check Exception :
STOP: 0x0000009C (0X00000004,0X8054D5CF, OXB2000000, 0X00070FOF).

Evidemment, Memtest OK au bout de 12 heures. J'ai changé d'alime, toujours pareil (peut-être un peu moins). Le site de MS est vraiment pas locace quant à ces pbs.
Je met en doute : le HDD, la Carte graphique ou encore ma carte Wi-Fi. J'ai du mal à mettre en doute le CPU, vu que ça arrive pdt la nuit et que le CPU fait rien (j'ai désactivé momentanément f@h). Si quelqu'un peut m'apporter des infos, j'ai pas envie de passer 3 jours dessus à tout tester, donc si qqu'un a déjà eu ce pb, dites le moi ;) 
Merci.


Config:
Citation :

A64 X2 4200+ ; Mobo Gigabyte K8N51PVMT-9 ; 2*512 Mo ddr Corsair TwinX
Ecran DELL 2405FPW
Zalman reserator 1
logitech Dinovo 2 avec Mx900
Altec Lansing 2100
alime 420w yesico fanless
Radeon X1600 Pro
2x 300Go Maxtor DiadmondMax 10 (soit 600 Go ^^)
Boitier Aspire xqpack
Webcam : Apple iSight



edit : résolu avec une mise à jour du bios (sortie 3 mois après la mobo !!)

Autres pages sur : probleme machine check exception bsod

Lassé par la pub ? Créez un compte
Expert Matériel

Trouvé sur le forum AMD :
Citation :
I finally figured out my machine check error problem. It was setup from bios where with 2 sata I had both raid 0 and 1 enabled. Currently just to check I enabled only SATA 0 and reinstalled 203 server x64 enterprise with bios upgrade. System worked an booted up nicely. So no problems with hardware. Machine Check Exception was due to wrong setting on raid arrray. Seems harware is all ok.


edit : en bonus, un thread sur le sujet assez dense... http://forums.amd.com/index.php?showtopic=40110

mes deux disques sont en IDE-PATA et pas en raid :D 
j'ai pas précisé :p  je vais matter ce topic ^^

Citation :
Right when the error occurs, the screen will go black and a looping sound clip will play. Then, it will change to the blue screen error. Any recommendations?

'est exactement mon problème :D 

Bon, j'ai remplacé "/NoExecute=OptIn" par /NoExecute=AllwaysOff dans boot.ini.
Si je repasse pas, c'est que ça fonctionne :p 


edit: ca a l'air de le faire moins fréquemment. Le message a un peu changé au niveau du deuxième chiffre entre parenthèses)

bon ça me l'a refait une fois,au bout de 72 heures environ, mais le message a changé (un peu au niveau du second numéro entre parenthèses). J'ai remis mon alime fanless,ça venait pas de ça. J'ai deux Maxtor en plus :D  Mais ils sont en PATA, pas en SATA :o 

moi j'avais mes jeux qui plantaient pas mal.
J'ai UNDERclocker le proco et depuis ca fonctionne plus vite :heink: 
AMD quand tu nous tiens !

Essaye toujours. moi on m'a dit que mon proco allait trop vite par rapport à la ram (3200) donc je suis passé en bus 133mhz au lieu de 166mhz.
Tente ta chance, tu peux rien faire de mal en underclockant un proco

est-ce que le probleme est du genre aleatoire ? ou est-ce que ça arrive apres certaines actions en particulier.

Regarde quand meme du cote du CPU.
J'ai deja eu un soucis avec un waterblock mal positionné. Linux tournait tres bien mais j'avais des ecrans bleus avec XP, de maniere tres aleatoire, meme quand le PC ne faisait rien.

Demande ton ventilrad, nettoi tout, pate thermique puis repositionne le bien ;) 


Sinon essai en virant les elements que tu mets en doute, en particulier la carte wifi: desinstalle la completement. ça vient peut-etre d'un driver foireux quelque part

fiumorbo a dit :
moi j'avais mes jeux qui plantaient pas mal.
J'ai UNDERclocker le proco et depuis ca fonctionne plus vite :heink: 
AMD quand tu nous tiens !


Moi j'avais OVERclocker mon 1800+, et il chauffait moins tout en faisant les mêmes tâches ... Vas comprendre ...

altair@IDN a dit :
est-ce que le probleme est du genre aleatoire ? ou est-ce que ça arrive apres certaines actions en particulier.

Regarde quand meme du cote du CPU.
J'ai deja eu un soucis avec un waterblock mal positionné. Linux tournait tres bien mais j'avais des ecrans bleus avec XP, de maniere tres aleatoire, meme quand le PC ne faisait rien.

Demande ton ventilrad, nettoi tout, pate thermique puis repositionne le bien ;) 


Sinon essai en virant les elements que tu mets en doute, en particulier la carte wifi: desinstalle la completement. ça vient peut-etre d'un driver foireux quelque part



ouais c'est aléatoire, complètement. Des fois ça m'arrive même tout bêtement sous Word quand je tappe mes news :/  Je tenterais de démonter le WB dès que je pourrais :) 

salut,
Ma config :
Citation :
Athlon x2 3800+
CM ASROCK NF4G / sata2
DD Seagate 250 Gb sata2
2*1024 ram kingston 200 Mhz
Carte graphique club3d 7600 gt
boitier Aspire XQPACK


J'ai monté la config by hand.
J'avais le probleme BSOD Machine Check Exception
J'ai d'abord soupconner le proco : je pensais avoir peut etre mal monter le ventirad d'origine mais le proc chauffe peu et les benchs ne disent rien.
J'ai pensé a la ram : effectuer un memtest mais pas de problemes apparents.
Puis jai soupsonné la carte graphique (Club 3d, la moins chère) mais les jeux tournent bien et le BSOD n'apparaissait pas forcément quand elle était sollicitée.
J'ai téléchargé HDTUNE pour le disque dur, pensant qu'il yavait un probleme avec le sata 2, mais pas de problèmes non plus.
J'ai alors cherché sur le net et je suis tombé sur un user qui, ayant le meme probleme, avait flashé son bios avec le dernier firm dispo.
J'ai effectué la meme manoeuvre et suis passé du 1.00 au 1.50 sur la ASROCK.
Et depuis, je touche du bois, plus de problemes de BSOD.
Surement que le bios était trop ancien pour bien gérer le proco double coeur...
En espèrant avoir aidé un peu et que le probleme ne revienne plus.
@+

oki ... me voila revenu des vacances, et voici ce que je peux tirer de tes dmp ...

Tes deux fichiers minidump sont dûs à hal.dll.
Je tenterai une réparation de XP, ou bien un remplacement avec une DLL tirée du net.

Salut DenisR,
Je vois que tu t'interresses au boulot,traditionnellement réservé à BigB,
Le Duck t'as fort gentiment analysé ton dump,donc hors de question pour moi,de passer derriere :jap: 
par contre comme tu t'interresses au process,saches d'abord que tu n'as nul besoin de kd,
à moins que tu ne sois une brute, de la ligne de commande!
Donc avec Windbg,(derniere version,si possible),si tu as des Pb avec les "symbols",ce qui ne m'étonne,
qu'a moitié ;)  ,tu dois d'abord les télécharger chez "Krosoft"//msdl.microsoft.com/download/symbols,
je te le dis de mémoire(vérifie quand meme),l'adresse a peutetre changée!
Tu télécharges,soit les packages,soit à la volée,choisit ton camp!
Si tu décides par exemple, de le faire à la volée,(plus simple pour les installer!)
tu vas dans file,symbol file path,et tu tapes:srv*c:\symbols*suivi de l'adresse ci-dessus ad/symbols.
De cette maniére,tout est automatique,et tu les stockes donc,localement! :sol: 
Ensuite windbg fera son taf.
Pour l'analyse,supposons que tu galéres,un peu,je me permet juste quelques rappels :jap: 
Le Pb est donc de voir,quelles fonctions ont été appelées dans la pile,noter les structures,du kernel
qui donc,je voulais te le re-signaler commence par:nt!
Voili,voilà,il me semble qu'avec ça tu devrais t'en sortir les doigts dans le...blaire :hello: 

Re,
Ecoute moi,je n'ai pas analysé des mini stroumpfs,pardon dump,depuis au moins 2-3 ans,
je te reconfirme la procédure!elle fonctionnait(en tout cas avec les packages)
Mais étant nouveau sur le forum,tu comprendras aisement,en tout cas, je l'espère,que je ne vais pas,
organiser un coup d'état pendant que BigB est en vacances! (ça suffit déjà,avec racchi et dePillevin) :lol:  :o 
Si le maitre du mini dump,estime bon de devoir te donner plus d'infos,il le fera lui meme! :jap: 
Vu?

je ne m'emmerde même pas avec les symbols ... Ce n'est peut-être pas très pro, mais bon, ça me donne déjà d'où vient l'erreur ...

Si tu tiens vraiment aux symbols, vois avec Bigbernie :) 

En tout cas, voici texto ce que dbg me ressort :


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


Loading Dump File [C:\Documents and Settings\Administrateur\Bureau\Mini041806-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 ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Apr 18 02:17:15.250 2006 (GMT+2)
System Uptime: 0 days 7:26:15.939
*********************************************************************
* 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 ntoskrnl.exe, Win32 error 2
*** 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 unloaded module list
......................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9C, {4, 805535f0, b2000000, 70f0f}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** WARNING: Unable to verify timestamp for hal.dll
*** ERROR: Module load completed but symbols could not be loaded for hal.dll
*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

MACHINE_CHECK_EXCEPTION (9c)
A fatal Machine Check Exception has occurred.
KeBugCheckEx parameters;
x86 Processors
If the processor has ONLY MCE feature available (For example Intel
Pentium), the parameters are:
1 - Low 32 bits of P5_MC_TYPE MSR
2 - Address of MCA_EXCEPTION structure
3 - High 32 bits of P5_MC_ADDR MSR
4 - Low 32 bits of P5_MC_ADDR MSR
If the processor also has MCA feature available (For example Intel
Pentium Pro), the parameters are:
1 - Bank number
2 - Address of MCA_EXCEPTION structure
3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
4 - Low 32 bits of MCi_STATUS MSR for the MCA bank that had the error
IA64 Processors
1 - Bugcheck Type
1 - MCA_ASSERT
2 - MCA_GET_STATEINFO
SAL returned an error for SAL_GET_STATEINFO while processing MCA.
3 - MCA_CLEAR_STATEINFO
SAL returned an error for SAL_CLEAR_STATEINFO while processing MCA.
4 - MCA_FATAL
FW reported a fatal MCA.
5 - MCA_NONFATAL
SAL reported a recoverable MCA and we don't support currently
support recovery or SAL generated an MCA and then couldn't
produce an error record.
0xB - INIT_ASSERT
0xC - INIT_GET_STATEINFO
SAL returned an error for SAL_GET_STATEINFO while processing INIT event.
0xD - INIT_CLEAR_STATEINFO
SAL returned an error for SAL_CLEAR_STATEINFO while processing INIT event.
0xE - INIT_FATAL
Not used.
2 - Address of log
3 - Size of log
4 - Error code in the case of x_GET_STATEINFO or x_CLEAR_STATEINFO
AMD64 Processors
1 - Bank number
2 - Address of MCA_EXCEPTION structure
3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
4 - Low 32 bits of MCi_STATUS MSR for the MCA bank that had the error
Arguments:
Arg1: 00000004
Arg2: 805535f0
Arg3: b2000000
Arg4: 00070f0f

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.


MODULE_NAME: nt

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 433b2f11

BUGCHECK_STR: 0x9C_IA32_AuthenticAMD

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80702bf7 to 805372b2

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
805535c8 80702bf7 0000009c 00000004 805535f0 nt+0x602b2
805536f4 806fdc52 80042000 00000000 00000000 hal+0x5bf7
00000000 00000000 00000000 00000000 00000000 hal+0xc52


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------


Kikiduku, on a du mal à te lire et a te comprendre. Je suis un ane en programation et déboguage mais je sais que dans la grammaire francaise on place la "," directe apres le mot puis on fait un " " avant le prochain mot.
exemple:
je place une virgule, puis un point.

Kikiduku, ce n'est pas dû à Fourbe, mais au code que j'y ai placé ...

Pour Denis, je me suis connecté au serveur de Microsoft pour le debuggage, et voici ce qu'il me sort ...

Loading Dump File [C:\Documents and Settings\Administrateur\Bureau\Mini041806-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp.050928-1517
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Apr 18 02:17:15.250 2006 (GMT+2)
System Uptime: 0 days 7:26:15.939
Loading Kernel Symbols
.................................................................................................
Loading unloaded module list
......................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9C, {4, 805535f0, b2000000, 70f0f}

Probably caused by : ntkrnlmp.exe ( nt!KdPitchDebugger+ef4 )

Followup: MachineOwner
---------


Si ça peut t'aider un peu plus ...

ntkrnlmp.exe
ca me dit kkchose ca.
j'avais un message windows avec ca quand j'avais mal installer les drivers de ma carte mère et que j'avais foutu les catalysts de la carte vidéo sans rebooter.
Le rapport je le vois pas.

Justement a propos des symbols et des choses qu'on ne peut pas trouver.
Je suis en contact sur le sujet avec Microsoft et on a parlé de ça.
Voici quelques echanges que j'ai eu qui vont vous permettre de comprendre un peu plus la difficulté du débogage.

Dans mes discussions sur le debogage avec un ingenieur Microsoft dont on trouvera quelques extraits signés plus bas, j'ai dejà eu un pan sur le bec pour avoir dit que Microsoft ne trouve pas toujours. C'est moi qui ne peut pas trouver toujours. Et pan !
Ma base de debogage contient 1 Go de symboles (traductions binaires) et celle de cet ingenieur 10 GO. J'utilise les bases Microsoft mais lui fabrique ses propres bases privées. CQFD.
Microsoft stocke comme dit plus bas la plupart des "versions released publiques" mais pas toutes. Cela explique les dificultés à trouver des equivalences pour les machines de Marques avec des XP modifiés. Ces machines ne rentrent pas forcement en totalité dans les bases publiques de Microsoft. Et en outre cet ingénieur dit que meme avec 10 Go de base (et moi 1) il n'a pas tout.



Citations signées.
...........................

Citation :
D'où la prudence en regardant ce type de dump, d'un côté on est tenté de pointer du doigt les DLLs inconnues, ou à l'inverse de pointer la DLL remontant l'exception (portcls.sys).

Donc les BSOD sur ntdll.dll, ça ne veut ni dire que c'est un bug Microsoft, ni que la version de ntdll est corrompue dans system32, ni que cela vient forcément des DLLs que l'on ne connait pas chargées dans le system à ce moment.

Bigbernie, c'est appréciable de voir des gens comme toi s'intéressant à cette face cachée du troubleshooting (d'ailleurs Windows comme Unix, qui a aussi ses mécanisme de génération de dumps).

Je suis persuadé que tes interventions rendent largement service.
Mes posts étaient pour mettre en évidence certaines précautions à prendre dans ces conclusions, ainsi que dans les certaines de tes traductions des écrits (ex: "Windbg et les symbols que Microsoft ne trouve pas", c'est toi qui ne trouves pas les symboles de tes dumps sur le serveur de symboles MS...)

Bonne continuation
_________________
Nicolas Diétrich [MSFT]




De nouveaux symboles de débuggage sont générés à chaque compilation d'un module (.dll, .exe), même si aucune modification de code n'est effectuée.

Chaque hotfix, SP, langue différente, etc... causera des symboles différents pour un module.

Tu n'auras jamais dans ton cache local l'ensemble des symboles nécessaires pour chaque dump que tu recevras. Mon cache local de symboles (privés donc plus gros) fait environ 10Gb, et j'ai rarement en local les symboles que je recherche.

De plus sur le serveur public, seulement la plupart des versions releasées publiques sont indexées, mais pas toutes...

Tu peux lancer un !sym noisy avant de recharger tes symboles pour vérifier où windbg essaie de trouver ces symboles. Tu peux aussi utiliser symcheck pour vérifier / downloader des symboles par rapport à un dump.

Et encore une fois le fait que le crash se fait dans ici dans portcls.sys peut être seulement une conséquence.
L'analyse d'un dump post mortem, et le debugging en règle général sont du reverse engineering. C'est à dire analyser un code assembleur remontant une exception, et comprendre d'où elle provient.
Le debugging est un exercice complexe.

_________________
Nicolas Diétrich [MSFT]


.

Non, on ne peut pas les deboguer !
Mais la plupart du temps sauf quelques cas de machines de Marques on arrive a trouver la dll ou l'exe qui a généré l'exception.
Mais comme dit Microsoft, la dll qui a généré l'exception n'est pas forcement boguée ou meme responsable directement. Comme le fameux ntoskrnl.
Soumettre quelques cas a l'ingéniérie Microsoft ça aide a comprendre.
D'ailleurs cet ingénieur ne m'a pas loupé avec " que Microsoft ne trouve pas".
Pour les plantages de drivers rajoutés ou de softs rajoutés la c'est facile.
Lorsqu'une erreur commence par atixxxx ou bien NVxxx on a compris de suite. Mais c'est pour les plantages kernel que c'est difficile.
Un debogueur possede environ 200 commandes permettant de rechercher tel ou tel ennui spécifique.
L'important c'est de pouvoir donner le declencheur du plantage.
Lorsqu'on a la cause directe ...NVidia ou Kerio ou Modem Alcatel etc
(pour ça on se sert de bases de .dll et de .exe) c'est facile. Par contre pour les causes indirectes il y a Google ou bien les bases Microsoft et les bulletins.





Lassé par la pub ? Créez un compte

Créer un nouveau sujet