BSOD Playing MPC

So after a week or so without any problems I received another BSOD while watching a Movie using Media Player Classic.

I've included the Dump File again for checking in what caused it.

The only thing I've changed within the past week in my System is that I reverted back to my old graphics driver (285.xx) since the newer version caused instant BSODs. (I've installed it from the CD that came with the product after uninstalling the older driver)

I've also reverted back to FireFox 6 from using FireFox 10.0.2 since the newer FireFox Version always crashes.

I've read somewhere around the net that the problem could be caused by Memory Timings or something like that.

Howdy,

This is a peculiar one. I did a bit of diving, and I did see something that looked to be a hardware-related issue. Unfortunately, when attempting to dive further I was stonewalled by the limitations caused by the minidump (a minidump retains very little information about the crash). I cannot progress further without a kernel dump (that huge MEMORY.DMP file located in your Windows directory).

I only know of one type of software bug that would cause this, but it is rare, whereas most of the cases that cause this kind of behavior are hardware-related. If you wanna look further into it, I suggest a couple of hardware tests.

First, run Prime95 on Torture Test with Large FFTs overnight. If you notice ANY errors that pop up during the test, then we are looking at what could most possibly be CPU (though motherboard or PSU can cause CPU errors).

Second, run Memtest86+ at least 7 passes on your memory. Again, any errors at all is not a good sign for your memory. If you see errors pop up both here and Prime95, expect it to be your mobo/PSU to be the culprit.

Third, and lastly, you'll want to run a couple passes with MemtestCL on your GPU. Your Nvidia card most likely will be able to run it. Any errors here means problems with your graphics card most likely.

If none of these tests show up failure, then you have either a bad PSU or motherboard, or you are experiencing that rare software bug, which you may be able to track down with Driver Verifier. Note that in addition to not checking Low Resource Simulation, also do not check IRP Logging and Force Pending Requests. Other than that the instructions in the article are good.



Analysts:

Code:

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

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff908c0855f24, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff96000067886, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 0000000000000005, (reserved)

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


Could not read faulting driver name
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800032bc0e0
GetUlongFromAddress: unable to read from fffff800032bc198
 fffff908c0855f24 

FAULTING_IP: 
win32k!RGNOBJ::bMerge+42
fffff960`00067886 418b03          mov     eax,dword ptr [r11]

MM_INTERNAL_CODE:  5

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x50

PROCESS_NAME:  mpc-hc.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffff880084f7a30 -- (.trap 0xfffff880084f7a30)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff900c0855e60 rbx=0000000000000000 rcx=fffff880084f7c50
rdx=000000007fffffff rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000067886 rsp=fffff880084f7bc0 rbp=fffff880084f7d24
 r8=fffff880084f7c40  r9=fffff900c2fbfaa0 r10=fffff900c2fbfa00
r11=fffff908c0855f24 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
win32k!RGNOBJ::bMerge+0x42:
fffff960`00067886 418b03          mov     eax,dword ptr [r11] ds:fffff908`c0855f24=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800031037a1 to fffff800030845c0

STACK_TEXT:  
fffff880`084f78c8 fffff800`031037a1 : 00000000`00000050 fffff908`c0855f24 00000000`00000000 fffff880`084f7a30 : nt!KeBugCheckEx
fffff880`084f78d0 fffff800`030826ae : 00000000`00000000 00000000`00000001 00000000`00000000 fffff960`003130d0 : nt! ?? ::FNODOBFM::`string'+0x40d4b
fffff880`084f7a30 fffff960`00067886 : 00000000`00001564 00000000`00000001 fffff880`084f7d24 00000000`00000000 : nt!KiPageFault+0x16e
fffff880`084f7bc0 fffff960`002107b1 : 00000000`00000001 fffff880`084f7cc8 fffff880`084f7c40 00000000`5701100e : win32k!RGNOBJ::bMerge+0x42
fffff880`084f7c20 fffff960`00211a76 : 00000000`00000004 fffff900`c0855e60 fffff900`c0af84f0 fffff900`c062daa8 : win32k!vSpUpdateDirtyRgn+0x3ad
fffff880`084f7cc0 fffff960`002126fc : fffff900`c00bf010 00000000`005207ba ffffffff`d80f0f02 00000000`00000000 : win32k!GreUpdateSprite+0x706
fffff880`084f7e60 fffff960`000c6c87 : fffff900`c00bf010 00000000`00000000 000002e8`00000560 fffff900`c00bf010 : win32k!GreUpdateSpriteDevLockEnd+0x444
fffff880`084f8110 fffff960`001045c1 : fffff900`c00bf010 fffff880`084f84a0 00000000`00a0a0a0 00000000`00a0a0a0 : win32k!DEVLOCKOBJ::vFlushSpriteUpdates+0x16b
fffff880`084f8160 fffff960`00104492 : fffff880`084f83a8 fffff960`00232998 00a0a0a0`00000000 00000000`fffdb300 : win32k!DEVLOCKOBJ::bDisposeTrgDco+0x61
fffff880`084f8190 fffff960`000bd7d1 : fffff880`084f8230 fffff960`00232998 00000000`00000004 00000000`00000000 : win32k!DEVLOCKOBJ::~DEVLOCKOBJ+0xe
fffff880`084f81c0 fffff800`0308371c : fffffa80`0d0a2890 00000000`00000001 fffffa80`0d0a2890 fffff8a0`0f09f4e0 : win32k!NtGdiFlushUserBatch+0xc9d
fffff880`084f8420 00000000`74c602ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceGdiTebAccess+0x25
00000000`0020c758 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74c602ba


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!RGNOBJ::bMerge+42
fffff960`00067886 418b03          mov     eax,dword ptr [r11]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  win32k!RGNOBJ::bMerge+42

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc5e0

