Nu cred că este vreun utilizator care să nu fi primit un BSOD (Blue Screen Of Death) în Windows.
Mulţi utilizatori nu ştiu cum să rezolve problema care generează aceste erori.

În acest articol o să vă explic cum puteţi interpreta un BSOD şi cum puteţi rezolva erorile care îl generează.
În primul rând, un BSOD este generat fie de o defecţiune hardware (o memorie RAM defectă, o incompatibilitate între componente, etc.), fie de o „defecţiune” software (incompatibilitate librării, drivere deteriorate, drivere care nu au trecut de testul Microsoft, etc.)

Vă voi recomanda două instrumente cu care puteţi depana BSOD-uri: DebugWiz de la Microsoft şi BlueScreenView de la Nirsoft.
Înainte de a continua, vă recomand să operaţi următoarele modificări (acestea ar trebuie realizate după fiecare reinstalare a sistemului de operare:
– se apasă tastele Win+Pause/Break pentru a deschide System Properties;
– click pe tab-ul Advanced;
– în secţiunea Startup and Recovery, executaţi un click pe butonul Settings;
din secţiunea System failure debifaţi opţiunea Automatically restart;
– din secţiunea Write debugging information modificaţi calea directorului în care se vor stoca log-urile: din %Systemroot%Minidump în D:Minidump sau orice altă cale, în afară de partiţia în care este instalat sistemul de operare.

Acum, pentru primul exemplu, voi folosi tool-ul de la Microsoft.

Paşi de lucru:
– după instalare se va accesa debugwiz.exe;
– se bifează opţiunea Advanced şi apoi se execută un click pe butonul Browse şi se navighează până în folder-ul unde a fost instalat debugger-ul şi se execută dublu click pe cdb.exe;

– acum se va executa un click pe butonul Browse pentru a selecta fişierul de timp Memory Dump;
– se va naviga până în directorul C:WindowsMinidump şi se va executa un click pe fişierul de tip *.dmp;

Acesta va fi de forma: 012810-24507-01.dmp
Ce înseamnă acest nume: data şi ora la care a avut loc BSOD-ul.

Pentru a genera log-ul, este suficient să executaţi un click pe butonul Generate Log.

Imediat, se va deschide Command Prompt şi se va afişa un mesaj în care suntem informaţi că după ce log-ul este generat, va fi salvat în partiţia C:, astfel: C:debuglog.txt.

Utilizând acest tool, generarea log-ului va dura ceva timp, dar se merită, fiindcă informaţiile oferite sunt complete, complexe şi utile.

Ca o mostră din informaţiile afişate:

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

Loading Dump File [C:Documents and SettingsAlexandruDesktop 12810-24507-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:WINDOWS;C:WINDOWSsystem32;C:WINDOWSsystem32drivers
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a0f000 PsLoadedModuleList = 0x82b57810
Debug session time: Thu Jan 28 15:45:07.307 2010 (GMT+2)
System Uptime: 0 days 0:07:27.039
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

……………………………………………………..
……………………………………………………….
………………………..
Loading User Symbols
Loading unloaded module list
………
1: kd> cdb: Reading initial command ‘!analyze -v;r;kv;lmtn;.logclose;q’
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Acestea sunt informaţii generale legate de SO, dump file, etc.

După generarea log-ului, fereastra terminalului se închide şi putem naviga în C:debuglog.txt pentru a analiza log-ul.
Aici, vom căuta MODULE_NAME şi IMAGE_NAME dar şi FAULTING_IP.

FAULTING_IP:
Wdf01000!FxDevice::Dispatch+b
MODULE_NAME: aswMonFlt
IMAGE_NAME:  aswMonFlt.sys

După o scurtă căutare pe Google, aflăm că acel driver aparţine antivirului Avast (Avast Antivirus File System Minifilter Driver).
Se pare că acest driver este cauza pentru care un alt driver a „cedat”: Wdf01000.sys
Soluţia este dezinstalarea completă a acestuia folosind Revo Uninstaller şi instalarea altui antivirus.


Acum, acelaşi fişier îl voi prelucra cu tool-ul de la Nirsoft.
Paşi de lucru:
după deschiderea soft-ului, în toolbar executaţi un click pe comanda Advanced Options;
– dacă fişerele dump nu sunt stocate în locaţia implicită, se va utiliza butonul Browse pentru a naviga până la acestea;

Interpretarea acestora este foarte rapidă, dar şi foarte săracă în detalii:

După cum puteţi observa, în imaginea de mai sus este blamat driver-ul ntkrnlpa.exe.
În stack-ul lui, vina mai cade şi pe ntkrnlpa.exe, Wdf01000.sys şi halmacpi.dll.
Căutând pe Google vom da peste o multitudine de soluţii care s-ar putea sau nu potrivi şi în cazul nostru.

Eu vă recomand tool-ul de la Microsoft, fiindcă oferă foarte multe detalii legate de cauză.
Sfatul meu este ca să apelaţi la persoane care se pricep la interpretarea şi rezolvarea acestor probleme, fiindcă dacă veţi umbla pe unde nu trebuie riscaţi să daţi peste cap sistemul de operare.

Back To Top
Search