BSOD memory dump (minidump gedebugged met windbg)

[Cooperator]

Bij het draaien van quickpar (heb de nieuwste versie), crasht het systeem telkens bij het repareren van grote bestanden (zoals dvd's), waarbij je reparatieblokken nodig hebt van in totaal meer dan 100mb. Dan volgt er een BSOD waarin er een memory dump wordt gemaakt (mini-dump).

Ook bij het draaien van Memtest 3.1 krijg ik zo'n BSOD.

Nu heb ik met een debug tool informatie weten te halen uit de dumpfile, maar ikzelf begrijp daar niks van. Misschien dat iemand van jullie er wel wijs uit kan en mij kan vertellen wat het probleem is?

Zou trouwens wel merkwaardig zijn als het geheugen niet goed blijkt te zijn. Die is namelijk erg nieuw en van topkwaliteit (Corsair 2x512mb TwinX Matched Memory Pair 2-2-2-5 latency).
Dit alles op een Asus P4P800 Deluxe mobo en Pentium 4 2,8Ghz cpu met HT.

Hier de debug info:

WARNING: Inaccessible path: 'C:\Program Files\Debugging Tools for Windows\symbols*http://msdl.microsoft.com/download/symbols'

Loading Dump File [C:\WINDOWS\Minidump\Mini042005-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\Program Files\Debugging Tools for Windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp2.030422-1633
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054a230
Debug session time: Wed Apr 20 01:53:36.093 2005 (GMT+2)
System Uptime: 0 days 0:19:13.775
Loading Kernel Symbols
................................................................................................................................
Loading unloaded module list
........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 805cea9a, eb033a80, 0}

Unable to load image a347bus.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for a347bus.sys
*** ERROR: Module load completed but symbols could not be loaded for a347bus.sys
Probably caused by : memory_corruption

Followup: memory_corruption
---------

1: 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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 805cea9a, The address that the exception occurred at
Arg3: eb033a80, Trap Frame
Arg4: 00000000

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - De instructie op 0x%08lx verwijst naar geheugen op 0x%08lx. De lees- of schrijfbewerking ("%s") op het geheugen is mislukt.

FAULTING_IP:
nt!SeCreateAccessState+60
805cea9a 108943188d43 adc [ecx+0x438d1843],cl

TRAP_FRAME: eb033a80 -- (.trap ffffffffeb033a80)
ErrCode = 00000002
eax=00000001 ebx=851d0ee9 ecx=00000005 edx=e1002a84 esi=851d0f9c edi=e1002a80
eip=805cea9a esp=eb033af4 ebp=eb033b00 iopl=0 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010283
nt!SeCreateAccessState+0x60:
805cea9a 108943188d43 adc [ecx+0x438d1843],cl ds:0023:438d1848=??
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 8059da27 to 805cea9a

STACK_TEXT:
eb033b00 8059da27 851d0ee8 851d0f9c 00000009 nt!SeCreateAccessState+0x60
eb033b38 8055b4b3 00000000 00000000 80534800 nt!ObOpenObjectByName+0x8d
eb033bb4 8055bc2e eb033d68 00000080 eb033d40 nt!IopCreateFile+0x407
eb033bfc 8055f14b eb033d68 00000080 eb033d40 nt!IoCreateFile+0x36
eb033c3c f781bc2b eb033d68 00000080 eb033d40 nt!NtOpenFile+0x25
WARNING: Stack unwind information not available. Following frames may be wrong.
eb033d68 00000080 eb033da8 eb033da4 00000000 a347bus+0x1c2b


CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
805cea95 - nt!SeCreateAccessState+5b
[ 8b:83 ]
1 error : !nt (805cea95)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: ONE_BIT

STACK_COMMAND: .trap ffffffffeb033a80 ; kb

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_ONE_BIT

BUCKET_ID: MEMORY_CORRUPTION_ONE_BIT

Followup: memory_corruption
---------

[Bergen]

Het lijkt me beter om memtest dan even vanaf een floppy te draaien. Dan heb je geen 'last' van Windows en dus niet van BSODs.

[Night89]

ik had ook vastlopers met een asus p4p800 del, maar dan totaal random (newsleecher,quickpar, tiepen,web,email enz)

heb nu net vandaag (gister ) een P4 P 800 E Deluxe gekocht, en is nog niet opnieuw opgestart :-)

zie ook dit topic:

URL

[SWAT]

