BSOD Blues

[-JR- Mumbler]

Greetings all:

I've been the unhappy victim of a series of BSOD crashes lately, and since there are a lot of techies who frequent these boards, I'm hoping someone can give me some insight into my dump file (Mxy?).

The crash happens while playing the Oblivion Lost 2.2 mod for Stalker Shadow of Chernobyl v1.005, and I've been playing this game for a long time without any problems until now.  All my drivers are up to date, and I haven't installed any new hardware/software (aside from the Auto Update function of Windows).  Here are my system specs:

OS:   Windows 7 Professional 64 bit (6.1, Build 7601)
CPU:   Intel Core 2 Duo (Conroe 6600) @ 2.4 GHz
Mobo:   Gigabyte 965P-DS3 (P965 Express ICH8)
GPU:   EVGA GeForce GTX 550 Ti 2GB
RAM:   6GB Corsair XMS2 DDR2 800
HDD:   WD Caviar Blue 500GB 7200rpm SATA
PSU:   Antec Basiq 550W
(I know, I know, it's old--stop laughing, I'm poor!)

I was really hoping the minidump would identify a simple driver problem, but unfortunately, as you can see from the results WinDbg below, it was " Probably caused by : CI.dll ( CI!I_ReloadCatalogs+199 )," which is no help at all (at least to a noob like me).

My failed attempts at fixing:

Ran Startup Repair and hit system restore (no help)
Ran memory test (memcheck says memory modules are fine)
Ran sfc /scannow (nothing)
Uninstalled/reinstalled game and mod (still get BSOD w/probable cause as CI.dll after a couple of minutes of gameplay)

At the risk of muddying the waters a bit, I'll point out another problem that may or may not be related to this issue: After the first BSOD, my AVG antivirus stopped working.  I've uninstalled/reinstalled AVG three times and have a work order in with their "advanced" tech support, but they haven't gotten back to me with the results of the diagnostic data in several days.  Maybe I'm guilty of a post hoc fallacy here and the virus scanner problem is only a coincidence, but now I'm also suspicious of a rootkit infection. Unfortunately, I have no way of scanning this drive because I don't have a HD enclosure and no $ to buy one for a few days.

I'm at the point where I'm considering a nuke & pave solution, which I really don't want to do, not only because it's a time-consuming pain in the butt, but also because I don't know how many more times M$'s fascist licensing policies will allow me to install some of their newer programs.  Anybody have any suggestions before I reformat?

The minidump and Debugger's analyze-v results are pasted below:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\022512-22593-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02e1e000 PsLoadedModuleList = 0xfffff800`03063670
Debug session time: Sat Feb 25 21:25:33.125 2012 (UTC - 8:00)
System Uptime: 0 days 0:00:16.953
Loading Kernel Symbols
...............................................................
.......................
Loading User Symbols
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {ffffffffc0000005, fffff80003172344, fffff880031f37e8, fffff880031f3040}
Probably caused by : CI.dll ( CI!I_ReloadCatalogs+199 )

Followup: MachineOwner---------

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

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.

Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80003172344, The address that the exception occurred at
Arg3: fffff880031f37e8, Exception Record Address
Arg4: fffff880031f3040, Context Record Address

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

FAULTING_IP:
nt!RtlCompareUnicodeStrings+44
fffff800`03172344 470fb70411      movzx   r8d,word ptr [r9+r10]

EXCEPTION_RECORD:  fffff880031f37e8 -- (.exr 0xfffff880031f37e8)
ExceptionAddress: fffff80003172344 (nt!RtlCompareUnicodeStrings+0x0000000000000044)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

CONTEXT:  fffff880031f3040 -- (.cxr 0xfffff880031f3040)
rax=000000000000003b rbx=000000000000003b rcx=fffff8a0001ee06e
rdx=0000000000000050 rsi=fffff98000020654 rdi=000000000000003b
rip=fffff80003172344 rsp=fffff880031f3a28 rbp=0000000000000133
 r8=00fff8a000b8ef80  r9=01000000009a0f12 r10=fffff8a0001ee06e
r11=fffff8a0001ee0e4 r12=0000000000008004 r13=fffff880031f3c40
r14=0000000000000000 r15=0000000000000001
iopl=0         nv up ei pl nz ac po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010217
nt!RtlCompareUnicodeStrings+0x44:
fffff800`03172344 470fb70411      movzx   r8d,word ptr [r9+r10] ds:002b:00fff8a0`00b8ef80=????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

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

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  ffffffffffffffff

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030cd100
 ffffffffffffffff

FOLLOWUP_IP:
CI!I_ReloadCatalogs+199
fffff880`00c0e451 85c0            test    eax,eax

