Jag mötte en blåskärm (eller hur man debuggar en stopkod)

[Rikard]

När jag orkar ska jag skriva detta tydligare och därefter lägga till det i min FAQ.

För några minuter sedan presenterades jag för en blåskärm på min IBM med Windows XP Professional!
För att sprida kunskapen om hur man hanterar detta så tänkte jag publicera hur jag går till väga för att reda ut detta.

1. Jag låter blåskärmen vara till dess datorn startar om per automatik. (Självklart har jag inställt att datorn ska göra det efter att ha loggat en minidump-fil)
2. När jag har loggat in så möts jag av OSts önskemål om att få skicka informationen till Microsoft, vilket naturligtvis sker. Om du är paranoid och tror att pyttemjuk avser att nyttja denna information mot dig har du fel. Så är det bara.
3. Om du inte redan har installerat Micrsoft Debugging Tools, gör det. http://www.microsoft.com/whdc/ddk/de...g/default.mspx
   Microsoft Debugging Tools startas.
4. För att kunna genomföra en debug så behöver du de symbolfiler som är kopplade till operativet. Vilka är nu dessa? Det spelar inte så stor roll. Det kan hanteras per automagik.
   När du har startat Debugging Tools, gå till file-menyn. Välj "Symbol File Path...". Skriv in följande rad: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols och klicka på OK. (Om du inte redan har en katalog som heter websymbols i rooten, skapa den.
5. Öppna nu dumpfilen som ligger i C:\Windows\Minidump. (File - Open Crash Dump...) Detta kan ta en stund eftersom Debugging Tools kommer att ladda hem de symbolfiler som krävs. När allt är klart ska det stå "kd>" långt ner till vänster i Debug-fönstret och en Disassembly-ruta har dykt upp.
6. Följ nu instruktionen genom att skriva !analyze -v.
7. Ofta kan man utläsa av det resultat som dyker upp exakt vad som är fel, i mitt fall:[kod]kd> !analyze -v
   ************************************************************ *******************
   * *
   * 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 KeBugCheckE)
   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
   KeBugCheckE) is not called the .bugcheck directive will not return bugcheck
   information in this case. The arguments are already printed out to the kernel
   debugger. You can also retrieve them from a global variable via
   "dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
   On MP machines it is possible to hit a timeout when the spinning thread is
   interrupted by hardware interrupt and ISR or DPC routine is running at the time
   of the bugcheck (this is because the timeout'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: 82624718, Pointer to a stuck thread object. Do .thread then kb on it to find
   the hung location.
   Arg2: 829a7008, Pointer to a DEFERRED_WATCHDOG object.
   Arg3: 82ac0530, Pointer to offending driver name.
   Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
   
   Debugging Details:
   ------------------
   
   Database SolnDb not connected
   
   FAULTING_THREAD: 82624718
   
   IMAGE_NAME: s3gsavmx.dll
   
   DEBUG_FLR_IMAGE_TIMESTAMP: 3e30f8a8
   
   MODULE_NAME: s3gsavmx
   
   FAULTING_MODULE: bf99e000 s3gsavmx
   
   DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
   
   BUGCHECK_STR: 0xEA
   
   LAST_CONTROL_TRANSFER: from 804f43f7 to 805313cf
   
   STACK_TEXT:
   f3e476f0 804f43f7 00000000 f7ae6c0c 00000000 nt!KiUnlockDispatcherDatabase+0x77
   f3e47700 f7276830 f7ae6c2c 00000000 00000000 nt!KeSetEvent+0x73
   f3e479f0 804f816d f7ae6bdc f3e47a3c f3e47a30 watchdog!WatchdogKernelApc+0xf2
   f3e47a40 806b138c 00000000 00000000 f3e47a58 nt!KiDeliverApc+0xb1
   f3e47a40 806ac383 00000000 00000000 f3e47a58 hal!HalpApcInterrupt2ndEntry+0x31
   f3e47adc f74ac56a 00000010 f7d56004 e1146010 hal!HalpAcpiTimerStallExecProc+0x63
   WARNING: Stack unwind information not available. Following frames may be wrong.
   f3e47adc f74ac56a 00000010 f7d56004 e1146010 s3gsavm+0x456a
   f3e47afc bf99e53d f7d56004 0000e3db 000000c8 s3gsavm+0x456a
   f3e47b40 bf9a19f9 e1146010 f3e47b80 ffffffc0 s3gsavmx+0x53d
   00000000 00000000 00000000 00000000 00000000 s3gsavmx+0x39f9
   f3e48690 8057d4c1 f3e48718 f3e4871c f3e4872c nt!KiCallUserMode+0x4
   f3e486ec bf805674 00000002 f3e4873c 00000018 nt!KeUserModeCallback+0x87
   f3e4876c bf895d1f bc64d4c0 0000000f 00000000 win32k!SfnDWORD+0xa0
   f3e487b4 bf802802 4064d4c0 0000000f 00000000 win32k!xxxSendMessageToClient+0x174
   f3e48800 bf80a4c6 bc64d4c0 0000000f 00000000 win32k!xxxSendMessageTimeout+0x1a6
   f3e48820 bf807c4b bc64d4c0 0000000f 00000000 win32k!xxxSendMessage+0x1a
   f3e4884c bf807d5c bc64d4c0 00000001 00eaf090 win32k!xxxUpdateWindow2+0x77
   f3e4886c bf807ce9 bc64d4c0 00000001 bf807daa win32k!xxxInternalUpdateWindow+0x6d
   f3e48878 bf807daa bc64d4c0 00eaf090 f3e48bfc win32k!xxxUpdateWindow+0xb
   f3e48894 8052d571 00010116 0000005e 00000286 win32k!NtUserCallHwndLock+0x49
   f3e48894 7ffe0304 00010116 0000005e 00000286 nt!KiSystemService+0xc4
   00eaf0c4 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
   f3e48b5c 8057d4c1 f3e48be4 f3e48be8 f3e48bf8 nt!KiCallUserMode+0x4
   f3e48bb8 bf805674 00000002 f3e48c08 00000018 nt!KeUserModeCallback+0x87
   f3e48c38 bf807e76 bc6b1e38 0000007f 001792e0 win32k!SfnDWORD+0xa0
   f3e48cac bf892dd4 e188c008 f3e48d64 00000000 win32k!xxxReceiveMessage+0xb5
   f3e48ce8 bf8730c0 f3e48d14 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x1ce
   f3e48d48 8052d571 00eaff2c 00000000 00000000 win32k!NtUserPeekMessage+0x40
   f3e48d48 7ffe0304 00eaff2c 00000000 00000000 nt!KiSystemService+0xc4
   00eafed8 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
   
   
   STACK_COMMAND: .thread ffffffff82624718 ; kb
   
   FOLLOWUP_NAME: MachineOwner
   
   BUCKET_ID: 0xEA_IMAGE_s3gsavmx.dll_DATE_1_24_2003
   
   Followup: MachineOwner
   ---------[/kod] (Ska jag vara helt ärlig, så är nog inte denna dump så värst bra som exempel då den kan peka på helt fel fel... )
8. Mycket tyder i detta fall på att det är grafikdrivrutinen s3gsavmx.dll som strular. Inte helt omöjligt...
9. Nästa steg är att slå på Verifier för denna drivrutin för att försöka fånga felet tidigare nästa gång. Debuggen avslutas.
10. Start - Run - "Verifier" - Enter.
11. "Create Standard..." Next.
12. "Automatically select unsigned..." Next.
13. Jag väljer "s3gsavmx.dll" i listan och klickar på "Finish".
14. En omstart krävs för att verifiern ska göra nytta - starta om.

En vacker dag ska jag tala om varför man gör allt detta.

[frankof]

*imponerad*
Men nu behöver inte jag göra detta, för du har ju gjort det och skickat resultatet til MS som tar drivrutinsförfattaren i örat och allt blir perfekt sedan ( )
[citat=Rikard]En vacker dag ska jag tala om varför man gör allt detta.[/citat]
*väntar på en vacker dag*

[Rikard]

[citat=frankof]*imponerad*
Men nu behöver inte jag göra detta, för du har ju gjort det och skickat resultatet til MS som tar drivrutinsförfattaren i örat och allt blir perfekt sedan ( )[/citat]
Det hänger väl på om vi har exakt samma version av drivrutinen eller inte?

[frankof]

[citat=Rikard]
Det hänger väl på om vi har exakt samma version av drivrutinen eller inte? [/citat]
Jo, jag vet, men jag är fortfarande impad, och väntar på en vacker dag

[Peeer]

Väldigt praktiskt!

[Nicrosoft]

[citat=frankof][citat=Rikard]
Det hänger väl på om vi har exakt samma version av drivrutinen eller inte? [/citat]
Jo, jag vet, men jag är fortfarande impad, och väntar på en vacker dag [/citat]

Här är det en väldigt vacker dag

[Peeer]

Kan man ladda ner symbolerna manuellt? Isf var och hur?

/r hittade http://www.microsoft.com/whdc/ddk/de...symbolpkg.mspx men [citat]Because of the size of the download package and required temporary files, it is recommended that you have at least 1 GB of disk space free before downloading and installing each symbol package.[/citat]. Ska det verkligen krävas så mycket utrymme? Sen fungerade visst inte downloadlänkarna på den siten heller

[Nexus86]

Men om det är en signerad drivrutin som krånglar då?

Jag har signerade drivrutiner till mitt nVidia Riva TNT2 Model 64 men ändå har jag fått blåskärm 2 ggr på 3 dagar nu.

[Rikard]

Hur vet du att det är den drivrutinen då?
Det är inte alltid det första preliminära resultatet är det korrekta. Ibland visar det fel varpå man får göra en mer utvecklad felsökning.

[yaz]

rikard har en poäng där, förstås

felmeddelandet som dyker upp och den riktiga orsaken kan vara rätt skilda.

min egna erfarenhet.. http://www.webforum.nu/showthread.ph...642#post845642

[Nexus86]

Okej då, jag är inte säker men jag gissar att det är det.

Observera det fetstilta.

[kod]kd> !analyze -v
************************************************************ *******************
* *
* Bugcheck Analysis *
* *
************************************************************ *******************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
that an unaligned data reference was encountered. The trap frame will
supply additional information.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf83ffd3, The address that the exception occurred at
Arg3: f08e6c68, Trap Frame
Arg4: 00000000

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instruktionen p "0x%08lx" refererade till minnet p "0x%08lx". Det gick inte att utf ra en minnes tgärd. F ljande fel returnerades: The memory could not be "%s".

FAULTING_IP:
win32k!EngCopyBits+1f6
bf83ffd3 33c9 xor ecx,ecx

TRAP_FRAME: f08e6c68 -- (.trap fffffffff08e6c68)
ErrCode = 00000000
eax=00000000 ebx=e167a118 ecx=00000004 edx=e167a118 esi=00000000 edi=f08e6f98
eip=bf83ffd3 esp=f08e6cdc ebp=f08e6e84 iopl=0 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!EngCopyBits+0x1f6:
bf83ffd3 33c9 xor ecx,ecx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 806b7dac to bf83ffd3

STACK_TEXT:
f08e6f30 806b7dac e10377f0 e23da370 000002cc win32k!EngCopyBits+0x1f6
f08e6f5c bf81e1d0 e23da370 e10ee018 00000000 hal!HalEndSystemInterrupt+0x54
f08e6fa4 bf81db92 bf9bf130 f08e704c e10377f0 win32k!OffCopyBits+0x7b
f08e7058 bf81e50a e10377f0 e10ee018 00000000 win32k!SpBitBlt+0xfa
f08e708c bf83327f e10377f0 e10ee018 00000000 win32k!SpCopyBits+0x25
f08e72d0 bf8aba68 f08e73d4 e10ee018 00000000 win32k!EngStretchBlt+0x6a8
f08e73f8 bf870827 e10ee008 00000000 00000000 win32k!psSetupTransparentSrcSurface+0x385
f08e7638 bf9bf9ea e168c008 e168c008 f08e77c8 win32k!EngTransparentBlt+0xea
WARNING: Stack unwind information not available. Following frames may be wrong.
00000001 00000000 00000000 00000000 00000000 nv4_disp+0x79ea
f08e7bf0 80584539 f08e7c78 f08e7c7c f08e7c8c nt!KiCallUserMode+0x4
f08e7c4c bf8733cd 00000002 f08e7c9c 00000018 nt!KeUserModeCallback+0x87
f08e7ccc bf8722a5 bc603478 0000000f 00000000 win32k!SfnDWORD+0xa0
f08e7d0c bf873b38 6c75ac58 f08e7d64 0006fe24 win32k!xxxDispatchMessage+0x1c0
f08e7d58 804d4e91 0006fe7c 00000000 00000000 win32k!NtUserDispatchMessage+0x39
f08e7d58 7ffe0304 0006fe7c 00000000 00000000 nt!KiSystemService+0xc4
0006fe5c 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4


FOLLOWUP_IP:
nv4_disp+79ea
bf9bf9ea ?? ???

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nv4_disp+79ea

MODULE_NAME: nv4_disp

IMAGE_NAME: nv4_disp.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 4061d5ac

STACK_COMMAND: .trap fffffffff08e6c68 ; kb

BUCKET_ID: 0x8E_nv4_disp+79ea

Followup: MachineOwner[/kod]

[Rikard]

zip tack.

[Nexus86]

[citat=Rikard]zip tack. [/citat]
Coming right up!

[Rikard]

En sak i taget:

Kontrollera loggarna och se om du kan hitta något där. Har du tillräckligt med diskutrymme på disken?

1. Stäng av memory BIOS caching/shadowing i BIOS.
Testa.

2. Byt drivrutin och testa med en äldre eller en senare.
Testa.

Det kan även vara hårdvara som inte är kompisar med varandra. Har du nyligen satt i en minnesmodul eller någon annan hårdvara i datorn?

[Nexus86]

[citat=Rikard]Det kan även vara hårdvara som inte är kompisar med varandra. Har du nyligen satt i en minnesmodul eller någon annan hårdvara i datorn?[/citat]
Haha, hela innehållet typ. Utom hårddisken och grafikkortet. Resten är nytt. Men jag testar det andra får vi se om det fortsätter.