Help me fix my random BSoDs

[loddie]

I'm currently being plagued with seemingly random BSoDs, at about 2-3 a day with no specific triggers. This is the second time I've attempted to use Win 7, the first time I had the same problem with Blue Screens which forced me to reinstall XP, which has no problems at all. I was hoping maybe you guys could look at my minidumps and see if you can get anything out of them.

 

[zigzag3143]

loddie

well you are right about it being quasi random. One recurring thing about the dumps is that as OS file IO.sys, ntkrnl, etc would crash the system because of memory corruption. Have you downloaded and run a memory test? memtest will give you definetive info on the memory.

As far as the system files, I suggest a system file check. to run it go to start>search>cmd>right click and run as admin>sfc /scannow

let us know the results

ken

 

[loddie]

I scanned the ram a couple days ago using the built-in test that comes with Win 7, but it came back with no errors. I considered trying memtest, but if it was faulty memory, wouldn't it also cause problems in XP?

 

[loddie]

The sfc /scannow also showed no issues.

 

[zigzag3143]

L

I would think so but maybe win 7 either addresses it in a different way or makes it work harder. We have someone who has much more experience in debugging bsod dumps. Im going to pm him a link for this thread so he can take a look.

ken

 

[chev65]

There are some new drivers out for your board that are Windows 7 specific.
GIGABYTE - Support&Download - Motherboard - Driver - GA-M57SLI-S4 (rev. 2.0)

Looking at the .dmp files I only read a memory corruption problem so that could mean you need some voltage adjustments in bios to support your memory in order to run Windows 7 which tends to stress the memory much more than Vista or XP.

 

[loddie]

I let Memtest run for about 7 hours and everything came back fine.

 

[loddie]

I've attached another dump from a BSoD that just happened. This is after installing the latest BIOS and bumping the RAM voltage up .1v. Again, it seems quite random. Earlier I set 3DMark Vantage to run on a loop and it did fine. The BSoD in the dump occurred while in a menu of Street Fighter 4.

 

[chev65]

I've attached another dump from a BSoD that just happened. This is after installing the latest BIOS and bumping the RAM voltage up .1v. Again, it seems quite random. Earlier I set 3DMark Vantage to run on a loop and it did fine. The BSoD in the dump occurred while in a menu of Street Fighter 4.

This dump showed the dxgmms1.sys as being the problem which seems to relate to an Nvidia driver problem. Also there is mention of the game streetfighter 4 as a potential problem or at least that is where the crash occured as you said earlier.

I would try using one of the older Nvidia drivers, the older Vista drivers are working well for people like the 185 series.

Bumping the memory voltage or the northbridge voltage can also help. Dump is listed below.

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

