Vista - BSOD Driver problem?

Long story short I recently installed 64-bit Vista to take advantage of all 4 gigs of memory in my rig. The first few days everything worked well, finally got a wireless g adapter that would work, latest nVidia drivers etc.

However, last night I had a friend over and we hooked up his router and LAN'd, I then had to install the drivers for my motherboard's network adapter. Install went fine, lan'd pretty well for a couple of hours (sins of a solar empire, great game :P) However, I then got a BSOD and restarted. Anyway, been having BSOD's every hour+ after that starting when I booted back up this mornings.

I followed the little guide to check dump files and well results were inconcluisve but hinted at a driver problem, also said possible memory problem which is unlikelyy, I ran memtest for 24hours+ when I built the rig back in january with no errors.

I had also recently removed the older PCI-Network adapter which had no 64-bit drivers and spent a week trying to get working when I switched over to a USB adapter.

Anyway I don't know what to do, all drivers are installed and up to date. Attached are all 4 dump files.

Please help

Based on those minidumps, I'd say its entirely possible that you've got a hardware problem, irrespective of whether memtest has found anything or not (it doesn't always).

Otherwise, you've also got at least one known-bad driver:

Image path: \SystemRoot\System32\Drivers\secdrv.SYS
Image name: secdrv.SYS
Timestamp: Wed Sep 13 23:18:38 2006 (4508052E)

That's a "SafeDisc" game protection mechanism and that particular build of the driver is a known memory corruptor. Try to update it because merely removing it would knock out your ability to play the related games - they're encrypted on-disc and that driver has the job of facilitating the files' decryption at game runtime.

Also, a few other drivers you might want to update, purely based on age:

Image path: \??\C:\Program Files (x86)\EVGA Precision\RTCore64.sys
Image name: RTCore64.sys
Timestamp: Wed May 25 16:39:12 2005 (42941D90)

Image path: \SystemRoot\system32\DRIVERS\bcmusbdhdlh64.sys
Image name: bcmusbdhdlh64.sys
Timestamp: Wed Jan 09 07:52:33 2008 (4783E291)

You might want to remove AVG long enough to check whether it makes any difference to the crash pattern.

My gut feeling is that you've got a hardware problem

Alright, I have been running the computer in test mode all afternoon and no crashes. Not even a hiccup.

How would I update safedisc? I can't seem to find a site to simply download a newer version.

Also what is bcmusbdhdlh64?

Tonight, unless I get another crash before then, I will run memtest all night, hasn't been ran since january and I have been in and out of my case since then though I am very careful to keep grounded.

Got another minidump, crashed again after about 1 1/2 hours of playing Sins of a Solar Empire

4e was the BCCode

An entirely different crash pattern to the others, except for the fact that the immediate problem is once again memory corruption. It's theoretically possible that a driver is doing wild writes which corrupt memory assigned to other drivers (thus leading to crashes), but you're running an x64 build of Windows which makes it far more difficult for bad or unsigned drivers to find their way into kernel-mode (unless you helped them by deliberately circumventing the mechanism).

Even standard driver development debugging techniques ("special pool") will not help in some of the types of crashes your machine is logging:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See Patching Policy for x64-Based Systems: Changes in policy that are related to patching the kernel for the x64-based versions of Microsoft Windows Server 2003 and Microsoft Windows XP Professional x64 Edition operating systems
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.

You can forget about "2", so your problem is either "1" or "3". I'm virtually certain it's "3" - in fact, it looks like the same exact portion of virtual memory was unreliable in at least two of your crashes:

1: kd> ln fffff80001cb946f
(fffff800`01d5fdd0) nt! ?? ::NNGAKEGL::`string'+0x31a40 | (fffff800`01d5ffec) nt!MiAdvanceVadHint

The physical memory backing virtual memory at location fffff80001cb946f appears to have been corrupted in two crashes. I'd be very surprised if this turned out to be anything but bad hardware. If you're overclocking, that's not a good idea. If the machine is insufficiently cooled, that can lead to crashes also. Check the power supply and replace it temporarily with another one if you can. Try blowing compressed air onto the RAM DIMMs and reseating them...

Good luck with it.

Could it be a hard drive issue? I have had issues with this particular HDD in the past.

I am 99.999% certain its not a cooling problem, I don't overclock, have a Zalman heatsink and temps on either core never pass 45C. Case has 4 120xmm fans, 2 intake, 2 exhaust, board temp on load is 38C, RAM has heatsinks.

I will try reseating the RAM. If that doesn't work, I will probably just go back to 32-bit (its still installed on the other hard drive) and see if I have any crashes there. If I don't then problem solved, if I do.... well a buddy of mine has a PSU tester.

Running memtest on that rig as we speak hopefully that will clearly point out a RAM issue if it is one.

Something is up with the USB drivers now, my mouse wouldn't move on start up. So I just turned off the computer and started memtest.

Once you suspect that bad hardware might be involved, all bets are off and almost any symptom is possible, but I doubt it's your HDD.

If the on-disk NTKRPAMP.EXE image was itself corrupt, that would be picked up sooner and it would presumably crash sooner too. Instead, in the two instances of your 0x109 crashes, that image starts off in memory perfectly intact, only to be damaged either by the actions of a kernel-mode driver, or by the fact that at least some of the memory backing it is unreliable. Think of it as a "bad sector", except in RAM - not the HDD.

It's still possible that it is a driver that's responsible, by making wild writes which overwrite critical data, but this degree of "wildness" won't be caught by "driver verifier". Since you're down to reinstalling, you might as well try verifier first though...

1. Run VERIFIER
2. "Create standard settings"
3. "Automatically select all drivers"
4. finish
5. reboot
6. wait and see whether the next BSOD pinpoints a driver as responsible

I followed that last set of steps, no crashes for a few hours then one.

Memtest was clear after 6 passes, but as you said not conclusive.

Attached crash from last night and this recently.