(Vermutlich kein)BSOD durch TC od. Wer kann Dumps auswerten?

[Hot-Doc]

Bei den ganzen Profis hier, traue ich mich ja kaum überhaupt zu antworten.

Nur als kurze Anmerkung, da bei Dir (angeblich) zwei verschiedene Dateien für die Abstürze verantwortlich sein sollen - so etwas hatte ich vor nicht allzu langer Zeit leider auch - nur lag es damals nicht an entsprechden Gerätetreibern sondern an Datenkorrumption auf der Festplatte (Serial ATA Raid auf einem NForce Board...). Erstaunlicherweise reichten eine BIOS-Änderung und ein Checkdisk-Durchlauf und die Probleme waren verschwunden.

[rellek]

@ Christian: Danke für die Anleitung Hilft zukünftig bestimmt weiter
Hab mal aus Spaß an der Freude den Dump ge-debug-t...
Er zeigt jetzt das an:

Code: Select all

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


Loading Dump File [C:\WINDOWS\Minidump\Mini020806-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: 
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x80800000 PsLoadedModuleList = 0x8087c1a0
Debug session time: Wed Feb  8 19:43:57.390 2006 (GMT+1)
System Uptime: 0 days 9:39:54.977
Loading Kernel Symbols
....................................................................................................................................................
Loading User Symbols
Loading unloaded module list
..................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000000A, {9b451008, 2, 1, 808479ef}

Probably caused by : win32k.sys ( win32k!SURFACE::bDeleteSurface+188 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 9b451008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 808479ef, address which referenced memory

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


WRITE_ADDRESS:  9b451008 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReleasePageFileSpace+55
808479ef 213e             and     [esi],edi

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

LAST_CONTROL_TRANSFER:  from 80847f1d to 808479ef

STACK_TEXT:  
ba014928 80847f1d 00000000 aa000000 00ca3000 nt!MiReleasePageFileSpace+0x55
ba014960 80848090 c0006518 00ca3000 00000000 nt!MiDeletePte+0x499
ba014a24 8083f641 00000018 00cc1fff 00000000 nt!MiDeleteVirtualAddresses+0x164
ba014a40 808d02ec 00ca0000 00cc1fff ba014b00 nt!MiDeleteFreeVm+0x1d
ba014ae8 80865808 ffffffff ba014bc8 ba014bd4 nt!NtFreeVirtualMemory+0x42e
ba014ae8 80826901 ffffffff ba014bc8 ba014bd4 nt!KiFastCallEntry+0xf8
ba014b70 bf80b855 ffffffff ba014bc8 ba014bd4 nt!ZwFreeVirtualMemory+0x11
ba014bcc bf80b8c0 00000000 f90508db ba014bf0 win32k!SURFACE::bDeleteSurface+0x188
ba014bdc bf8c195b 00000001 00000002 e2644e80 win32k!SURFREF::bDeleteSurface+0x12
ba014bf0 bf8c14ed 00000c5c 00000001 e177d008 win32k!vCleanupSurfaces+0x33
ba014c10 bf8bfba8 e177d008 00000000 00000000 win32k!NtGdiCloseProcess+0x6d
ba014c28 bf820f1c e177d008 00000000 85bcc508 win32k!GdiProcessCallout+0xea
ba014c44 808effb1 84ef5b90 00000000 86880238 win32k!W32pProcessCallout+0x5c
ba014cf0 808f02f1 40010004 ba014d4c 808260bb nt!PspExitThread+0x423
ba014cfc 808260bb 86880238 ba014d48 ba014d3c nt!PsExitSpecialApc+0x23
ba014d4c 80865871 00000001 00000000 ba014d64 nt!KiDeliverApc+0x1af
ba014d4c 7c91eb94 00000001 00000000 ba014d64 nt!KiServiceExit+0x58
WARNING: Frame IP not in any known module. Following frames may be wrong.
00c7f7f0 00000000 00000000 00000000 00000000 0x7c91eb94


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!SURFACE::bDeleteSurface+188
bf80b855 e964ffffff       jmp win32k!SURFACE::bDeleteSurface+0x1a8 (bf80b7be)

FAULTING_SOURCE_CODE:  


SYMBOL_STACK_INDEX:  7

FOLLOWUP_NAME:  MachineOwner

SYMBOL_NAME:  win32k!SURFACE::bDeleteSurface+188

MODULE_NAME:  win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  43446a58

FAILURE_BUCKET_ID:  0xA_W_win32k!SURFACE::bDeleteSurface+188

BUCKET_ID:  0xA_W_win32k!SURFACE::bDeleteSurface+188

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

In der Tat, da ist schon mehr zu erkennen. Und jetzt heißt der Übeltäter auch auf einmal win2k.sys *g*

@ Hot-Doc: Naja, ich habs ja auch nicht geglaubt, aber Memtest hatte zu Weihnachten null Fehler gebracht, heute dann plötzlich über 4000.... Das wird wohl der Grund sein, denk ich...

[ghisler(Author)]

Also gemäss dem Stacktrace (GDI...) deutet das eher auf Probleme mit dem Grafiktreiber hin. Haben Sie da kürzlich was geändert?

[rellek]

Hi,

nene, passt schon - habe nichts am Grafiktreiber geändert - das Problem hat sich inzwischen im (mittlerweile?!) defekten 2. RAM-Riegel lokalisiert... Obwohl er - wie gesagt - zu Weihnachten definitiv stabil und ohne Probleme bei Memtest ging.
Ein neuer Satz RAM ist bereits unterwegs.

Danke für die Hilfe!

MfG