Loading Dump File [C:\Users\Rob\Desktop\100709-21793-01\100709-21793-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\SymCache*Symbol information
Executable search path is:
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a62000 PsLoadedModuleList = 0xfffff800`02c9fe50
Debug session time: Wed Oct 7 03:55:14.638 2009 (GMT-7)
System Uptime: 0 days 0:57:31.573
Loading Kernel Symbols
...............................................................
................................................................
.............................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {fffffa0006afb7b8, 2, 1, fffff80002a9a903}
Probably caused by : dxgmms1.sys ( dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+229 )
Followup: MachineOwner
---------
0: 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: fffffa0006afb7b8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002a9a903, address which referenced memory
Debugging Details:
------------------

WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002d0a0e0
fffffa0006afb7b8
CURRENT_IRQL: 2
FAULTING_IP:
nt!MiRemoveUnusedSegment+93
fffff800`02a9a903 488908 mov qword ptr [rax],rcx
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: StreetFighterI
TRAP_FRAME: fffff88004cc94c0 -- (.trap 0xfffff88004cc94c0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000200 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002af3e60 rsp=fffff88004cc9650 rbp=0000000000000001
r8=fffffa800451dff8 r9=0000000030f49000 r10=0000000000000200
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po cy
nt!MmProbeAndLockPages+0x130:
fffff800`02af3e60 410fb601 movzx eax,byte ptr [r9] ds:00000000`30f49000=??
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80002ad3469 to fffff80002ad3f00
STACK_TEXT:
fffff880`04cc8e98 fffff800`02ad3469 : 00000000`0000000a fffffa00`06afb7b8 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`04cc8ea0 fffff800`02ad20e0 : fffff800`02a48460 00000000`00000000 fffff800`02a48460 fffff780`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`04cc8fe0 fffff800`02a9a903 : 00000000`00000001 00000000`000008e1 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260
fffff880`04cc9170 fffff800`02b922f9 : fffffa80`06b635c0 00000000`00000000 fffffa80`06b635c0 000fffff`ffffffff : nt!MiRemoveUnusedSegment+0x93
fffff880`04cc91c0 fffff800`02b31d7c : fffffa80`06b635c0 00000000`00000000 00000000`00000001 00000000`00000002 : nt!MiCheckForControlAreaDeletion+0x39
fffff880`04cc9210 fffff800`02a975ac : 00000000`00000002 fffff800`00000000 fffffa80`017f7ed0 fffff800`00000001 : nt! ?? ::FNODOBFM::`string'+0x10cac
fffff880`04cc9280 fffff800`02b9323d : fffffa80`017f7ed0 fffff880`04cc93c0 00000000`00000080 00000000`0009a1fc : nt!MiRestoreTransitionPte+0xcc
fffff880`04cc92e0 fffff800`02a7f398 : fffff680`00187a48 fffff880`04cc93c0 00000000`00000000 ffffffff`ffffffff : nt!MiRemoveLowestPriorityStandbyPage+0x2ad
fffff880`04cc9360 fffff800`02ad1fee : 00000000`00000000 ffffffff`ffffffff 00000000`40b8e000 ffffffff`ffffffb0 : nt! ?? ::FNODOBFM::`string'+0x43555
fffff880`04cc94c0 fffff800`02af3e60 : fffff8a0`00000000 fffff800`02c61880 00000000`00000000 fffff800`02c06646 : nt!KiPageFault+0x16e
fffff880`04cc9650 fffff880`04a33a25 : fffffa80`0451d000 00000000`00000000 00000000`00000002 00000000`30d50000 : nt!MmProbeAndLockPages+0x130
fffff880`04cc9760 fffff880`04a32bbc : fffffa80`068c6ea0 fffff8a0`035047a0 00000000`000000e8 00000000`00200000 : dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+0x229
fffff880`04cc97f0 fffff880`04a2d6a0 : fffff8a0`035047a0 fffff8a0`035047a0 fffff8a0`08f21f00 00000000`00000133 : dxgmms1!VIDMM_SEGMENT::LockAllocationBackingStore+0x80
fffff880`04cc9860 fffff880`04a21af3 : fffffa80`03bba150 fffffa80`068bd000 fffffa80`068bd000 fffff880`04a216e8 : dxgmms1!VIDMM_APERTURE_SEGMENT::CommitResource+0x1c4
fffff880`04cc98b0 fffff880`04a1e763 : 00000000`00000000 fffffa80`04376000 00000000`00000000 fffffa80`06e78170 : dxgmms1!VIDMM_GLOBAL:ageInAllocations+0xbb
fffff880`04cc9910 fffff880`04a3865d : 00000000`00000000 fffff8a0`0a580090 fffffa80`00000000 fffffa80`03c0ec60 : dxgmms1!VIDMM_GLOBAL:repareDmaBuffer+0xccf
fffff880`04cc9ae0 fffff880`04a38398 : fffff880`009ebec0 fffff880`04a37d00 fffffa80`00000000 fffffa80`00000000 : dxgmms1!VidSchiSubmitRenderCommand+0x241
fffff880`04cc9cd0 fffff880`04a37e96 : 00000000`00000000 fffffa80`07766010 00000000`00000080 fffffa80`05e0e410 : dxgmms1!VidSchiSubmitQueueCommand+0x50
fffff880`04cc9d00 fffff800`02d77166 : 00000000`1dd889c0 fffffa80`05e1db60 fffffa80`039cdb30 fffffa80`05e1db60 : dxgmms1!VidSchiWorkerThread+0xd6
fffff880`04cc9d40 fffff800`02ab2486 : fffff880`009e7180 fffffa80`05e1db60 fffff880`009f1f40 fffff880`0141ba90 : nt!PspSystemThreadStartup+0x5a
fffff880`04cc9d80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb
FOLLOWUP_IP:
dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+229
fffff880`04a33a25 4c8b1d8cd6fdff mov r11,qword ptr [dxgmms1!_imp_g_loggerInfo (fffff880`04a110b8)]
SYMBOL_STACK_INDEX: b
SYMBOL_NAME: dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+229
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME: dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc578
FAILURE_BUCKET_ID: X64_0xA_dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+229
BUCKET_ID: X64_0xA_dxgmms1!VIDMM_SEGMENT::SafeProbeAndLockPages+229
Followup: MachineOwner
---------
0: kd> lmvm dxgmms1
start end module name
fffff880`04a00000 fffff880`04a46000 dxgmms1 (pdb symbols) c:\symcache\dxgmms1.pdb\685AF9F266284BE19008B39B739A572B1\dxgmms1.pdb
Loaded symbol image file: dxgmms1.sys
Mapped memory image file: C:\SymCache\dxgmms1.sys\4A5BC57846000\dxgmms1.sys
Image path: \SystemRoot\System32\drivers\dxgmms1.sys
Image name: dxgmms1.sys
Timestamp: Mon Jul 13 16:38:32 2009 (4A5BC578)
CheckSum: 0004AD44
ImageSize: 00046000
File version: 6.1.7600.16385
Product version: 6.1.7600.16385
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: dxgmms1.sys
OriginalFilename: dxgmms1.sys
ProductVersion: 6.1.7600.16385
FileVersion: 6.1.7600.16385 (win7_rtm.090713-1255)
FileDescription: DirectX Graphics MMS
LegalCopyright: © Microsoft Corporation. All rights reserved.

 

[loddie]

I'll try using some older drivers then. It's odd though, because I've also had BSoDs while I was elsewhere and the computer was idling on the deskop.

 

[loddie]

Here's another dump that appears different than the others (I'm using a program called Bluescreenview to view them, not that I have any idea what I'm looking at).

 

[zigzag3143]

Here's another dump that appears different than the others (I'm using a program called Bluescreenview to view them, not that I have any idea what I'm looking at).

Loddie

Bluescreenview isnt bad for what it does but nothing would have helped this dump. It looks like hardware (maybe memory) the dump has nothing conclusive. sometimes this happens on 64bit machines.

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

sorry I couldn't help

ken

 

[H2SO4]

Here's another dump that appears different than the others (I'm using a program called Bluescreenview to view them, not that I have any idea what I'm looking at).

Something corrupted memory which was storing the kernel itself. It's either bad hardware or a buggy driver. Try updating these drivers, starting with the oldest, or even remove those you can do without:

start end module name
fffff880`00fb9000 fffff880`00fe4000 nvstor Wed May 20 16:45:37 2009 (4A13A711)
fffff880`0120c000 fffff880`0124b000 nvstor64 Wed Aug 05 10:31:07 2009 (4A78D2CB)
fffff880`0124b000 fffff880`01256000 amdxata Wed May 20 03:56:59 2009 (4A12F2EB)
fffff880`04676000 fffff880`046d9d80 nvm62x64 Sat Oct 18 08:01:06 2008 (48F8FD12)
fffff880`04a1c000 fffff880`04bbd300 HCW85BDA Sat Aug 08 05:53:15 2009 (4A7C862B)
fffff880`04bc8000 fffff880`04bd7000 hcw85cir3 Sat Aug 08 05:52:36 2009 (4A7C8604)
fffff880`04c46000 fffff880`04c8a000 ainsu512 Sun Mar 22 01:48:32 2009 (49C4FE40)
fffff880`05205000 fffff880`053ec280 RTKVHD64 Tue Sep 22 23:04:41 2009 (4AB8CB69)
fffff880`07134000 fffff880`0713e000 GVTDrv64 Tue Sep 05 17:10:02 2006 (44FD22CA)
fffff880`0713e000 fffff880`07145000 AODDriver Mon Oct 13 15:38:55 2008 (48F2D0DF)

 

[chev65]

When recieving a bunch of different bug reports I'd say you could have some general instability going on there. That is why I mentioned adjusting the memory and or voltage settings in bios. These can have a big impact on general stablity, just one adjustment can make the difference between stable and unstable.

 

[loddie]

Here's another dump that appears different than the others (I'm using a program called Bluescreenview to view them, not that I have any idea what I'm looking at).

Something corrupted memory which was storing the kernel itself. It's either bad hardware or a buggy driver. Try updating these drivers, starting with the oldest, or even remove those you can do without:

start end module name
fffff880`00fb9000 fffff880`00fe4000 nvstor Wed May 20 16:45:37 2009 (4A13A711)
fffff880`0120c000 fffff880`0124b000 nvstor64 Wed Aug 05 10:31:07 2009 (4A78D2CB)
fffff880`0124b000 fffff880`01256000 amdxata Wed May 20 03:56:59 2009 (4A12F2EB)
fffff880`04676000 fffff880`046d9d80 nvm62x64 Sat Oct 18 08:01:06 2008 (48F8FD12)
fffff880`04a1c000 fffff880`04bbd300 HCW85BDA Sat Aug 08 05:53:15 2009 (4A7C862B)
fffff880`04bc8000 fffff880`04bd7000 hcw85cir3 Sat Aug 08 05:52:36 2009 (4A7C8604)
fffff880`04c46000 fffff880`04c8a000 ainsu512 Sun Mar 22 01:48:32 2009 (49C4FE40)
fffff880`05205000 fffff880`053ec280 RTKVHD64 Tue Sep 22 23:04:41 2009 (4AB8CB69)
fffff880`07134000 fffff880`0713e000 GVTDrv64 Tue Sep 05 17:10:02 2006 (44FD22CA)
fffff880`0713e000 fffff880`07145000 AODDriver Mon Oct 13 15:38:55 2008 (48F2D0DF)

I'm having trouble identifying what the "GVTDrv64" you've pointed out belongs to. Google isn't helping much. Anyone know?

 

[H2SO4]

I'm having trouble identifying what the "GVTDrv64" you've pointed out belongs to. Google isn't helping much. Anyone know?

Gvtdrv.sys driver

"There are 4 different variations of the file in our database and the file is digitally signed from GIGA-BYTE TECHNOLOGY CO., LTD - VeriSign Time Stamping Services Signer "

There's no proof that it's in any way connected to the crash, but in these situations the best approach is to start with the older drivers. If it's not absolutely required, test whether removing it helps to ward off future crashes.