1
BSoD - Blue Screen of Death
une fatalité ?
une fatalité ?
Une description est très bien réalisée sur wikipedia, je veux simplement rajouter quelques commentaires et conseils.
Un BSoD indique un dysfonctionnement dans le coeur de Windows. Mais, il ne faut pas se méprendre, la plupart du temps ce n'est pas Windows le responsable.
Toutes les applications, telles que les antivrus, les pare-feu, les émulateurs de cd-rom et j'en passe, possèdent leurs propres drivers qui travaillent exclusivement dans le noyau de Windows. L'aimable Microsoft 'offre' une partie de son sésam aux partenaires prestigieux comme Norton ou Nero dans le cadre d'un partenariat lucratif. Pour information, Microsoft permet également aux universités d'utiliser, à des fins de recherche, une partie du code source de son noyau. Démarche intéressante. Plus d'information : wrk
A coté de cela, le commun des mortels peut s'engager à réaliser son propre driver pour X raisons. DeamonTools, Rku, Seem, tous ces programmes possédent leur propre driver. La difficulté réside dans le fait que le sésam de Windows n'est pas documenté officiellement et chaque erreur de programmation provoque ce fameux BSoD. Les drivers cités sont plûtot de type 'software', mais il existe également tous les drivers de type 'hardware' fournit par les constructeurs de composants informatique.
Ainsi même les respectables sociétés de développement ne sont pas à l'abrit de provoquer ces écrans bleus sur les ordinateurs de leurs clients. On pourrait citer pour l'exemple : Outpost Firewall Pro.
Tout ça pour dire que la plupart du temps, un BSoD est le résultat d'un driver mal programmé et non de Windows. Je ne fais pas l'apologie de Windows, je remets les choses dans leur contexte
Mais alors que faire face à un BSoD ?
Non non et non, il ne faut pas formater et reinstaller Windows !! Voila le genre de réponse que je vois sur certain forum ...Ce n'est pas la faute de Windows si un driver réalise une opération non autorisée tout de même.
Première chose à faire : identifier le dysfonctionnement.
Lors de l'écran bleu, il faut surtout noter le code erreur et le driver responsable, dans le cas ou tout ceci est cité.
Un petit tour sur une base de connaissance permet d'identifier le problème. (Très bon site en passant
).Ainsi, on retrouve les grands classiques :
0x0000000A: IRQL_NOT_LESS_OR_EQUAL
0x0000008E: KERNEL_MODE_EXCEPTION_NOT_HANDLED
etc etc ...
Cela permet de connaitre le contexte de l'erreur, et d'en déduire les façons d'y remédier. Le site propose également quelquesz solutions aux problèmes les plus courants et les plus simples.
Maintenant, si aucune information n'est viable dans le BSoD, cela se complique, mais quelques solutions existent.
Comment faire si le BSoD n'annonce rien de particulier ?
Notre cher Windows nous permet de réaliser un dump (une sauvegarde) des informations lors du plantage.Il faut tout d'abord activer le mode debug de Windows.
Pour cela, il convient de rajouter l'argument /DEBUG lors du chargement de l'os via le fichier de configuration boot.ini.
Ainsi lors de BSoD, un fichier nommé minidump sera créé généralement dans le dossier C:\WINDOWS\Minidump.
Ce fichier n'est pas réellement utilisable en l'état. Mais celui-ci renferme certaines informations essentielles pour comprendre le dysfonctionnement (Nom du driver le driver responsable, l'état de la mémoire, l'état des registres du processeur ...).
Pour lire le fichier vous devez disposer des outils de debug fournits par Microsoft.
Ils sont gratuits et peuvent être utilisé sans limite.
(Le lien est valable pour les processeur x86 et un os 32bits, sinon affiner votre recherche)
Cela vous installe une multitude de programme, mais le plus important dans notre cas, est l'outil windbg.exe.
Vous trouverez un fichier de documentation dans ce dossier, vous disposez également de la base de Microsoft.
Pour analyser le fichier dump (.dmp), en mode console, taper ceci :
CODE
C:\Program Files\Debugging Tools for Windows>windbg -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z c:\windows\minidump\Mini011907-02.dmp
Extrait d'une analyse :
CODE
*******************************************************************************
* Bugcheck Analysis *
***************************************************************************
***
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 805b817e, efdcd9f0, 0}
Probably caused by : example.sys ( example+3c4 )
Followup: MachineOwner
* Bugcheck Analysis *
***************************************************************************
***
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 805b817e, efdcd9f0, 0}
Probably caused by : example.sys ( example+3c4 )
Followup: MachineOwner
Voici un exemple de résultat sur lequel j'ai retiré plusieurs informations.
Néanmoins, les choses importantes sont :
- BugCheck 1000008E
- caused by : example.sys ( example+3c4 )
)
L'erreur 1000008E : KERNEL_MODE_EXCEPTION_NOT_HANDLED indique que le driver accède à une zone mémoire non incluse dans son propre espace.
Ici, c'est un driver de test que j'ai réalisé qui est légèrement bancal. La preuve
Dans le cas ou vous trouvez le responsable du crash et après moulte réinstallation du driver original, si le problème persiste, faites vous à d'idée que celui-ci est défaillant.
Ici je fais principalement alusion aux drivers type 'software' qui n'accède pas au matériel physique de la machine. Néanmoins pour cette catégorie, même si un problème matériel se présente le driver permettant la communication avec le kernel devrait pouvoir gérer tous les types d'erreur et ainsi ne pas provoquer de BSoD. Facile à dire ... croyez moi
++