BUGCHECK_STR:  0x7E

LAST_CONTROL_TRANSFER:  from fffff8000313613e to fffff80003172344

STACK_TEXT: 
fffff880`031f3a28 fffff800`0313613e : 00000000`00000000 00000000`00000133 fffff8a0`001ee010 00000000`00000082 : nt!RtlCompareUnicodeStrings+0x44
fffff880`031f3a30 fffff880`00c0e451 : 00000000`00000000 fffff8a0`00b6e5d8 00000000`00c50000 ffffffff`800001b4 : nt!RtlCompareUnicodeString+0x26
fffff880`031f3a70 fffff880`00c0d3e7 : ffffffff`800001ac 00000000`c0000428 fffff880`031f3f48 00000000`00000000 : CI!I_ReloadCatalogs+0x199
fffff880`031f3c10 fffff880`00c0b9cd : fffff880`031f3e60 00000000`00000001 fffff880`00000000 00000000`00000000 : CI!I_FindFileOrHeaderHashInCatalogs+0x10b
fffff880`031f3cb0 fffff880`00c0c381 : fffffa80`06588750 fffff880`031f3e60 00000000`00008004 00000000`00000000 : CI!CipFindFileHash+0xf9
fffff880`031f3d80 fffff880`00c0afbb : 00000000`00000001 fffff880`031f4040 fffff880`031f4040 00000000`00000000 : CI!CipValidateFileHash+0x311
fffff880`031f3ef0 fffff800`03107a44 : 00000000`000000f4 00000000`000fffff fffffa80`06588750 00000000`00000000 : CI!CiValidateImageHeader+0x213
fffff880`031f3fd0 fffff800`0310784a : 00000000`00000000 00000000`00000080 fffffa80`06540d10 00000000`00000000 : nt!SeValidateImageHeader+0x58
fffff880`031f4010 fffff800`03198086 : fffffa80`06588750 fffffa80`06540d10 00000000`00000001 00000000`000000f4 : nt!MiValidateImageHeader+0x21a
fffff880`031f40e0 fffff800`03176596 : fffff880`031f4330 fffff880`031f4450 fffff880`031f45e8 00000000`00000001 : nt!MmCreateSection+0x966
fffff880`031f42e0 fffff800`02e99ed3 : fffffa80`04f08680 fffff880`031f4588 fffff880`031f4378 00000000`00000000 : nt!NtCreateSection+0x171
fffff880`031f4360 fffff800`02e96470 : fffff800`03272c26 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`031f4568 fffff800`03272c26 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiServiceLinkage
fffff880`031f4570 fffff800`03272fec : ffffffff`80000190 fffffa80`00100000 fffffa80`04f4c0a8 00000000`000004ef : nt!MmCheckSystemImage+0x96
fffff880`031f46a0 fffff800`03273207 : ffffffff`80000190 fffff800`00000001 00000000`00000000 00000000`00000000 : nt!MiCreateSectionForDriver+0xcc
fffff880`031f4750 fffff800`0327edfd : 00000000`00000000 00000000`00000000 fffffa80`04f08680 00000000`00000000 : nt!MiObtainSectionForDriver+0xd7
fffff880`031f47b0 fffff800`03281a9d : fffff880`031f4928 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmLoadSystemImage+0x23d
fffff880`031f48d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopLoadDriver+0x44d


SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  CI!I_ReloadCatalogs+199

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: CI

IMAGE_NAME:  CI.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7c944

STACK_COMMAND:  .cxr 0xfffff880031f3040 ; kb

FAILURE_BUCKET_ID:  X64_0x7E_CI!I_ReloadCatalogs+199

BUCKET_ID:  X64_0x7E_CI!I_ReloadCatalogs+199

Followup: MachineOwner
---------

[MrMxyzptlk]

[...] The crash happens while playing the Oblivion Lost 2.2 mod for Stalker Shadow of Chernobyl v1.005, and I've been playing this game for a long time without any problems until now.  All my drivers are up to date, and I haven't installed any new hardware/software (aside from the Auto Update function of Windows). [...]

That sounds like the scenario of a heat problem, to me.  (The ones that "pop up out of nowhere" and nothing has changed in a long time....)

Check that fans are working and heat sinks are hot to the touch (and your case is clean) while I look into the BSOD details....

BBIAB!


*edit*  All Things seem to point to a possible memory fault as the root cause.  Memory may be: overheating (dirty fins / poor thermal design on mobo), in need of reseating, or failing (in order of likelihood from most to least.)

NOTE: Only place memory on a static-free surface, and ground yourself before touching any components!

Suggested Action: Boot and run with case open. As soon as it's running, lightly touch memory fins to get a feel for heat level.  Once machine crashes touch memory again and determine if is MUCH hotter when crashed. (Like charcoal briquette hot!) If so, that's likely your problem: Poorly cooled or now-failing memory due to heat damage.

If heat doesn't seem like the answer: After checking and a light cleaning around the memory and memory slots see if it runs better/longer.

If still not working, then: You'll need to pull all the installed memory sticks and replace/test them one at a time. (OR remove one at a time and try all combinations, which takes longer and is more prone to problems, but possible.)  Try the same touch heat check above on each stick: you may find one that gets hotter than the others.

Sorry that this is such a tedious process, but it's what should be checked into before looking further into things like drivers....

*edit* As for the AVG, etc. stuff: It's entirely possible that the install got corrupted by the faulty memory when you tried it.  In fact, anything that you've done since this first started to occur could've been just causing a cascade of additional failures....  


We're also going to want to similarly check the GPU for dirt/overheating/seating if none of the above pan out....

[BFM_Crimson]

I will admit that I didn't read even 1/4 of that, but I saw AVG and BSOD and I though to myself, one of my clients was recently getting BSOD's on one of their workstations, and it turned out that AVG had somehow managed to fill up the C drive with .doc files. That's probably not what it is reading the first sentence of Mxy's post.


Hi Mumbler!

[-JR- Mumbler]

Hi Mxy:

Thanks for your (as always) sage counsel.  I'll start puttering around w/the RAM tonight.

A note on heat as the potential problem, though.  As someone who has melted a video card or three after marathon gaming sessions, that was the first thing that came to mind in the wake of the initial BSOD.  I pulled off my side cover and discovered minimal dust (just blew it out maybe two or three weeks ago).  Also, one of the virtues of my fan-festooned Antec 1200 case is that it stays pretty frosty overall: GPU at idle runs ~30C and under load runs ~57C (at most).  After the first crash, I started up EVGA Precision to monitor GPU temp while playing, and right before the 2nd crash, it was 54C (fairly typical for that game). I'd be surprised if this problem turns out to be GPU related. RAM may be another matter.

While I haven't yet taken any of the RAM sticks out, I did feel them yesterday after playing Crysis (to see if other system intensive games caused a crash); Crysis ran fine, the GPU never went above 57C, and although all the DIMMs were pretty warm, I couldn't feel any anomalous heat (no glowing coal) from a particular one.  (It occurs to me, however, that my hands make wonderful sandwich clamps but crude thermometers).  I'll post more once I test the sticks individually.

*edit* As for the AVG, etc. stuff: It's entirely possible that the install got corrupted by the faulty memory when you tried it.  In fact, anything that you've done since this first started to occur could've been just causing a cascade of additional failures.... 

FYI: I tried starting up EVGA Precision a while ago, and I got a dialogue box which read "Some of the components of this program are missing or corrupted."  I guess that lends credence to your supposition about a cascade of additional failures . . .

ps: Hi Crimson!   

[MrMxyzptlk]

Sounds like the case and GPU are well cooled, so things point to questionable RAM.

Advice I forgot to mention: Try to disable anything that you can - such as AVG - before going to deeply into the per-stick RAM testing, as things may run soooooo sllloooowwwwllllyyyy on a single stick of RAM that it will either be murder to test, or fail due to insufficient system memory.

NBD if you don't do the above, but reducing RAM usage before going through them will go more smoothly iff running "bare bones."

GL....

[-JR- Mumbler]

Hey Mxy:

My 6GB RAM is in four dual channel sticks: (2 X 1GB) and (2 X 2GB).  I could run the 2GB sticks individually, but since minimum system requirements for 64bit Windows call for 2GB RAM, I couldn't test the 1GB sticks individually.  Windows worked with all 2GB combos, though (although slowly).  Also, the memory diagnostic I reported above was only the standard 2 pass test.  Last night I let the memory diagnostic run multiple passes overnight and no errors were reported.

Nonetheless, in the vain hopes that reseating the DIMMs magically solved the problem, I fired up RAGE this morning . . . but got two back-to-back BSODs.

For some reason, WinDbg couldn't read the dump files (I couldn't figure out why my symbol path wasn't working), so I downloaded the free version of WhoCrashed, which gave me this:

crash dump file: C:\Windows\memory.dmp
This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0)
Bugcheck code: 0x7E (0xFFFFFFFFC0000005, 0xFFFFF800025C1CD7, 0xFFFFF880021CDA18, 0xFFFFF880021CD270)
Error: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Bug check description: This bug check indicates that a system thread generated an exception that the error handler did not catch.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time.

crash dump file: C:\Windows\Minidump\030412-27953-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40)
Bugcheck code: 0x3B (0xC0000005, 0xFFFFF80002EDCB65, 0xFFFFF88007906C50, 0x0)
Error: SYSTEM_SERVICE_EXCEPTION
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
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 the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time.

I poked around on a few tech boards and read that the ntoskrnl.exe / ntkrnlmp.exe problem(s) could be caused by drivers or by a number of other things (like mobo failure or PSU fluctuation).

A reformat/reinstall is starting to look more attractive to me now.    Do you have any suggestions before I pursue this?

Best,

-M

[MrMxyzptlk]

Ya, that's a pretty generic crash situation, and is virtually impossible to track to a source of any merit....

I'd suggest TWO passes at letting Windows Update update your drivers by following the instructions here. DO NOT update any non-WHQL-certified drivers, tho. (Hopefully getting WHQL certified drivers should stabilize things.... Also, if there are no NEW WHQL drivers then skip all this and go for the nuke & pave....  )

You'll likely need to do a reboot between the two passes, BTW.

GL with the brain surgery! 

[-JR- Mumbler]

Hi Mxy et al:

I've got one last plea for assistance before I do a nuke & pave, and this goes out not only to Mxy (to whom I am indebted), but also to anyone who owns an older Gigabyte mobo . . .

I thought I'd try flashing my BIOS as a penultimate resort to solving my BSOD headaches, but Qflash (the Gigabyte flashing utility in DOS) will not recognize my USB drive.  I've formatted my flash drive in FAT32, tried several different flash drives and all my USB ports (back and front), set "Floppy A" to "none" in CMOS (there isn't a floppy drive on the computer), enabled USB support in CMOS, and set my first boot drive to USB HDD, but thus far, nothing works: my only two choices in the Qflash menu are 1) Update BIOS from Floppy and 2) Save BIOS to Floppy; there is no option to update from a drive, and entering the "update from floppy" option results in an unsurprising "Access Floppy Disk Error."

I do NOT want to flash my BIOS in Windows with the @bios utility--my Windows system is already unstable and the risk of toasting my mobo too great.

I wrote a tech support query to Gigabyte on this issue, and while they responded, they apparently didn't bother to read my question at all because the only thing I got back was a set of bonehead instructions on how to flash BIOS, which I already know how to do.

Has anyone with a GB mobo experienced this drive recognition problem with Qflash? 

I never thought I'd see the day when I missed having a 1.44 floppy . . .

Yours in total discombobulation,

-M.

[ËQINÖX]

I have an older Gigabyte mobo and if i remember the last time i attempted to update the bios i had the same problem in the end i resorted to using the the windows bios installer and well all went  well it said  its all updated and to click reboot to finish the update and when it rebooted i was presented with a nice black screen and allot of beep error codes. Luckily the Gigabyte mobo i have has a bios back up built into it so as soon as i powered down and then back up again the bios was auto restored back to the last safe bios version that was running after that i decided the risk of updating the bios was simply  not worth it.
So i guess what I'm saying is its unlikely to be a bios issue causing the BSOD (That's not to say it isn't but its the least likely) its more likely down to a corrupted OS or hardware fault. I personally would nuke the hard drive and start over this eliminates the software side and if all works then great. If it does not work then at least you have eliminated the software as a factor and this means that its a hardware problem. Since you have already tested the ram its really next to the mobo and PSU and perhaps the GPU and well the mobo and gpu you cant really test and well i remember sometime back getting random crashing and i replaced the PSU and all worked perfectly after that but as we know good quality PSUs are not cheap and it can be allot of cash buying parts to swap out when you don't know what has actually gone faulty.

Again i would stress that flashing your bios is very dangerous even on a stable computer and can result in a corrupted bios and turn your nice comp into an expensive paper weight and well if your comp is not stable and has an unknown fault attempting to flash the bios could only add to the fault list if it was to fail.

[-JR- Mumbler]

Hi Equinox:

Thanks for your comments.  I ended up doing a fresh Windows install, but unfortunately, I'm still getting the BSODs (and I haven't even finished reinstalling all my games/programs yet).  It could very well be a hardware issue, as you say, but I won't have the $ to throw at new components until I get my tax refund.

In the meantime, I'm still interested in getting Qflash to work.  I realize flashing BIOS is risky, and I'd never do it through a Windows program, but some of the new BIOS versions may help (at least other people have reported as much on a few tech forums).  And I've never had a problem when flashing in DOS (fingers crossed). I'm engaged in some exasperating correspondence with the Gigabyte techies right now (who keep telling me things I already know), and if I ever figure out how to get Qflash to read a drive other than a floppy, I'll shoot you a PM.

-M.

Latest dump:

On Sat 3/10/2012 11:50:47 PM GMT your computer crashed
crash dump file: C:\Windows\memory.dmp
This was probably caused by the following module: win32k.sys (win32k!EngRestoreFloatingPointState+0x4B34)
Bugcheck code: 0x19 (0x3, 0xFFFFF900C235EA60, 0xFFF900C235EA60, 0xFFFFF900C235EA60)
Error: BAD_POOL_HEADER
file path: C:\Windows\system32\win32k.sys
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: Multi-User Win32 Driver

Bug check description: This indicates that a pool header is corrupt.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules.
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 which cannot be identified at this time.

[MrMxyzptlk]

Ugh, the BAD_POOL_HEADER fault is about as general as what you were getting before.    That can be anything from one (or more) driver(s) faulting, to a corrupt Registry. (And since you just did a nuke & pave, it's not likely to be your Registry....)

As for getting Qflash to work: This is exactly why I have a USB Floppy Drive!  (Okay, full disclosure: I have THREE of them!  )

Bad BIOS is pretty rare (more rare than driver and/or component failures) - a failing mobo would only be slightly less probable.

Since you've now got a "clean system" installed and are still getting errors, I'd suggest another route for you, tho.  Please see my PM about that.

[-JR- Mumbler]

S O L V E D !

Finally isolated a bad RAM stick.

As usual, Mxy demonstrates his genius--his first call was the right call.

My own idiocy was that when I first pulled the DIMMs, I tested to see if they worked, but not if they failed under load: i.e., all the sticks worked well enough to run Widows (barely), but none of my newer games would run decently on only two gigs.   After I ran intensive games on just the newest 4 gigs, viola--no more BSOD.

And no more hours spent reading crash codes and debugs. 

And it was the cheapest component to fail, which is great news for an insolvent dude.

Thanks Mxy & Equinox.

-M

ps: It might be worth noting, for those suspicious of faulty RAM, that neither Memtest86+ nor the internal Windows Memory Diagnostic turned up any problems after multiple passes.

[MrMxyzptlk]

Glad to hear you caught it!  (I was beginning to worry....  )

Yes, I, too, have discovered that MemTest86 alone does not cut the mustard.  (I think it might be the additional load on the mobo/PSU having the GA running hard, too?)

So I usually test with 3Dmark or the like.

Glad that you're back online again, Mumbles!