Ik ben het eens met Bergen. Probeer Memtest 3.2 eens van floppy/CDRW te draaien en dan 24 uur lang ofzo. Blijf in het begin (eerste minuut) wel ff kijken of alles goed gaat en of je geen errors krijgt. Voor hetzelfde geld ligt het aan een RAM instelling (of tweaking van de latency's) of eraan dat het RAM op een gegeven moment TE warm wordt.

[Kuip]

Probeer het geheugen eens op 2-3-3-6 te zetten voordat je memtest draait. Dit is de door Corsair geadviseerde latency voor dat geheugen op een Pentium systeem.

[Cooperator]

Kuip schreef op woensdag 20 april 2005 @ 10:55:
Probeer het geheugen eens op 2-3-3-6 te zetten voordat je memtest draait. Dit is de door Corsair geadviseerde latency voor dat geheugen op een Pentium systeem.

Dat is de geadviseerde latency? Waarom dan het duurste geheugen kopen met een latency van 2-2-2-5 als ze zelf adviseren het op 2-3-3-6 te draaien?

Wat betreft mijn mobo, ik heb geen last van random vastlopers, het is puur met Quickpar en de wat langer durende reparaties en blijkbaar ook met het draaien van Memtest in Windows. Ik heb het geheugen gekocht in maart dit jaar. (pc is defect geweest van 1 tot 13 april, bleek defecte voeding te zijn) Voordat ik die geheugen erin had gestopt, heb ik nog nooit deze BSOD's gehad met dat memory dump. En had ik voor zover ik kan herinneren ook nooit problemen met quickpar. Dat begon met dit nieuwe geheugen als ik me goed herinner.

Ik zal proberen de latency op 2-3-3-6 te draaien en kijken wat ie doet, alhoewel ik de latencies al een keer op z'n slechts had ingesteld en ie toen ook al vastliep. Verder zal ik memtest eens proberen te draaien vanaf boot.

[Cooperator]

Nou, ik heb de latencies nu op 2-3-3-6 staan en heb Memtest-86 v3.2 1 uur en een kwartier laten draaien bij boot. Heeft 3,5 keer alle tests kunnen doorlopen in die tijd en 0 errors. Toen heb ik de test gestaakt. Heb windows xp opgestart en gelijk Memtest 3.1 gaan draaien en bij 210% coverage nog altijd 0 errors.

Gisteravond liep die al vast geloof ik binnen 100% coverage en kreeg een bsod. Alhoewel ik op de achtergrond wel msn open had staan, en grabit draaiende.

Ik zal straks eens een quickpar repair proberen op een dvd die ik niet heb kunnen repairen op dit systeem, maar nu dan met deze hogere (2-3-3-6) latencies. Kijken of het daar aan lag. Want voorheen zou er weer een bsod moeten volgen bij deze quickpar repair.

[ Voor 7% gewijzigd door Cooperator op 20-04-2005 20:52 ]

[Cooperator]

Ik heb de quickpar reparatie uitgevoerd na het opstarten van windows, zonder andere programma's te hebben gestart. Reparatie is ditmaal wel gelukt. Mogelijk dat het dan toch aan de latencies lag?

Alhoewel ik wel vindt dat als je duur geheugen koopt van 2-2-2-5 cas en niet eens overklokt, je het dan ook op 2-2-2-5 moet kunnen draaien.

Maar wie weet, ik zal nog wel zien of hij het goed blijft doen, ook na windows al een tijd te hebben gedraaid en andere programma's.

In ieder geval bedankt voor jullie tips!

[Mr Magic]

Heb je ook gekeken naar het voltage (Vdimm) dat Corsair adviseert voor jouw geheugen?

Ik moest dit op mijn Asus P4C800-E Deluxe handmatig instellen (ik meen op 2,75 uit m'n hoofd). Standaard stond dit in elk geval te laag.

[Kuip]

Cooperator schreef op woensdag 20 april 2005 @ 18:30:
[...]


Dat is de geadviseerde latency? Waarom dan het duurste geheugen kopen met een latency van 2-2-2-5 als ze zelf adviseren het op 2-3-3-6 te draaien?

Ik weet niet precies welk type je hebt van Corsair, ik gebruik deze: TWINX1024-3200C2

Hier staat het stukje over de geadviseerde timings:

This memory has been verified to operate at 200 MHz (DDR400) at aggressive 2-3-
3-6 latency settings on Intel CPU platforms, and 2.5-3-3-6 on AMD platforms.

Als jij een duurder type hebt, dat wel wel 2-2-2-5 zou moeten draaien is het inderdaad niet zo netjes dat het niet lukt.

Succes met testen!

[Cooperator]

Mr Magic schreef op donderdag 21 april 2005 @ 08:09:
Heb je ook gekeken naar het voltage (Vdimm) dat Corsair adviseert voor jouw geheugen?

Ik moest dit op mijn Asus P4C800-E Deluxe handmatig instellen (ik meen op 2,75 uit m'n hoofd). Standaard stond dit in elk geval te laag.

Inderdaad, voltage moet op 2,75V. Ik zal eens moeten kijken of die daar op staat.

Reactie op Kuip:
Ik heb een andere type: twinx1024-3200xl, deze is wel geadviseerd op 2-2-2-5.

Hij draait momenteel op 2-3-3-6, en systeem lijkt beter te functioneren, maar ik zal nog wel ff doortesten en het is niet de bedoeling op 2-3-3-6 te gaan draaien, daar heb ik per slot van rekening niet zulk duur geheugen voor betaald.

[Verwijderd]

Die CL setting van 2 i.p.v. 2,5 heeft niet zoveel effect op je performance als wel op de stabiliteit van je systeem.
Je kunt je geheugen instellen op 2,5-3-3-6 en niet op 2-2-2-5 en nauwelijks vertraging hebben.
Dit kun je zelf testen door bijvoorbeeld met Sisoft Sandra te benchen.
De FSB met slechts 1 Mhz verhogen heeft vele malen meer effect dan de geheugensettings strakker te zetten.

Met de hogere settings zal je systeem stabieler zijn en dat lijkt me véél belangrijker dan een seconde winst in een uur tijd

Bron: Tom's Hardware Guide