Jump to content

Bsod When Playing Mw:o


26 replies to this topic

#1 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 20 February 2013 - 07:21 PM

Hey guys, I just got off the phone with Microsoft and Toshiba and both were clueless about my issue. Starting after the patch (may or may not be related) and a RAM upgrade to 16 GB, I've been blue-screening every time I play MW:O for more than a few matches.

The error thrown is different each time, but it always involves a particular Windows driver (ntoskrnl.exe) that also happens to be a piece of the Windows 8 kernel... and apparently shouldn't ever be invoked after boot-up time.

First of all, I've tried every Google-able option I could find to include the following:
- Windows 8 System Refresh
- Windows System Restore
- memtest86/memtest86+ scans on both sticks, as well as each one at a time
- Windows 8 memory test utility
- chkdsk, CCleaner, regfix, antivirus, everything else you can imagine, etc.
- monitoring memory clock speeds, timings, temperature, and usage (no correlations to the crashes, apparently)
- doing other things that are NOT MW:O and trying (without success) to recreate the errors


Secondly, my system specs:
- Toshiba Satellite L855-S5372 Notebook
- Intel Core i7 3630QM (Ivy Bridge) 2.4GHz – 3.4GHz
- Toshiba Portable PC motherboard (complete crap, I know)
- Insyde Corp. BIOS Rev. 6.50 (again, embarrassing and useless…)
- (Old RAM) 6 GB (4 & 2) PC3-12800 DDR3 SO-DIMM RAM @ 1600MHz (800MHz Dual Channel)
- (New RAM) Corsair 16 GB (8 & 8) PC3-12800 DDR3 SO-DIMM RAM @ 1600MHz (800MHz Dual Channel)
- Intel HD Graphics 4000 2 GB @ ~300MHz - ~1150MHz
- Windows 8 (6.2) 64-bit


First of all, what about MW:O could be causing ntoskrnl.exe to try to access pieces of my memory that are either (according to the BSOD messages) marked NOWRITE or READ ONLY by the system? Like I said, these errors only occur when I play MW:O and once I start playing, they occur rather predictably.

When I use any combination of either of the 8 GB Corsair sticks and one of my old 4 GB sticks, I can run without a hitch. This makes absolutely NO sense to me. Neither of the sticks is faulty, they simply don’t want to work together even though they’re a matched dual-channel pair.

Could one of the developers confirm whether or not something about MW:O actually DOES invoke the NT Kernel file that keeps throwing errors? I’m at a loss and entirely unable to play MW:O currently, so any help is appreciated.

Thanks again guys, and I’ve attached my most recent minidump for your reading pleasure.

Edited by roflplanes, 20 February 2013 - 07:23 PM.


#2 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 21 February 2013 - 06:15 AM

MWO may not have to access the kernel directly to cause problems. What I can't figure out is why it would only be causing problems with 16GB of RAM.

Have you tried simply uninstalling and reinstalling MWO? You could always upload a dump file for us to look at, but I'm afraid I don't know a whole lot about this error, so I wouldn't have much of an idea of what to look for.

Edited by Catamount, 21 February 2013 - 06:16 AM.


#3 frag85

    Member

  • PipPipPipPipPip
  • 141 posts

Posted 21 February 2013 - 09:46 AM

What is the BSOD exception code? If you missed it filter your event log for the Source, BugCheck. You will see "The computer has rebooted from a bugcheck. The bugcheck was: 0x0...".

It sounds like its probably a driver conflict though (with the exception being you just replaced your ram, even memtest86+ is not always going to tell you the ram is bad). I'm assuming you've run SFC /scannow and chkdsk /f /r? Its possible something in windows 8 was corrupt, and doing a windows restore you only restored the same corrupt data.

Edited by frag85, 21 February 2013 - 09:49 AM.


#4 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 22 February 2013 - 08:57 AM

Won't let me quote today for some reason... Anyhow, yes I tried uninstalling and reinstalling (even going as far as to do a fresh Windows 8 x64 install) with no positive effects.

And the BSOD error code is different each time. The two recurring ones were attempts to write to READ_ONLY or NOWRITE memory blocks, and the culprit (or at least the only recurring culprit) was always "ntoskrnl.exe," which is apparently a piece of the OS Kernel. Confusing.

