Rozwiązywanie problemów z Bluescreen – ekran śmierci

[Kobacabana]

Bluescreen (BSOD) - szukanie przyczyny powstawania komunikatów oraz czytanie plików DMP

Kod:

Komputer napotkał problem i należy go uruchomić ponownie. Trwa zbieranie informacji o błędzie. Po zakończeniu tego procesu komputer zostanie automatycznie uruchomiony ponownie. I tu proces ukończenia naprawy komputera.

Aby dowiedzieć się więcej, można później wyszukać w trybie online ten błąd:
CRITICAL_STRUCTURE_CORRUPTION

Bluescreen-y, czyli błędy sprzętowe oraz programowe w systemie Windows mogą powstawać na wskutek różnych przyczyn. Czasami może to być awaria sprzętowa np. uszkodzenie pamięci RAM (jak sprawdzić pamięć RAM – opis i instrukcja MemTest) albo też awaria programowa. Z komunikatów, jakie otrzymujemy ciężko jednak cokolwiek odczytać. Czasami pomaga wrzucenie komunikatu do wyszukiwarki, ale nie zawsze to pomoże, bo problem może być bardziej złożony lub też mogą istnieć więcej jak jedna przyczyna bluescreen. Ponadto komunikat z błędem czasami jest tak złożony, ze trudno go rozszyfrować. Jednak możemy użyć narzędzia (program) do analizy plików DMP.

Pliki DMP tworzy system Windows w C:\Windows\minidump i są to pliki, w których są zapisywane krytyczne momenty systemu Windows jak np. bluescreen, a dokładnie, co tworzy takie problemy. Aby odczytać taki plik potrzebujemy narzędzia do analizy plików DMP.

Odczytanie plików zrzutu DMP

Warto skorzystać z darmowego rozwiązania firmy Microsoft o nazwie WinDbg - Microsoft Debugging Tools x86 (jest wersja x32 oraz x64). Po zainstalowaniu programu można rozpocząć poszukiwanie przyczyn błędu. Informacja o błędzie jest zapisywana w plikach zrzutu pamięci DMP. Każdy plik DMP posiada unikalną nazwę. Po dacie oraz godzinie wystąpienia problemu możemy zlokalizować, kiedy wystąpił ostatni problem, (jeśli mamy więcej plików .dmp w katalogu).

Mając już zainstalowany program uruchamiamy WinDbg, aby wyświetlić prawidłowo wszystkie dziwne znaki i symbole należy w menu programu File wybrać opcję Symbol File Path (lub wcisnąć kombinację klawiszy Ctrl+S). W nowym oknie należy wkleić poniższy kod i zatwierdzić klikając OK. Symbole ściągniemy na dysk.

Kod:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Wczytanie symboli za pierwszym razem może trochę dłużej porwać, ale odczytanie pliku zrzutu staje się wtedy łatwiejsze.

W oknie programu, z menu wybieramy File i Open Crush Dump (lub naciskamy Ctrl+D), po czym wskazujemy plik DMP, który chcemy otworzyć. Musimy sobie taki plik wyciągnąć z katalogu, jeśli nasz badany system nie pozwala się uruchomić. Jeżeli pokaże się nam ekran z pytaniem, czy zapisać miejsce pracy, odpowiadamy Tak. W ten sposób ustawimy sobie katalog pracy z plikami.

Po załadowaniu pliku i odczytaniu raportu będziemy mieli standardowy raport, możemy go rozszerzyć o więcej informacji klikając w raporcie na Use !analyze -v to get detailed debugging information w ten sposób raport zostanie rozszerzony o dokładniejsze informacje. Dla nas najważniejsze są dwie linijki BugCheck i nr błędu oraz Probably caused by:

Kod:

BugCheck 109, {a3a01f5894602a64, b3b72bdee6e01973, fffff80000570000, 19}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Te dwie linijki mogą wskazywać na program, na bibliotekę .dll w komputerze, albo jak w moim przypadku dość dziwny problem CRITICAL STRUCTURE CORRUPTION, który nawet w analizie z pliku .dmp, jest trudny do rozwiązania. Oczywiście opis na stronie Microsoft jest podany, kiedy taki problem może się pojawiać i zazwyczaj występuje to w sytuacji konfliktu programowego (może zachodzić konflikt sterowników, niewłaściwe oddziaływanie na kernel systemowy), ale dokładnego rozwiązania jak ten problem BugCheck 109 usunąć Microsoft nie podaje.

Oprócz pełnej informacji o błędzie, dość pomocnym polem jest PROCESS_NAME. W polu tym podana jest nazwa procesu podczas, którego wykonywania doszło do błędu. Zazwyczaj jest podany jakiś program, który tworzy problem, ale jak w moim przypadku widać problem zachodzi w systemie, jednak nie ma dokładnych informacji, co powoduje taki problem i jak ten problem rozwiązać samemu.

Mój przykład analizowanego pliku .dmp w WinDbg:

Kod:

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


Loading Dump File [C:\DMP\my_file.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:
Windows 7 Kernel Version 9600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.16384.amd64fre.winblue_rtm.130821-1623
Machine Name:
Kernel base = 0xfffff803`d1879000 PsLoadedModuleList = 0xfffff803`d1b409b0
Debug session time: Fri Aug 29 13:45:14.301 2014 (GMT+2)
System Uptime: 0 days 1:10:53.132
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a01f5894602a64, b3b72bdee6e01973, fffff80000570000, 19}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

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

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5894602a64, Reserved
Arg2: b3b72bdee6e01973, Reserved
Arg3: fffff80000570000, Failure type dependent information
Arg4: 0000000000000019, Type of corrupted region, can be
    0 : A generic data region
    1 : Modification of a function or .pdata
    2 : A processor IDT
    3 : A processor GDT
    4 : Type 1 process list corruption
    5 : Type 2 process list corruption
    6 : Debug routine modification
    7 : Critical MSR modification

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


BUGCHECK_STR:  0x109

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff803d19c90a0

STACK_TEXT:  
ffffd000`2377a1c8 00000000`00000000 : 00000000`00000109 a3a01f58`94602a64 b3b72bde`e6e01973 fffff800`00570000 : nt!KeBugCheckEx


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  BAD_STACK

Followup: MachineOwner

W moim przypadku z racji, że nie miałem zrobionej ostatniej prawidłowej kopii jedynym sensownym rozwiązaniem problemu CRITICAL STRUCTURE CORRUPTION było zainstalowanie na nowo systemu Windows.

Dokładniejszego szukania rozwiązań problemów z bluescreen, jeśli już poznamy analizę zrzutów z plików .dmp możemy szukać w oparciu o błędy systemu Windows (kody BSOD) - [Kod błędu - Bug Check], które znajdziemy w interencie oraz na stronach Microsoft.