/u/8033/neo.JPG?f=community)
FAQ: Windows Crash/Memory dumps FAQ
Inleiding
Windows NT achtige (2000/xp) systemen geven een BSOD (Blue Screen Of Death) als het systeem niet meer garant kan staan voor het correct functioneren van het systeem. Om evt data corruptie te voorkomen wordt het systeem dan stil gelegd. En de gebruiker getrakteerd op het "Wow hier ging iets *HEEL* erg mis"-BSOD.
Oorzaken
Rotte drivers
De nr.1 oorzaak van crashes zijn rotte drivers, ook hardware fabrikanten zijn niet perfect en willen nog wel es een rotte (meestal niet signed) driver ophoesten. de WHQL (getest door ms) drivers geven iets meer garantie dat er weinig/geen bugs in zitten maar helemaal uitgesloten is het nooit.
Rotte Hardware
Rotte of tever overclockte hardware wil nog wel eens voor onstabile situaties zorgen waar drivers niet opgerekend hebben en over hun nek gaan of er treed gewoon corruptie van het werkgeheugen op, de cpu doet verkeerde/onvoorspelbare dingen omdat ie het te heet heeft ect ect ect...Onvoorspelbare situaties houd nt niet zo van en geeft je een BSOD.
Bugs in het OS
Ook microsoft is niet perfect (big surprise here) en laat nog wel es een foutje zitten hier en daar.
Instellen
De instellingen aangaande crashes zijn in te stellen in het system properties scherm (Rechts klikken op my computer, properties, Advanced, Startup and recovery, settings). De enige echt interessante opties hier zijn bij het dump type de mogelijkheid tot automatishe reboot na een crash en het vinkje voor het automatish overschrijven van oude dumps, als deze optie niet aanstaat en er is al een oude dump aanwezig op het systeem zal er *GEEN* nieuwe gemaakt worden (geld alleen voor full en kernel memory dump)
Soorten Crash Dumps
- Full memory dump. (default voor NT4)
Hierbij wordt het complete interne geheugen weggeschreven naar disk.De dump wordt echter alleen gemaakt als de grote van de paging file groter is dan de grote van het fysieke geheugen + 1 megabyte (paging file moet dus minimaal 129mb zijn op een pc met 128mb geheugen). De dump die aangemaakt wordt zal (meestal afhangkelijk van de instellingen) in je X:\winnt map geplaatst worden met de naam Memory.dmp. Let wel op dat de optie - Kernel memory dump (vanaf windows 2000)
Hierbij wordt alleen de stukken geheugen weggeschreven die gebruikt worden door kernel mode drivers/componenten. Deze optie is toegevoegd omdat het interne geheugen steeds groter werd en het soms nogal problematish werd om bv een dump van een pc met bv 2 gig ram bij support personeel of microsoft te krijgen. Dit imho de beste optie om kiezen een dump van handelbare grote maar met toch voldoende informatie om de oorzaak van je bsod te achterhalen. De dump die aangemaakt wordt zal (meestal afhangkelijk van de instellingen) in je X:\winnt map geplaatst worden met de naam Memory.dmp - Small memory dump. (vanaf windows 2000,default voor XP/2000)
Dit is een dump van 64kb waar de meest belangrijke informatie zoals active drivers in het geheugen een stacktrace de active thread toen de bsod gebeurde. De dump die aangemaakt wordt zal (meestal afhangkelijk van de instellingen) in je X:\winnt\minidumps map geplaatst worden met de naam miniMMDDYY-NN.dmp. waar MMDDYY voor de huidige datum staat en NN voor de nummer van de crash die dag. - None
Geen dump. Er wordt geen informatie weggeschreven aangaande de crash en het os zal aan de hand van de gekozen opties rebooten of in het bsod blijven hangen.
Ja leuk maar wat doe ik er aan?
Als het een eenmalige crash is zou ik zeggen zand er over niet meer naar kijken maar als het een regelmatig terug kerend iets is wordt het toch wel een beetje irritant en kunnen we de informatie uit de dump analyseren om er achter te komen waarom onze pc het niet zo naar z'n zin heeft.
Tools
Om uit te vinden waar de BSOD vandaan komt hebben we wat dingen nodig:
- Debugging Tools for Windows (ik heb 4.0 beta 1 gebruikt maar pak maar gewoon de nieuwste die je vinden kan) te verkrijgen op:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx - Symbol files
te verkrijgen op http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx
Download hier de symbol files passend bij het operating systeem/service pack wat je draait *note werkt niet in firefox/opera wegens het keuze menu*.
De installatie spreekt redelijk voor zich en zal daar ook geen woorden over vuilmaken.
Windbg
Na het starten van windbg hebben gestart gaan we naar
File->Symbol file path en vullen de de directory in waar de symbols geinstaleerd staan (waarschijnlijk c:\winnt\symbols).
In de 4.0 beta versie van de tols kan je ook SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols invullen waarna de debugger de informatie die ie nodig heeft zelf zal downloaden bij microsoft en deze in c:\websymbols plaatsen.
Vervolgens vullen we bij File ->image file path het path in waar windows geinstaleerd staat. (C:\winnt waarschijnlijk)
waarna we File->Open Crashdump onze crashdump kunnen openen. Ik heb ter illustratie een van m'n eigen mini dumps geanalyseerd. Na het openen zal windbg automatish een korte analyse geven van de dump. deze is later nog es op te roepen door !kanalyzebugcheck
Bugcheck Analysis
Use !analyze -v to get detailed debugging information.
BugCheck 100000EA, {81600708, 814b43a8, 8179f888, 1}
Probably caused by : nv4_disp ( nv4_disp+2dddb )
Followup: MachineOwner
---------
Okay NV4_DISP ging op zijn plaat dit keer dus, toch maar es checken of er al een driver update is van nvidia >:) . Als je meer techishe info wil weten of deze informatie wil door sturen naar de hardware fabrikant. Staan er nog wat handige commando's tot je beschikking.
!drivers geeft een overzicht van alle geladen drivers in het geheugen op het moment van de crash met de datum/tijd dat ze gecreeerd zijn. In dit geval is nv4_disp.dll gedateerd Thu Sep 20 02:03:17 2001. Deze informatie is vrij handig zodat zowel jij als de fabrikant over de zelfde versie van de driver spreken.
!analyze -v Geeft een uitgebreidere analyze van de crash.Als je van technishe termen houd is dit the place to be ;)
Bugcheck Analysis
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The argumentes are already printed out to the kernel
debugger. You can also retrieve them from watchdog's global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possble to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR routine is running at the time of
the bugcheck (this is because watchdog's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 81600708, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 814b43a8, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 8179f888, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
Debugging Details:
------------------
Faulting Thread address: 81600708
Faulting thread:
Cannot read thread type from thread 81600708, HRESULT 0x80004005
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
f564ebc8 bf9efe28 nv4_disp+0x2dddb
f564ebd4 bfa0813c nv4_disp+0x37e28
f564ebf8 804db47b nv4_disp+0x5013c
e1996100 000041a8 nt!CcPfLogPageFault+0x85
Implicit thread is now 817cbb30
Last Control Transfer from bf9efe28 to bf9e5ddb
Failure Image Name nv4_disp
Failure Module Name nv4_disp
BUCKET ID: 0xEA_IMAGE_nv4_disp_TS_3BA93245
Command to show faulting stack:
-------------------------------
.thread ffffffff81600708 ; kb
Probably caused by : nv4_disp ( nv4_disp+2dddb )
Followup: MachineOwner
---------
!process Laat informatie zien van het active process toen de BSOD plaatsvond. Dit is alleen mogelijk met kernel/fulldumps.
Ter afsluiting
Door het analyseren van crashdumps zullen de bsod's niet als sneeuw voor de zon verdwijnen, je zal alleen iets beter weten in welke richting je de oorzaak moet zoeken, succ6!
Thanks to
Met dank aan Yarvieh voor het schrijven van dit duidelijke stuk :)
Lijst met figuren
- Geen figuren gevonden
Inhoudsopgave
[ Voor 52% gewijzigd door sanfranjake op 08-10-2008 21:39 ]
Dit topic is gesloten.