Thanks for the replies though, I'm still investigating so any tips are appreciated!

#5 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 22 February 2013 - 09:35 AM

I'm still thinking this is MWO causing some kind of funny behavior in a driver somewhere. Why don't you upload a couple of dump files and we'll see what we've got. I don't know that anything useful will be gleamed from them, but it's worth a shot, IMO.

Besides those two recurring errors, are there any other you've seen?

Edited by Catamount, 22 February 2013 - 09:35 AM.


#6 Oderint dum Metuant

    Member

  • PipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 4,758 posts
  • LocationUnited Kingdom

Posted 22 February 2013 - 09:50 AM

I recommend http://www.resplendence.com/whocrashed

it will give you data on what crashed in a fairly friendly format

Quote

[color=#3C3B3B]On Wed 8/1/2012 11:18:09 PM GMT your computer crashed [/color]
[color=#3C3B3B]crash dump file: C:\Windows\Minidump\080112-10530-01.dmp [/color]
[color=#3C3B3B]This was probably caused by the following module: ntoskrnl.exe (nt+0x7F1C0) [/color]
[color=#3C3B3B]Bugcheck code: 0xA (0xFFFFFA818044DD30, 0x2, 0x1, 0xFFFFF800020FD830) [/color]
[color=#3C3B3B]Error: IRQL_NOT_LESS_OR_EQUAL [/color]
[color=#3C3B3B]file path: C:\Windows\system32\ntoskrnl.exe [/color]
[color=#3C3B3B]product: Microsoft® Windows® Operating System [/color]
[color=#3C3B3B]company: Microsoft Corporation [/color]
[color=#3C3B3B]description: NT Kernel & System [/color]
[color=#3C3B3B]Bug check description: This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. [/color]
[color=#3C3B3B]This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. [/color]
[color=#3C3B3B]The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. [/color]



After a number of crashes it can analyze the results to give you a suggestion if it can.

Other than that, i think this is memory related, since it occurred after the memory upgrade

#7 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 22 February 2013 - 10:05 AM

Crash Dump Analysis

[color="#000000"]Crash dump directory: C:\windows\Minidump[/color]

[color="#000000"]Crash dumps are enabled on your computer.[/color]

[color="#000000"]On Fri 2/22/2013 5:28:23 PM GMT your computer crashed
crash dump file: C:\windows\Minidump\022213-18953-01.dmp
This was probably caused by the following module: [color="#000000"]ntoskrnl.exe[/color] (nt+0x7A040)
Bugcheck code: 0x1 (0x7702C90A, 0x0, 0x20000, 0xFFFFF880113F5B80)
Error: [color="#000000"]APC_INDEX_MISMATCH[/color]
file path: C:\windows\system32\ntoskrnl.exe
product: [color="#000000"]Microsoft® Windows® Operating System[/color]
company: [color="#000000"]Microsoft Corporation[/color]
description: NT Kernel & System
Bug check description: This indicates that there has been a mismatch in the APC state index.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time. [/color]




[color="#000000"]On Fri 2/22/2013 5:28:23 PM GMT your computer crashed
crash dump file: C:\windows\memory.dmp
This was probably caused by the following module: [color="#000000"]ntkrnlmp.exe[/color] (nt!KeBugCheckEx+0x0)
Bugcheck code: 0x1 (0x7702C90A, 0x0, 0x20000, 0xFFFFF880113F5B80)
Error: [color="#000000"]APC_INDEX_MISMATCH[/color]
Bug check description: This indicates that there has been a mismatch in the APC state index.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time. [/color]




[color="#000000"]On Fri 2/22/2013 4:08:36 PM GMT your computer crashed
crash dump file: C:\windows\Minidump\022213-18250-01.dmp
This was probably caused by the following module: [color="#000000"]dxgkrnl.sys[/color] (dxgkrnl+0x4EBA0)
Bugcheck code: 0x3B (0xC0000005, 0xFFFFF88004256BA0, 0xFFFFF8800EC44D90, 0x0)
Error: [color="#000000"]SYSTEM_SERVICE_EXCEPTION[/color]
file path: C:\windows\system32\drivers\dxgkrnl.sys
product: [color="#000000"]Microsoft® Windows® Operating System[/color]
company: [color="#000000"]Microsoft Corporation[/color]
description: DirectX Graphics Kernel
Bug check description: This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in a standard Microsoft module. Your system configuration may be incorrect. Possibly this problem is caused by another driver on your system that cannot be identified at this time. [/color]




[color="#000000"]On Fri 2/22/2013 1:03:30 AM GMT your computer crashed
crash dump file: C:\windows\Minidump\022113-26187-01.dmp
This was probably caused by the following module: [color="#000000"]igdkmd64.sys[/color] (0xFFFFF88004C00C68)
Bugcheck code: 0xD1 (0x486D458, 0x2, 0x0, 0xFFFFF88004C00C68)
Error: [color="#000000"]DRIVER_IRQL_NOT_LESS_OR_EQUAL[/color]
file path: C:\windows\system32\drivers\igdkmd64.sys
product: [color="#000000"]Intel Graphics Accelerator Drivers for Windows 8®[/color]
company: [color="#000000"]Intel Corporation[/color]
description: Intel Graphics Kernel Mode Driver
Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: igdkmd64.sys (Intel Graphics Kernel Mode Driver, Intel Corporation).
Google query: [color="#000000"]Intel Corporation DRIVER_IRQL_NOT_LESS_OR_EQUAL[/color][/color]




[color="#000000"]On Fri 2/22/2013 12:02:59 AM GMT your computer crashed
crash dump file: C:\windows\Minidump\022113-37140-01.dmp
This was probably caused by the following module: [color="#000000"]ntoskrnl.exe[/color] (nt+0x7A040)
Bugcheck code: 0x7F (0x8, 0xFFFFF880009A1DB0, 0x0, 0xFFFFF801E5534B1C)
Error: [color="#000000"]UNEXPECTED_KERNEL_MODE_TRAP[/color]
file path: C:\windows\system32\ntoskrnl.exe
product: [color="#000000"]Microsoft® Windows® Operating System[/color]
company: [color="#000000"]Microsoft Corporation[/color]
description: NT Kernel & System
Bug check description: This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time. [/color]


Those are just the ones I've gotten since my full Windows reinstall. All the old ones were lost, but the error messages were scattered and quite a few that I've never seen before. I'll keep posting as I continue to experience. Thanks for all the help guys!

#8 DocBach

    Member

  • PipPipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 4,828 posts
  • LocationSouthern Oregon

Posted 22 February 2013 - 10:08 AM

Oh god, you don't have a GPU??

#9 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 22 February 2013 - 10:26 AM

Alright, this is giving a much more complete picture. Yes, it's a driver problem and it looks like the culprit is your Intel graphics driver trying to pass bad code onto your kernel in some fashion. I've seen this from GPU drivers before. Why the driver isn't playing nicely with extra system RAM is beyond me (unless the RAM really is bad in some fashion, and that's the problem), but then, Intel's track record with GPU drivers isn't stellar anyways :/

Try going over to Intel and getting a more up-to-date GPU driver. I mean, if worse came to worst, you could just sell off the RAM and live with 8GB, which is likely more than enough for anything that machine would ever be doing, but then idea here is to avoid that option since that's hassle.

Edited by Catamount, 22 February 2013 - 10:28 AM.


#10 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 22 February 2013 - 11:11 AM

View PostDocBach, on 22 February 2013 - 10:08 AM, said:

Oh god, you don't have a GPU??

Huh? Yeah, it's an HD4000 Mobile, why?

View PostCatamount, on 22 February 2013 - 10:26 AM, said:

Alright, this is giving a much more complete picture. Yes, it's a driver problem and it looks like the culprit is your Intel graphics driver trying to pass bad code onto your kernel in some fashion. I've seen this from GPU drivers before. Why the driver isn't playing nicely with extra system RAM is beyond me (unless the RAM really is bad in some fashion, and that's the problem), but then, Intel's track record with GPU drivers isn't stellar anyways :/

Try going over to Intel and getting a more up-to-date GPU driver. I mean, if worse came to worst, you could just sell off the RAM and live with 8GB, which is likely more than enough for anything that machine would ever be doing, but then idea here is to avoid that option since that's hassle.

Thought of that, and tried the latest Intel drivers AND the latest Toshiba-specific drivers for my machine. Both still caused the BSOD. Tried the next version right before the latest from Intel and they still didn't help either. Also, those Intel drivers JUST started coming up in my dump files after my reinstall. Previously, it was only that ntoskrnl.exe.

#11 Kaemon

    Member

  • PipPipPipPipPipPipPipPip
  • 1,924 posts
  • LocationMN

Posted 22 February 2013 - 11:18 AM

Are we to the point where windows 8 is actually stable? I would dual boot a win 7 image and see if you're seeing the same issues, I'm skeptical on windows 8 drivers or even the build at this point.

Just a thought.

Edited by Kaemon, 22 February 2013 - 11:21 AM.


#12 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 22 February 2013 - 11:18 AM

That's the probelm with kernel errors; you don't quite know exactly what's causing them. I still think it was the Intel GPU driver the whole time. The fact that it's bee the culprit twice strongly suggests this.

From the sounds of it, however, Intel doesn't have a fix for whatever the problem is. My advice is just to go back to 8GB or RAM and call it a day. Sell off the new stuff and go back to the configuration that actually worked. I can't imagine you'll actually suffer from having "only" 8GB or RAM :D

#13 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 22 February 2013 - 11:36 AM

View PostKaemon, on 22 February 2013 - 11:18 AM, said:

Are we to the point where windows 8 is actually stable? I would dual boot a win 7 image and see if you're seeing the same issues, I'm skeptical on windows 8 drivers or even the build at this point.

Just a thought.

Tried this, Windows 7 won't boot nicely with the Windows 8 UEFI unfortunately... :wub:

View PostCatamount, on 22 February 2013 - 11:18 AM, said:

That's the probelm with kernel errors; you don't quite know exactly what's causing them. I still think it was the Intel GPU driver the whole time. The fact that it's bee the culprit twice strongly suggests this.

From the sounds of it, however, Intel doesn't have a fix for whatever the problem is. My advice is just to go back to 8GB or RAM and call it a day. Sell off the new stuff and go back to the configuration that actually worked. I can't imagine you'll actually suffer from having "only" 8GB or RAM :D

I know lol, but switching from 12 GB (1 new 8 GB and 1 old 4 GB) to 16 GB (both new 8 GB) I DO see about a 10-15 FPS difference... It's pretty nice, if unnecessary haha.

#14 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 22 February 2013 - 11:57 AM

You're probably seeing the increase because you're switching to a real dual-channel setup, rather than a half dual-channel, half single-channel setup (or does the computer run completely single channel? I don't know how that works) that you get with mismatched 4GB/8GB memory channels, which is feeding your graphics card more bandwidth. This is one of my big complaints with computer manufacturers; they give memory in multiples of 3, instead of powers of 2 like dual-channel RAM is supposed to be set up in. You see laptops that get an "upgrade" from 4GB of RAM to a mismatched 6GB (2+4), or 12GB (4+8) that actually reduces the memory performance of the machine. Why do they do it? I'll be damned if I know :/

You're still going to be hard pressed to use more than 8GB or RAM. I'd be surprised if you were even using more than 4GB. Sell the 8GB DIMMS and get another 4 so you're running 4+4, and you should have good performance.

Edited by Catamount, 22 February 2013 - 12:00 PM.


#15 Oderint dum Metuant

    Member

  • PipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 4,758 posts
  • LocationUnited Kingdom

Posted 23 February 2013 - 12:15 AM

I knew that program would find the problem :P

Im going to agree with cata here, initially at least dial back to 8GB and see if the error persists.

#16 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 25 February 2013 - 04:39 PM

For gaming, no I don't need the extra memory, but I'm also a developer and I use very close to all of it sometimes with my database apps haha. Swapped my sticks out for a pair of Vengance sticks which are working fine so far. I'll be on tomorrow and I'll keep you all posted. Thanks again for the help!

#17 JorDash

    Member

  • PipPip
  • 32 posts
  • LocationHomer, Alaska

Posted 26 February 2013 - 11:21 PM

Just to throw this out there. Most computers can't handle over a certain amount of ram. Also it might just be that your mb doesn't agree with that brand. Here is a link that might help out with that last bit. http://www.newegg.com/MemoryFinder/
of course you probably already know this but it's worth a shot

#18 roflplanes

    Member

  • PipPipPip
  • FP Veteran - Beta 2
  • FP Veteran - Beta 2
  • 83 posts
  • LocationColumbus, OH

Posted 27 February 2013 - 09:49 PM

Alright guys, first of all thank you ALL for your help and support through this issue. Your suggestions and feedback have been IMMEASURABLY helpful to me!

That said, I found the culprit. This is kind of a weird issue, so someone might want to pin this where other Win8/Toshiba/Insyde Corp./Ivy Bridge users can find it for reference.

The Corsair sticks I bought initially were RATED at my motherboard's maximum recognized clock speed of 800 MHz dual-channel (1600 MHz total) and their capacity was WELL within my laptop's capabilities. Their latencies were the only mechanical difference between the upgrade sticks and the stock ones (newer sticks were actually a bit higher-latency than my old ones), or so I thought.

I noticed, but didn't think anything of, the fact that in every CPU monitoring/rating application I used, my memory's clock speed rating for it's top-tier JEDEC rating was actually 814 MHz. Now, since those JEDECs are only theoretical ratings based on proposed clock speeds and the corresponding latencies you'd see from USING those speeds, I didn't think anything about it at the time. When I swapped my sticks out for a (theoretically identical except for a slightly lower latency) pair of (still Corsair) Vengeance sticks and my problems all went away, I did some digging. The REAL-TIME clock speed (according to CPU-Z and the Intel Extreme Clocking App Thingey) never exceeded 798.xx MHz, but the RATED max clock speeds for the memory's highest-level JEDEC rating was exactly 800 MHz on the working sticks, and 814 MHz on the broken ones (both sets).

I bought another pair of the original Corsair sticks I had purchased, verified that all the specs were the same, and played some MW:O... and bluescreened within a couple of matches. Consistently. So I swapped my Vengeance sticks back in and played without issue. I retested this theory two or three times (until I was bored and fed up lol) then took the (seemingly factory-overclocked?) sticks back to the store and have been happily using my Vengeance sticks ever since.

Long story short... learn from my mistakes. And if anyone can explain to me the discrepancies between the theoretical JEDEC clocks I was seeing and my actual monitored speeds, I would GREATLY appreciate the free education. Because I'm stumped. Happy to be playing MW:O again, but stumped. :lol:

Thanks again guys, and I hope this can help someone else!

Edited by roflplanes, 27 February 2013 - 09:56 PM.


#19 Catamount

    Member

  • PipPipPipPipPipPipPipPipPip
  • LIEUTENANT, JUNIOR GRADE
  • 3,305 posts
  • LocationBoone, NC

Posted 28 February 2013 - 06:31 AM

The odd JEDEC information might well have thrown your machine off. It's hard to say. The only way to really test it would be to use me or modules with the same problem from another company to make sure it isn't some other problem with those modules.

#20 Bad Karma 308

    Member

  • PipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 411 posts

Posted 28 February 2013 - 02:11 PM

A good start to diagnose the RAM would be to run a test against each stick of ram and see if one or more of them may be slightly off spec or possibly even defective. JDEC or not sometime you get a less that optimal memory bank that cant quite meet the spec it is trying to deliver. Then that throws the whole Dimm stick into a wonky state, which only further propagate the issue all the way up to the controller.

Memtest86+ ( http://www.memtest.org/ ) will do run some serious diagnostics against your ram and let you know if anything is at fault. Grab the bootable ISO file and then use a ISO-to-USB tool to make a bootable thumb drive. Or you can can send it to a optical disk.

Microsoft offers a really good one but there are many out there to choose from as well.
http://www.microsoft..._usbdvd_dwnTool

Don't forget to set your BIOS to boot from whatever media source you choose (Optical/USB)

Then the best way is to test with only one stick at a time installed. And let it run two full test before moving to the next stick.

Many RAM vendors will ask you to run this exact test (or their licensed copy of it) before issuing an RMA.

Either way Memtest is a great tool to have in your PC toolbox.

Edited by Bad Karma 308, 28 February 2013 - 02:17 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users