FAILURE_BUCKET_ID:  X64_0x50_win32k!RGNOBJ::bMerge+42

BUCKET_ID:  X64_0x50_win32k!RGNOBJ::bMerge+42

Followup: MachineOwner

Rudimentary Analysis:

As a forewarning, I'm still an amateur about this stuff. Take information with a grain of salt.

The callstack shows GDI attempting to update a drawn sprite(s), which I think may be related to subtitles on the movie the client was playing or some element or elements of the Media Player Classic window (I don't believe an actual movie itself would be rendered as a sprite would it?). It attempted to access a bad memory address. The thing is, the address itself looks like a pretty legit address, so what seems to be the problem? Well, what I noticed is the address looks very familiar to other addresses in the stack, as noted below:

Code:

Red is faulting address, green are similarly patterned:

Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`084f78c8 fffff800`031037a1 : 00000000`00000050 fffff908`c0855f24 00000000`00000000 fffff880`084f7a30 : nt!KeBugCheckEx
fffff880`084f78d0 fffff800`030826ae : 00000000`00000000 00000000`00000001 00000000`00000000 fffff960`003130d0 : nt! ?? ::FNODOBFM::`string'+0x40d4b
fffff880`084f7a30 fffff960`00067886 : 00000000`00001564 00000000`00000001 fffff880`084f7d24 00000000`00000000 : nt!KiPageFault+0x16e (TrapFrame @ fffff880`084f7a30)
fffff880`084f7bc0 fffff960`002107b1 : 00000000`00000001 fffff880`084f7cc8 fffff880`084f7c40 00000000`5701100e : win32k!RGNOBJ::bMerge+0x42
fffff880`084f7c20 fffff960`00211a76 : 00000000`00000004 fffff900`c0855e60 fffff900`c0af84f0 fffff900`c062daa8 : win32k!vSpUpdateDirtyRgn+0x3ad
fffff880`084f7cc0 fffff960`002126fc : fffff900`c00bf010 00000000`005207ba ffffffff`d80f0f02 00000000`00000000 : win32k!GreUpdateSprite+0x706
fffff880`084f7e60 fffff960`000c6c87 : fffff900`c00bf010 00000000`00000000 000002e8`00000560 fffff900`c00bf010 : win32k!GreUpdateSpriteDevLockEnd+0x444
fffff880`084f8110 fffff960`001045c1 : fffff900`c00bf010 fffff880`084f84a0 00000000`00a0a0a0 00000000`00a0a0a0 : win32k!DEVLOCKOBJ::vFlushSpriteUpdates+0x16b
fffff880`084f8160 fffff960`00104492 : fffff880`084f83a8 fffff960`00232998 00a0a0a0`00000000 00000000`fffdb300 : win32k!DEVLOCKOBJ::bDisposeTrgDco+0x61
fffff880`084f8190 fffff960`000bd7d1 : fffff880`084f8230 fffff960`00232998 00000000`00000004 00000000`00000000 : win32k!DEVLOCKOBJ::~DEVLOCKOBJ+0xe
fffff880`084f81c0 fffff800`0308371c : fffffa80`0d0a2890 00000000`00000001 fffffa80`0d0a2890 fffff8a0`0f09f4e0 : win32k!NtGdiFlushUserBatch+0xc9d
fffff880`084f8420 00000000`74c602ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceGdiTebAccess+0x25 (TrapFrame @ fffff880`084f8420)
00000000`0020c758 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74c602ba

Unfortunately, the minidump does not retain what is actually stored at this address, so unless we disassemble the code flow and figure out just what is going on (not worth our time) it can't be determined what it actually is. However, I did find a discrepancy between the faulting address and the similar ones (taking one of them as example:

Code:

6: kd> .formats fffff908`c0855f24
Evaluate expression:
  Hex:     fffff908`c0855f24
  Decimal: -7658991689948
  Octal:   1777777620430041257444
  Binary:  11111111 11111111 11111001 00001000 11000000 10000101 01011111 00100100
  Chars:   ......_$
  Time:    ***** Invalid FILETIME
  Float:   low -4.16786 high -1.#QNAN
  Double:  -1.#QNAN
6: kd> .formats fffff900`c0855e60
Evaluate expression:
  Hex:     fffff900`c0855e60
  Decimal: -7693351428512
  Octal:   1777777620030041257140
  Binary:  11111111 11111111 11111001 00000000 11000000 10000101 01011110 01100000
  Chars:   ......^`
  Time:    ***** Invalid FILETIME
  Float:   low -4.16777 high -1.#QNAN
  Double:  -1.#QNAN

A solitary bit has been set in the upper half of the memory address, making it fffff908 instead of fffff900. This is very suspicious activity. I doubt this is memory, because memory failure typically involves not retaining stored data (hence zeroing bits of data). In this case however, a bit was set.

I disassembled the code starting from the faulting instruction and walked back to find where this address originated from but again the minidump does not retain such information. However I did see it in the stack a number of times, so if it is a hardware failure that caused this it probably happened earlier and only now did it cause a fault.

That's all folks.

Hi Vir Gnarus!.

I just finished Memtest86+ (I was running it for a few hours already and it was passed the 7th. round/pass). Found out 1 of the sticks went bad already (It has like, 13000+ errors). Tried the good stick on all slots and it has no errors whatsoever. Going to leave the Prime95 Test overnight to see if any errors happen and will do MemtestCL tomorrow in the morning.

EDIT > The bad RAM was inserted at Slot 4 while the better one was in slot 2. (I have no idea why it was put on those slots but all slots are working fine).

EDIT 2 > Finished with MemtestCL a few times and it returned no errors. Now going to leave the PC overnight for Prime95 Torture Test.

Wow, if this does turn out to be a memory issue, I'd be pretty impressed! Normally memory issues occur when it fails to hold the data in its memory banks, but in this case it would've inadvertently added data!

Vir Gnarus said:

Wow, if this does turn out to be a memory issue, I'd be pretty impressed! Normally memory issues occur when it fails to hold the data in its memory banks, but in this case it would've inadvertently added data!

I just finished with Prime95 and didn't receive any errors. It seems to be the Memory afterall. Thanks again for the help.

No problemo. Make sure to mark this thread as solved if you have verified that it's indeed memory, for future reference. :)