Help with Dump files on new Windows 7 machine

Associate
Joined
24 Mar 2004
Posts
52
Hi there.

Just finished building a new workstation system:

ASUS P6X58D Premium
i7-930 2.80Ghz
12GB XMS3 DDR3 1600MHz
Nvidia 8800GTS
128GB Corsair Nova SSD V128GB2-BRKT (System Drive)

I have currently unplugged all other drives for the purposes of benchmarking.
I have fully updated all the system drivers including the intel & marvell controllers.

The problems lies when doing any form of transfer or benchmarking on the SSD whilst connected to the marvell controller. Randomly it will just blue screen and produce a memory dump in which i have no experience with. Can anyone help interpret the file i have attached?

Thanks

http://www.smdpromotions.co.uk/stuff/031810-10998-01.dmp
 
Log Name: System
Source: Microsoft-Windows-WER-SystemErrorReporting
Date: 18/03/2010 14:07:32
Event ID: 1001
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: MAINPC
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x000000d1 (0xfffffa880a88be18, 0x0000000000000006, 0x0000000000000000, 0xfffff8800108168a). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 031810-10998-01.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-WER-SystemErrorReporting" Guid="{ABCE23E7-DE45-4366-8631-84FA6C525952}" EventSourceName="BugCheck" />
<EventID Qualifiers="16384">1001</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-03-18T14:07:32.000000000Z" />
<EventRecordID>2610</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>MAINPC</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">0x000000d1 (0xfffffa880a88be18, 0x0000000000000006, 0x0000000000000000, 0xfffff8800108168a)</Data>
<Data Name="param2">C:\Windows\MEMORY.DMP</Data>
<Data Name="param3">031810-10998-01</Data>
</EventData>
</Event>
 
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [031810-10998-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a50000 PsLoadedModuleList = 0xfffff800`02c8de50
Debug session time: Thu Mar 18 14:06:30.651 2010 (GMT+0)
System Uptime: 0 days 0:09:47.680
Loading Kernel Symbols
...............................................................
................................................................
................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {fffffa880a88be18, 6, 0, fffff8800108168a}

Unable to load image \SystemRoot\system32\DRIVERS\mv91xx.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for mv91xx.sys
*** ERROR: Module load completed but symbols could not be loaded for mv91xx.sys
Unable to load image \SystemRoot\system32\DRIVERS\nvlddmkm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys
Probably caused by : mv91xx.sys ( mv91xx+3868a )

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

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: fffffa880a88be18, memory referenced
Arg2: 0000000000000006, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800108168a, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cf80e0
 fffffa880a88be18 

CURRENT_IRQL:  6

FAULTING_IP: 
mv91xx+3868a
fffff880`0108168a 488b34c8        mov     rsi,qword ptr [rax+rcx*8]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  System

TRAP_FRAME:  fffff88003121830 -- (.trap 0xfffff88003121830)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800a88be20 rbx=0000000000000000 rcx=00000000ffffffff
rdx=fffffa800a88b958 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800108168a rsp=fffff880031219c0 rbp=fffffa800a88a801
 r8=fffff88003726900  r9=0000000000000001 r10=fffffa800a8abe18
r11=fffffa800a88a8a8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na pe nc
mv91xx+0x3868a:
fffff880`0108168a 488b34c8        mov     rsi,qword ptr [rax+rcx*8] ds:74c8:fffffa88`0a88be18=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002ac1469 to fffff80002ac1f00

STACK_TEXT:  
fffff880`031216e8 fffff800`02ac1469 : 00000000`0000000a fffffa88`0a88be18 00000000`00000006 00000000`00000000 : nt!KeBugCheckEx
fffff880`031216f0 fffff800`02ac00e0 : 00000000`00000001 fffffa80`0a88b984 fffffa80`0b74d628 fffff880`05a0df1d : nt!KiBugCheckDispatch+0x69
fffff880`03121830 fffff880`0108168a : fffffa80`0a88b984 fffff880`0377c020 fffffa80`0b74d000 fffffa80`09d823e0 : nt!KiPageFault+0x260
fffff880`031219c0 fffffa80`0a88b984 : fffff880`0377c020 fffffa80`0b74d000 fffffa80`09d823e0 fffffa80`0ae169a0 : mv91xx+0x3868a
fffff880`031219c8 fffff880`0377c020 : fffffa80`0b74d000 fffffa80`09d823e0 fffffa80`0ae169a0 fffff880`05d176b7 : 0xfffffa80`0a88b984
fffff880`031219d0 fffffa80`0b74d000 : fffffa80`09d823e0 fffffa80`0ae169a0 fffff880`05d176b7 fffff880`03726900 : 0xfffff880`0377c020
fffff880`031219d8 fffffa80`09d823e0 : fffffa80`0ae169a0 fffff880`05d176b7 fffff880`03726900 fffffa80`0a8abda0 : 0xfffffa80`0b74d000
fffff880`031219e0 fffffa80`0ae169a0 : fffff880`05d176b7 fffff880`03726900 fffffa80`0a8abda0 fffffa80`0a8a74c8 : 0xfffffa80`09d823e0
fffff880`031219e8 fffff880`05d176b7 : fffff880`03726900 fffffa80`0a8abda0 fffffa80`0a8a74c8 fffffa80`0b74d000 : 0xfffffa80`0ae169a0
fffff880`031219f0 fffff880`03726900 : fffffa80`0a8abda0 fffffa80`0a8a74c8 fffffa80`0b74d000 00000000`00000000 : nvlddmkm+0x4966b7
fffff880`031219f8 fffffa80`0a8abda0 : fffffa80`0a8a74c8 fffffa80`0b74d000 00000000`00000000 00000000`00000000 : 0xfffff880`03726900
fffff880`03121a00 fffffa80`0a8a74c8 : fffffa80`0b74d000 00000000`00000000 00000000`00000000 fffffa80`0ad5b900 : 0xfffffa80`0a8abda0
fffff880`03121a08 fffffa80`0b74d000 : 00000000`00000000 00000000`00000000 fffffa80`0ad5b900 fffff880`03726900 : 0xfffffa80`0a8a74c8
fffff880`03121a10 00000000`00000000 : 00000000`00000000 fffffa80`0ad5b900 fffff880`03726900 00000000`44000008 : 0xfffffa80`0b74d000


STACK_COMMAND:  kb

FOLLOWUP_IP: 
mv91xx+3868a
fffff880`0108168a 488b34c8        mov     rsi,qword ptr [rax+rcx*8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  mv91xx+3868a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: mv91xx

IMAGE_NAME:  mv91xx.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4acf09d5

FAILURE_BUCKET_ID:  X64_0xD1_mv91xx+3868a

BUCKET_ID:  X64_0xD1_mv91xx+3868a

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




mv91xx.sys is causing the crash, which is the driver for your Marvell controller; try upgrading to the latest drivers.
 
Thanks for that, just confirmed my suspicions!

There are no newer drivers and it would appear i am not the only one having a problem with them

http://vip.asus.com/forum/view.aspx...1&model=P6X58D+Premium&page=1&SLanguage=en-us

The guys in that topic have different SSD from me so would defop point to it being a problem with the driver rather than incompatible hardware which was something else i was worried about.

When switching to the standard windows AHCI drivers i can now fully complete an ATTO test which shows positive I/O results over the intel controller but nothing overwhelming.

I guess this storage controller is still in early stages and i'll have to wait for an updated Marvell driver, i'll not hold my breath though!
 
Have you tried the drivers from Marvell's website, they might be newer? (assuming you're getting them from Asus' site at the moment)
 
Oh ok. You could maybe try downgrading to an older driver if you can find them.
 
Back
Top Bottom