[SOLVED] BSoD in Overwatch

S

SlaideR

New member
Joined
Oct 15, 2019
Posts
4
  • OS - Windows 10
  • x86 (32-bit) or x64 (64-bit)? x64 (64-bit)
  • What was the originally installed OS on the system? Originally installed Windows 10 x64
  • Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)? OEM version
  • Age of system (hardware) - ~2Y
  • Age of OS installation - have you re-installed the OS? Re-installed 13.10.2019

    · CPU - Intel i7-7820HK
    · Video Card - Nvidia GeForce GTX 1080
    · MotherBoard - N/A

    · System Manufacturer - Dell Alienware
    · Exact model number - Alienware 17 R4

    · Laptop or Desktop? Laptop
Hi guys,
There is a problem with my laptop when I’m running Overwatch. After a few game matches it goes to BSoD with UNEXPECTED_KERNEL_MODE_TRAP or IRQL_NOT_LESS_OR_EQUA messages.
Another games work perfectly on ultra settings (tested in APEX, AC: Odyssey, Dead by Daylight, Witcher 3). Also there’s no BSoD when I'm using it routinely, only in Overwatch after a few matches (2+).

MEMORY.DMP on Google Drive

How I tried to fix that:
1. Copied Overwatch to SSD - ended up with BSoD in Overwatch
2. Changed in-game settings to low - BSoD in Overwatch
3. Factory restore (that's why Windows was re-installed 13.10.2019) - BSoD in Overwatch
4. Sometimes game crashes with errors BLZOWCLI00000005 and BLZOWCLI00000004, but more often ending with BSoD in Overwatch
5. Uninstalled Tobii Eye Tracker and GeForce Experience, disabled all the Alienware software - BSoD in Overwatch
6. Checked and updated all the drivers with TweakBit Driver Updater - you guessed it! BSoD in Overwatch

What I haven’t done yet because of a little risk (I’m scared) - BIOS update. I have BIOS version: 1.2.4, A00. Here's what Alienware SupportAssist wants to be installed: Version SKL1.3.0_KBL1.2.4, 1.3.0 and Version 1.7.0, 1.7.0

Found a possible fix: There’s no BSoD if I set FPS limit to 60 (ingame settings). Having FPS limit to any number over 60 (tried with 70) - BSoD

Thank you in advance!
 

Attachments

From the kernel memory dump provided:

Code: 
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: [COLOR=rgb(65, 168, 95)]ffff8e87156d9468[/COLOR], memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, 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: [COLOR=rgb(255, 0, 0)]fffff807060485ad[/COLOR], address which referenced memory

The system has crashed because a page fault was executed at IRQL Level 2, this is an illegal operation and therefore will result in a crash.

Code: 
0: kd> [COLOR=rgb(65, 168, 95)]ln fffff807060485ad[/COLOR]
Browse module
Set bu breakpoint

(fffff807`060484b0)  [COLOR=rgb(255, 0, 0)] nt!KeSetEvent+0xfd [/COLOR]  |  (fffff807`06048970)   nt!KiExitDispatcher

The KeSetEvent function simply sets an event object to the signaled state. This is used for synchronization of resources. The function takes one parameter which is a handle to the event object which it wishes to set to signaled.

Code: 
0: kd> [COLOR=rgb(255, 0, 0)].frame /r 3[/COLOR]
03 ffffe883`92e2ea60 fffff807`1f9159e3 nt!KeSetEvent+0xfd
rax=[COLOR=rgb(255, 0, 0)]ffff8e87156d9460[/COLOR] rbx=ffffae87156d9458 rcx=ffffae87156d9460
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff807060485ad rsp=ffffe88392e2ea60 rbp=ffffae87157637f0
 r8=0000000000000000  r9=0000000000000000 r10=fffff807060484b0
r11=ffffe88392e2ea00 r12=0000000000000000 r13=fffff80702751180
r14=ffff8e87156d9460 r15=ffffae87156d9460
iopl=0         nv up ei ng nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040286
nt!KeSetEvent+0xfd:
fffff807`060485ad 48396808        cmp     qword ptr [rax+8],rbp ds:002b:[COLOR=rgb(0, 0, 255)]ffff8e87`156d9468[/COLOR]=????????????????

Interestingly, it appears that the address within the rax register is actually an object pointer.

Code: 
0: kd> [COLOR=rgb(65, 168, 95)]!object ffffae87156d9460[/COLOR]
Object: ffffae87156d9460  Type: (ffffae86fe6317a0) [COLOR=rgb(255, 0, 0)]DxgkCurrentDxgProcessObject[/COLOR]
    ObjectHeader: ffffae87156d9430 (new version)
    HandleCount: 0  PointerCount: 545460846592

We can dump the associated PTE to see if the address has been mapped, and looks like it hasn't, again confirms why we page fault on that address.

Code: 
0: kd> [COLOR=rgb(65, 168, 95)]!pte ffff8e87156d9468[/COLOR]
                                           VA ffff8e87156d9468
PXE at FFFF8140A05028E8    PPE at FFFF8140A051D0E0    PDE at FFFF8140A3A1C558    PTE at FFFF8147438AB6C8
contains 0000000000000000
contains 0000000000000000
[COLOR=rgb(255, 0, 0)]not valid[/COLOR]

Since the call stack shows a vast number of graphics library related calls, then I would first begin with checking for updates for your graphics card driver:

Code: 
0: kd> [COLOR=rgb(65, 168, 95)]lmvm nvlddmkm[/COLOR]
Browse full module list
start             end                 module name
fffff807`22fa0000 fffff807`244c9000   nvlddmkm   (no symbols)           
    Loaded symbol image file: nvlddmkm.sys
    Image path: \SystemRoot\System32\DriverStore\FileRepository\nvdmegpu.inf_amd64_b7816616157a066e\nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    Timestamp:        [COLOR=rgb(255, 0, 0)]Fri Jul 12 08:28:57 2019[/COLOR] (5D2836B9)
    CheckSum:         014D548F
    ImageSize:        01529000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

Source: NVIDIA DRIVERS GeForce Game Ready Driver WHQL
 
Hi x BlueRobot, thank you for the information!

I have updated Nvidia driver and rebooted laptop. Then launched Overwatch and disabled FPS limit, noting here: no lags or freezes in the game, stable FPS at 120-130, videocard temp max was 82C. In the first match game crashed and appered system window with send report to Blizzard button. Second attempt and BSoD was found (SYSTEM_SERVICE_EXCEPTION now) - Game freezed for ~10 seconds and laptop rebooted. Here is the new dump file: Google Drive.

I've written to Blizzard support team already, they can't help with BSoD issues :(.
I also noticed that all the minidump proprities contain the same Crash Address: ntoskrnl.exe+1c1220. What does it mean?

Thank you!
 

Attachments

Played Apex Legends yesterday and turned off V-Sync in game settings (was on triple buffered) - laptop went to BSoD screen. I turned it because i have G-Sync and just for test.
So now not only Overwatch with BSoD issue...
 
Code: 
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: [COLOR=rgb(65, 168, 95)]00000000c0000005[/COLOR], Exception code that caused the bugcheck
Arg2: [COLOR=rgb(255, 0, 0)]ffff80a11c833c15[/COLOR], Address of the instruction which caused the bugcheck
Arg3: [COLOR=rgb(0, 0, 255)]ffff918d137c6f80[/COLOR], Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Code: 
4: kd> [COLOR=rgb(65, 168, 95)]!error c0000005[/COLOR]
Error code: (NTSTATUS) 0xc0000005 (3221225477) - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

Okay, seems like we're looking at a similar kind of crash to the Stop 0xA.

Code: 
4: kd> [COLOR=rgb(65, 168, 95)]ln ffff80a11c833c15[/COLOR]
Browse module
Set bu breakpoint

(ffff80a1`1c8339c0)   [COLOR=rgb(255, 0, 0)]win32kbase!NtDCompositionGetFrameSurfaceUpdates[/COLOR]+0x255   |  (ffff80a1`1c833c30)   win32kbase!EXFORMOBJ::bEqualExceptTranslations

Another graphics library related function call which we crashed on, again very similar to our last bugcheck and fits the context of when we crashed too.

Let's dump the context record to get more information on why we crashed.

Code: 
4: kd> [COLOR=rgb(65, 168, 95)].cxr 0xffff918d137c6f80[/COLOR]
rax=0000000000000000 rbx=ffff80dfc0608ed0 rcx=000000ec5ddfef0c
rdx=ffffae010d5bd710 rsi=ffff80dfc2843c10 rdi=0000000000000020
rip=ffff80a11c833c15 rsp=ffff918d137c7970 rbp=ffff918d137c7a80
 r8=0000000000000014  r9=ffff918d137c7a00 r10=7ffffffffffffffc
r11=ffff918d137c7900 r12=0000000000000001 r13=00000000000316cb
r14=000000ec5ddfef00 r15=000000ec5ddfef08
iopl=0         nv up ei ng nz na po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050287
win32kbase!NtDCompositionGetFrameSurfaceUpdates+0x255:
ffff80a1`1c833c15 8b442430        mov     eax,dword ptr [[COLOR=rgb(255, 0, 0)]rsp+30h[/COLOR]] ss:0018:ffff918d`137c79a0=00000000

Code: 
4: kd> [COLOR=rgb(65, 168, 95)]dd ffff918d137c7970+30 l5[/COLOR]
ffff918d`137c79a0  00000000 00000000 000316cb 00000000

Okay, the address doesn't appear to be pointing to a null value.

Let's dump the PTE information for the address, primarily since I noticed that there was a page fault in the call stack.

Code: 
4: kd> [COLOR=rgb(65, 168, 95)]!pte ffff918d`137c79a0[/COLOR]
                                           VA ffff918d137c79a0
PXE at FFFF96CB65B2D918    PPE at FFFF96CB65B231A0    PDE at FFFF96CB646344D8    PTE at FFFF96C8C689BE38
contains 0A0000000408D863  contains 0A0000000408E863  contains 0A000004564F4863  contains 8A00000457871863
pfn 408d      ---DA--KWEV  pfn 408e      ---DA--KWEV  pfn 4564f4    ---DA--KWEV  pfn 457871    ---DA--KW[COLOR=rgb(255, 0, 0)]-[/COLOR]V

Okay, looks like we possibly attempted to execute an instruction on a non-executable region of memory which would lead to our access violation error code shown earlier.

I'm still leaning towards possible driver issues at this point, let's enable Driver Verifier and see what if it catches anything - Driver Verifier - BSOD related - Windows 10, 8.1, 8, 7 + Vista

SlaideR said:
I also noticed that all the minidump proprities contain the same Crash Address: ntoskrnl.exe+1c1220. What does it mean?
Click to expand...

It just means that Windows wasn't able to find a probable cause at the time of the crash, so it defaults to the last call on the stack just before the bugcheck dispatcher is called. The last call is usually a Windows related function so it's very common to see ntoskrnl.
 
Hi,

Just for history. Issue was resolved by changing RAM sticks (bought a new kit). This is a little strange, because memtest86 (tried twice) didn't show any errors ¯\_(ツ)_/¯.

Thanks.
 
Thanks for letting us know! As a general note, it isn't uncommon for memory testing programs to be unable to detect faulty RAM, which is why we always suggest testing each RAM stick individually for each slot on the motherboard. It can be quite long and tedious, but you'll know if the system crashes with one particular stick or within a particular slot and therefore can make the appropriate replacement(s).
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top