Many BSOD's when rendering on gpu

Hi, i’ve been having this problem for a while now,
To try and solve it, i’ve

  • reinstalled windows
  • run memtest for 23 hours - no errors
  • tried using a different hard disk
  • changed motherboards

What happens is that, after some time rendering on the GPU the computer will BSOD, time can vary in about the region of 5 minutes to 1 hour.

viewport render hasn’t crashed it yet, anyone know what the cause could be?
Here’s the msdn link for the error code:

I’ve pasted my dmp file below
If you need any more info just ask, thanks for looking :slight_smile:
Primary AnalysisCrash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff80002e4e000 PsLoadedModuleList = 0xfffff8000308be50
Debug session time: Tue Jun 17 18:22:14.291 2014 (UTC - 4:00)
System Uptime: 0 days 20:06:25.213


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff88010d3e78e, Address of the instruction which caused the bugcheck
Arg3: fffff8800ebacb40, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

TRIAGER: Could not open triage file : e:\dump_analysis\program riage\modclass.ini, error 2

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
dxgkrnl!DXGCONTEXT::Present+364e
fffff88010d3e78e ff15a4e8faff call qword ptr [dxgkrnl!_imp_ExIsResourceAcquiredSharedLite (fffff88010ced038)]

CONTEXT: fffff8800ebacb40 – (.cxr 0xfffff8800ebacb40)
rax=fffffa80173f4620 rbx=0000000000000000 rcx=fffffa8014247000
rdx=fffffa80173f4620 rsi=fffff8800ebad8f0 rdi=0000000000000000
rip=fffff88010d3e78e rsp=fffff8800ebad520 rbp=fffff8a018c19c80
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff8800ebad080 r12=fffff8a018c19d40 r13=fffff8a018c19d40
r14=fffff8a002664230 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
dxgkrnl!DXGCONTEXT::Present+0x364e:
fffff88010d3e78e ff15a4e8faff call qword ptr [dxgkrnl!_imp_ExIsResourceAcquiredSharedLite (fffff88010ced038)] ds:002b:fffff880`10ced038=00000000000ef342
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x3B

PROCESS_NAME: dwm.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff88010d3e78e

STACK_TEXT:
fffff8800ebad520 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : dxgkrnl!DXGCONTEXT::Present+0x364e

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: STRIDE

STACK_COMMAND: .cxr 0xfffff8800ebacb40 ; kb

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_STRIDE

BUCKET_ID: X64_MEMORY_CORRUPTION_STRIDE

Followup: memory_corruption

This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)