picasso Opublikowano 29 Września 2015 Zgłoś Udostępnij Opublikowano 29 Września 2015 (edytowane) :( Diagnostyka samoczynnych restartów i BSOD Materiały pomocnicze w diagnostyce na forum Konfiguracja ekranu z błędem i zrzutów pamięci *.DMP Debug zrzutów pamięci *.DMP BlueScreenView (dla niezaawansowanych) WinDbg jako składnik Windows SDK (Windows 7 do Windows 11) WinDbg w wersji samodzielnej (Windows 10 i Windows 11) Materiały referencyjne: Resolving Blue Screen errors in Windows ----------------------------------------------------------- Advanced troubleshooting for stop or blue screen errors (wcześniej jako KB3106831) Overview of memory dump file options for Windows (wcześniej jako KB254649) Generate a kernel or complete crash dump (wcześniej jako KB969028) How to determine the appropriate page file size for 64-bit versions of Windows (wcześniej jako KB2860880) Getting Crash Dumps to Appear in Win7 Kernel dump storage and clean up behavior in Windows 7 Understanding Crash Dump Files ----------------------------------------------------------- Analyze a kernel-mode dump file by using WinDbg Using the !analyze Extension Copyright @picasso fixitpc.pl Powielanie tej pracy zabronione. Edytowane 30 Stycznia przez picasso Odnośnik do komentarza
picasso Opublikowano 29 Września 2015 Autor Zgłoś Udostępnij Opublikowano 29 Września 2015 (edytowane) Konfiguracja ekranu z błędem i zrzutów pamięci *.DMP Domyślnie wszystkie Windows są skonfigurowane na automatyczny restart ukrywający BSOD, który może ewentualnie zbyt szybko mignąć, by dało się z niego coś odczytać. W przypadku wystąpienia tajemniczego autorestartu należy skonfigurować odpowiednią opcję, tak by w zamian zaczął się pokazywać konkretny błąd. Teksty ogólne na BSOD są powtarzalne i nas nie interesują, chodzi o detale błędu: - W Windows 7 i starszych ekran BSOD zawiera dokładny kod STOP z 4 parametrami. - W Windows 8 i nowszych ekran BSOD otrzymał nową formę i został ograniczony do przyjaznej nazwy błędu STOP. Brakujący kod STOP i parametry mogą być pozyskane z Dziennika zdarzeń lub zrzutów pamięci. Ekran ewentualnie może zostać zmodyfikowany, by pokazały się 4 parametry (w lewym górnym rogu ekranu) poprzez utworzenie w rejestrze wartości DisplayParameters. Na Windows 8 i 8.1 edycja wymaga instalacji hotfixów sprecyzowanych w KB2929742, na Windows 10 edycja możliwa out-of-box. Ta edycja nie przywraca starej formy ekranu, jak to sugerowane w niektórych opisach na Google. Podstawowa weryfikacja opcji systemowych Z klawiatury kombinacja + R i w polu Uruchom wklej następujące polecenie: Windows Vista do Windows 11: SystemPropertiesAdvanced Windows XP: rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl,,3 To polecenie otworzy Właściwości systemu w karcie Zaawansowane: Należy przejść do sekcji Uruchamianie i odzyskiwanie: I dopasować wyliczane poniżej opcje. Po wykonaniu konfiguracji należy zatwierdzić zmiany poprzez reset systemu. 1. Odznacz Automatycznie uruchom ponownie. W okolicznościach ponawiających problem zamiast auto-restartu pojawi się plansza niebieskiego ekranu śmierci. Należy przepisać informacje typu nazwa i kod błędu oraz (o ile będzie podane) plik generujący błąd. Jak już powiedziane, na Windows 8 i nowszych dane ograniczone tylko do nazwy błędu, ale i to może być przydatne w sytuacji gdy system nie nagrywa z jakiś względów żadnych innych danych (brak rekordu w Dzienniku zdarzeń, czy zrzutów pamięci). 2. Upewnij się, że w Zapisywanie informacji o debugowaniu jest ustawione wykonywanie zrzutu pamięci, a nie (brak). Typy zrzutów pamięci DMP: Mały zrzut pamięci (Small memory dump) - Domyślne ustawienie na XP. W zależności od wersji Windows 64KB, 128KB lub 256KB. Zrzut pamięci jądra (Kernel memory dump) - Domyślne ustawienie na Windows 7 i Vista. Pełny zrzut pamięci (Complete memory dump) - Ta opcja jest niewidoczna na niektórych konfiguracjach posiadających więcej niż 2GB pamięci. Wymaga ogromnego pliku pamięci i miejsca na dysku. W typowej diagnostyce "domowej" rzadko kiedy potrzebna. Automatyczny zrzut pamięci (Automatic memory dump) - Tylko w Windows 8 i nowszych. Domyślne ustawienie na tych systemach *. Aktywny zrzut pamięci (Active memory dump) - Tylko w Windows 10 i Windows 11. * Nie jestem pewna, ale wydaje mi się, że w okolicach Windows 11 Wersja 22H2 ponownie zmieniono domyślne ustawienie (lub system bierze pod uwagę specyficzne okoliczności). Windows 11 Wersja 24H2, zarówno na moim głównym komputerze (aktualizowany z Windows 10) jak i w wirtualnej maszynie (czysta instalacja), ustawił "Mały zrzut pamięci (256 KB)". Małe zrzuty są generowane w folderze C:\Windows\Minidump (pliki nie są zastępowane), wszystkie pozostałe są zapisywane do pliku C:\Windows\MEMORY.DMP (domyślnie jest zastępowany), o ile nie zmieniano ręcznie konfiguracji lokalizacji. Brak obecności plików zrzutów *.DMP, mimo prawidłowej konfiguracji systemu na zapis zrzutów, może wynikać z braku miejsca na dysku, nieprawidłowych ustawień pliku pamięci wirtualnej (brak pliku lub jest za mały), lub użycia czyściciela usuwającego pliki DMP (np. CCleaner). Dodatkowo, od Windows 7 na komputerach domowych nie podłączonych do domeny domyślnie Zrzut pamięci jądra nie jest zapisywany na dysku z mniej niż 25GB wolnego. Automatyczna konfiguracja systemu pod kątem Zrzutu pamięci jądra lub Pełnego zrzutu pamięci Do tego celu służy skrypt DumpConfigurator.hta. Uwzględnia także rozmaite edycje rejestru udokumentowane przez Microsoft. Edytowane 29 Stycznia przez picasso Odnośnik do komentarza
picasso Opublikowano 29 Września 2015 Autor Zgłoś Udostępnij Opublikowano 29 Września 2015 Debug zrzutów pamięci *.DMP Wskazanym krokiem jest też zdebugowanie obecnych w systemie kilku ostatnich zrzutów pamięci i podanie końcowego raportu tekstowego. W zależności od ustawienia wyżej pokazanej opcji Zapisywanie informacji o debugowaniu pliki *.DMP są w: C:\Windows\Minidump (Mały zrzut pamięci) lub C:\Windows\MEMORY.DMP (pozostałe typy). By odczytać ten typ plików, jest wymagana specjalna aplikacja: BlueScreenView (podstawowy program dla mniej zaawansowanych) lub Debugging Tools for Windows | WinDbg (dla zaawansowanych, o wiele większe możliwości). Odnośnik do komentarza
picasso Opublikowano 4 Grudnia 2015 Autor Zgłoś Udostępnij Opublikowano 4 Grudnia 2015 (edytowane) BlueScreenView Strona domowa Platforma: Windows XP do Windows 10 32-bit i 64-bit Licencja: freeware Nie wymaga Microsoft Debugging Tools i instalacji, ale ma limitowane możliwości i może być konieczne skorzystanie jednak z narzędzia Microsoftu. Program datowany na 2015 i w teorii kompatybilność kończy się na Windows 10, zachowanie na Windows 11 nie zostało przeze mnie przetestowane. BlueScreenView potrafi otworzyć lokalizację plików Minidump i przekonwertować zrzuty pamięci na czytelną formę umożliwiającą wytypowanie przyczyny dla krytycznych błędów / restartów komputera. Dla każdego z zrzutów są podawane informacje: nazwa pliku, czas / data powstania, podstawowe informacje wyświetlane na ekranie śmierci (Bug Check Code i 4 parametry), detale o sterownikach lub modułach będących przypuszczalną przyczyną. W dolnej części okna widok prezentuje sterowniki załadowane podczas wystąpienia błędu z opcjonalnym wyróżnianiem kolorem wytypowanych obiektów tworzących problem lub graficzny BSOD w stylu XP. Program jest ustawiony na automatyczne skanowanie lokalizacji C:\Windows\Minidump, podając listę wszystkich wykrytych tam plików zrzutów pamięci. Lokalizację można przekonfigurować w opcjach, co umożliwi odczytywanie np. plików przeniesionych z innego komputera, lub pochodzących z równoleglej instalacji Windows. Również dostępna opcja bezpośredniego otwierania pojedynczego pliku. BlueScreenView potrafi odczytywać pliki Minidump wersji 64-bit. By skopiować dane, podświetl dane wejście i z menu kontekstowego wybierz Save selected items. Wynikowy plik TXT zaprezentuj za pomocą Załączników forum. ================================================== Dump File : 020215-57860-01.dmp Crash Time : 2015-02-02 01:46:25 Bug Check String : DRIVER_POWER_STATE_FAILURE Bug Check Code : 0x1000009f Parameter 1 : 00000000`00000004 Parameter 2 : 00000000`00000258 Parameter 3 : fffffa80`07332040 Parameter 4 : fffff800`049d23d0 Caused By Driver : WudfPf.sys Caused By Address : WudfPf.sys+6500 File Description : Product Name : Company : File Version : Processor : x64 Crash Address : ntoskrnl.exe+79d8a Stack Address 1 : Stack Address 2 : Stack Address 3 : Computer Name : Full Path : D:\DMP\020215-57860-01.dmp Processors Count : 4 Major Version : 15 Minor Version : 7601 Dump File Size : 442 624 Dump File Time : 2015-02-02 09:58:57 ================================================== Edytowane 29 Stycznia przez picasso Odnośnik do komentarza
picasso Opublikowano 4 Grudnia 2015 Autor Zgłoś Udostępnij Opublikowano 4 Grudnia 2015 (edytowane) Debugging Tools for Windows Strona domowa Platforma: Windows XP do Windows 11 32-bit i 64-bit Licencja: darmowa Windows SDK for Windows 11 [Do instalacji na Windows 7 i nowszych] Windows SDK for Windows 10 [Do instalacji na Windows 7 i nowszych] Windows SDK for Windows 7 and .NET Framework 4.0 [Do instalacji na XP i Vista] Wsparcie XP i Vista zostało usunięte z najnowszych edycji. Ostatnia wersja obsługująca te systemy to SDK for Windows 7 and .NET Framework 4.0. Debugging Tools for Windows są składową potężnego SDK, aczkolwiek pobrany plik jest typem instalatora webowego, w którym można skonfigurować instalowane składniki. Należy odznaczyć wszystko z wyjątkiem omawianej tu aplikacji: Windows SDK for Windows 11: Windows SDK for Windows 10: Windows SDK for Windows 7 and .NET Framework 4: 1. Po instalacji w Menu Start pojawi się stosowna pozycja, w której wybieramy uruchomienie graficznego interfejsu WinDbg, w zgodnymi z systemem bitami: 2. Następnym krokiem jest doinstalowanie tzw. symboli, które umożliwią dokładniejszą diagnozę. Z menu File > Symbol File Path: Wpisujemy następującą ścieżkę: SRV*Ścieżka*https://msdl.microsoft.com/download/symbols W kolorowe miejsce wstawiamy wybrany przez siebie folder np. C:\Symbole. Debuger, o ile to będzie konieczne, samodzielnie pobierze z internetu wymagane symbole do tegoż właśnie folderu. (uwaga: zrzut ekranu stary i figuruje niezabezpieczony adres http, oczywiście teraz używany https) 3. Czas na otworzenie w debugerze wybranego zrzutu pamięci. Z menu File > Open Crash Dump: Wskazujemy istniejący plik z lokalizacji ustawionej w konfiguracji Zapisywanie informacji o debugowaniu. 4. Wynikowo pojawi się przetransformowana zawartość zrzutu, którą należy uszczegółowić poprzez kliknięcie w !analyze -v. Całość należy przekleić do posta. Jeśli nie potrafisz tego samodzielnie wykonać, zapakuj pliki *.DMP w ZIP i shostuj podając link do pliku. -------------------------------------------------------------------------- PLIKI DO POKAZANIA NA FORUM -------------------------------------------------------------------------- ZIP > zewnętrzny serwis hostingowy Edytowane 29 Stycznia przez picasso Odnośnik do komentarza
picasso Opublikowano 29 Stycznia Autor Zgłoś Udostępnij Opublikowano 29 Stycznia (edytowane) Artykuł w zasadzie nie wymagał żadnych szczególnych dostosowań pod kątem Windows 11, wszystko nadal aktualne. Natomiast nowością jest, że debuger Microsoftu został opublikowany również w wersji samodzielnej. Obecnie więc są dwie postacie WinDbg: WinDbg określany jako "Legacy" bądź "Klasyczny" (po staremu jako składnik instalacji SDK opisanej powyżej) oraz WinDbg jako oddzielny program (opisany poniżej). Obie edycje w najnowszych dostępnych wersjach utylizują ten sam silnik i mają te same możliwości analityczne, lecz mają drastycznie inne interfejsy. Opisywany tu delikwent jest przyjemniejszy dla przeciętnego użytkownika i powinien być wybierany tutaj na forum. WinDbg Strona domowa Platforma: Windows 11, Windows 10 Wersja 1607 i nowsze 64-bit Licencja: darmowa Pobieranie bezpośrednie Pobieranie z Microsoft Store W zależności od metody pobrania, inna postać instalatora: Skutki uruchomienia jednak te same. Program jest lokowany w folderze C:\Program Files\WindowsApps\Microsoft.WinDbg_x.xxxx.xxxxx.x_x64__8wekyb3d8bbwe. Skrót uruchomieniowy jest w menu Start. Póki co, nie wygląda na to by WinDbg był spolszczony (jedna opcja w sposób najwyraźniej przypadkowy wyświetla się po polsku). Uruchomienie okna Microsoft Store nie wykazuje, by były dostępne nowsze aktualizacje. ====================================== Instrukcje debugowania plików *.DMP są nadal takie same, tylko należy nanieść poprawkę na inny interfejs. Czyli: 1. Po instalacji otwiera się ogólny widok w następującej formie: 2. Wybierz pozycję File (Plik), co otworzy wewnętrzne menu: 3. Przejdź do Settings > Debugging settings: 4. W polu Default symbol path wprowadź ścieżkę kierującą na publiczny serwer symboli Microsoftu: srv*https://msdl.microsoft.com/download/symbols Zatwierdź przez OK. 5. Ponownie wybierz pozycję File, następnie Open dump file: 6. Używając przycisku Browse wskaż istniejący plik *.DMP z lokalizacji ustawionej w konfiguracji Zapisywanie informacji o debugowaniu. W przykładzie lokalizacja C:\Windows\Minidump: Kliknij w Open. 7. Debuger zacznie przetwarzać dane. Spodziewane, że pierwsze uruchomienie potrwa dłużej niż kolejne ze względu na pobieranie symboli na dysk, Czekaj cierpliwie aż ukończy pracę i zaserwuje podświetlony link !analyze -v: Kliknij w ten odnośnik i poczekaj na ukończenie pracy. W zależności od danych, może to potrwać. Alternatywnie można wpisać w polu kd> to polecenie i ENTER. 8. Skopiuj zawartość okna do posta. Upewnij się, że kursor jest w obrębie okna, CTRL+A, a następnie CTRL+V do posta. Przykładowy wygląd raportu: Spoiler ************* Preparing the environment for Debugger Extensions Gallery repositories ************** ExtensionRepository : Implicit UseExperimentalFeatureForNugetShare : true AllowNugetExeUpdate : true NonInteractiveNuget : true AllowNugetMSCredentialProviderInstall : true AllowParallelInitializationOfLocalRepositories : true EnableRedirectToChakraJsProvider : false -- Configuring repositories ----> Repository : LocalInstalled, Enabled: true ----> Repository : UserExtensions, Enabled: true >>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds ************* Waiting for Debugger Extensions Gallery to Initialize ************** >>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.015 seconds ----> Repository : UserExtensions, Enabled: true, Packages count: 0 ----> Repository : LocalInstalled, Enabled: true, Packages count: 42 Microsoft (R) Windows Debugger Version 10.0.27725.1000 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\Minidump\012925-7234-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Path validation summary ************** Response Time (ms) Location Deferred srv*https://msdl.microsoft.com/download/symbols Symbol search path is: srv*https://msdl.microsoft.com/download/symbols Executable search path is: Windows 10 Kernel Version 26100 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Kernel base = 0xfffff800`7aa00000 PsLoadedModuleList = 0xfffff800`7b8f4870 Debug session time: Wed Jan 29 10:13:47.883 2025 (UTC + 1:00) System Uptime: 7 days 5:29:45.356 Loading Kernel Symbols ............................................................... ................................................................ ................................................................ .......... Loading User Symbols PEB is paged out (Peb.Ldr = 000000cd`e3b2e018). Type ".hh dbgerr001" for details Loading unloaded module list .................................................. For analysis of this file, run !analyze -v nt!KeBugCheckEx: fffff800`7aeb85d0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffff000`a69c14e0=00000000000000c2 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* BAD_POOL_CALLER (c2) The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc. Arguments: Arg1: 000000000000000d, Attempt to release quota on a corrupted pool allocation. Arg2: ffffb882d8c0b510, Address of pool Arg3: 000000004b677844, Pool allocation's tag Arg4: ff73a68a4dfa40c0, Quota process pointer (bad). Debugging Details: ------------------ KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 1421 Key : Analysis.Elapsed.mSec Value: 1435 Key : Analysis.IO.Other.Mb Value: 8 Key : Analysis.IO.Read.Mb Value: 1 Key : Analysis.IO.Write.Mb Value: 30 Key : Analysis.Init.CPU.mSec Value: 1312 Key : Analysis.Init.Elapsed.mSec Value: 594191 Key : Analysis.Memory.CommitPeak.Mb Value: 95 Key : Analysis.Version.DbgEng Value: 10.0.27725.1000 Key : Analysis.Version.Description Value: 10.2408.27.01 amd64fre Key : Analysis.Version.Ext Value: 1.2408.27.1 Key : Bugcheck.Code.LegacyAPI Value: 0xc2 Key : Bugcheck.Code.TargetModel Value: 0xc2 Key : Dump.Attributes.AsUlong Value: 21008 Key : Dump.Attributes.DiagDataWrittenToHeader Value: 1 Key : Dump.Attributes.ErrorCode Value: 0 Key : Dump.Attributes.KernelGeneratedTriageDump Value: 1 Key : Dump.Attributes.LastLine Value: Dump completed successfully. Key : Dump.Attributes.ProgressPercentage Value: 0 Key : Failure.Bucket Value: 0xc2_d_dxgkrnl!DXGDEVICE::DestroyDeferredAllocations Key : Failure.Hash Value: {0dfb9eb5-f5b2-9ea1-051a-45dd0caf5a53} BUGCHECK_CODE: c2 BUGCHECK_P1: d BUGCHECK_P2: ffffb882d8c0b510 BUGCHECK_P3: 4b677844 BUGCHECK_P4: ff73a68a4dfa40c0 FILE_IN_CAB: 012925-7234-01.dmp DUMP_FILE_ATTRIBUTES: 0x21008 Kernel Generated Triage Dump FAULTING_THREAD: ffffa68a502e7080 BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 CUSTOMER_CRASH_COUNT: 1 PROCESS_NAME: firefox.exe STACK_TEXT: fffff000`a69c14d8 fffff800`7b5389f8 : 00000000`000000c2 00000000`0000000d ffffb882`d8c0b510 00000000`4b677844 : nt!KeBugCheckEx fffff000`a69c14e0 fffff800`0dec01f2 : ffffb882`d8c0b510 ffffb882`d8c0b510 ffffb882`d1000000 00000000`00000000 : nt!ExFreePoolWithTag+0xd38 fffff000`a69c15d0 fffff800`0dec1a10 : ffffa68a`48098760 ffffa68a`48098cd0 ffffa68a`48098cd0 ffffa68a`48098760 : dxgkrnl!DXGDEVICE::DestroyDeferredAllocations+0x472 fffff000`a69c1860 fffff800`0dec2dbe : 00000000`00000000 ffffa68a`48098760 ffffa68a`417bab60 ffffa68a`417bab60 : dxgkrnl!ADAPTER_RENDER::DeferredDestructionWork+0x11c fffff000`a69c1910 fffff800`7ad704a2 : ffffa68a`502e7080 ffffa68a`417bab00 ffffa68a`00000000 ffffa68a`00000000 : dxgkrnl!DxgkpDeferredDestructionWork+0xe fffff000`a69c1940 fffff800`7ae5585a : ffffa68a`502e7080 ffffa68a`502e7080 fffff800`7ad702f0 ffffa68a`417bab60 : nt!ExpWorkerThread+0x1b2 fffff000`a69c1af0 fffff800`7b07ae54 : ffff8580`ea759180 ffffa68a`502e7080 fffff800`7ae55800 00000000`00000000 : nt!PspSystemThreadStartup+0x5a fffff000`a69c1b40 00000000`00000000 : fffff000`a69c2000 fffff000`a69bb000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34 SYMBOL_NAME: dxgkrnl!DXGDEVICE::DestroyDeferredAllocations+472 MODULE_NAME: dxgkrnl IMAGE_NAME: dxgkrnl.sys IMAGE_VERSION: 10.0.26100.2454 STACK_COMMAND: .process /r /p 0xffffa68a416cd040; .thread 0xffffa68a502e7080 ; kb BUCKET_ID_FUNC_OFFSET: 472 FAILURE_BUCKET_ID: 0xc2_d_dxgkrnl!DXGDEVICE::DestroyDeferredAllocations OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {0dfb9eb5-f5b2-9ea1-051a-45dd0caf5a53} Followup: MachineOwner --------- ====================================== Edytowane 3 Lutego przez picasso Odnośnik do komentarza
Rekomendowane odpowiedzi