BSOD, need help with dumps

Hi Major Geeks,
I've been away a while, very busy, but I'm back now

I have had an unwelcome niggle affect my PC for the last 3 months, BSOD
It usually strikes about 5 mins after startup & maybe randomly after that, more likely during gaming than surfing etc.

I was wondering if anybody would be able to help & take a look at the DMP files. I have Corsair XMS2 DDR2 1066Mhz RAM installed but have never been able to run it above 800Mhz & if that wasn't annoying enough now I get BSOD's everytime I start up :mad

:major2-Bit-Geek:major

 

Ok so, I've been at this all night trying to find out what the problem is with debugging tools for windows & this is what I have turned up...


Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\061810-25474-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Machine Name:
Kernel base = 0xfffff800`02a1b000 PsLoadedModuleList = 0xfffff800`02c58e50
Debug session time: Fri Jun 18 18:58:00.210 2010 (UTC + 1:00)
System Uptime: 0 days 0:20:55.270
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
.............................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff88005d9fff8, 2, 1, fffff8000301402e}

*** WARNING: Unable to verify timestamp for hal.dll
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntoskrnl.exe ( nt+70600 )

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

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

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: fffff88005d9fff8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff8000301402e, address which referenced memory

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff80002a1b000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cfeb

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
fffff88005d9fff8

CURRENT_IRQL: 0

FAULTING_IP:
hal!memcpy+25e
fffff800`0301402e 48894118 mov qword ptr [rcx+18h],rax

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from fffff80002a8ab69 to fffff80002a8b600

STACK_TEXT:
fffff880`02f228c8 fffff800`02a8ab69 : 00000000`0000000a fffff880`05d9fff8 00000000`00000002 00000000`00000001 : nt+0x70600
fffff880`02f228d0 00000000`0000000a : fffff880`05d9fff8 00000000`00000002 00000000`00000001 fffff800`0301402e : nt+0x6fb69
fffff880`02f228d8 fffff880`05d9fff8 : 00000000`00000002 00000000`00000001 fffff800`0301402e fffffa80`06124000 : 0xa
fffff880`02f228e0 00000000`00000002 : 00000000`00000001 fffff800`0301402e fffffa80`06124000 00000000`00000000 : 0xfffff880`05d9fff8
fffff880`02f228e8 00000000`00000001 : fffff800`0301402e fffffa80`06124000 00000000`00000000 00000000`00000000 : 0x2
fffff880`02f228f0 fffff800`0301402e : fffffa80`06124000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x1
fffff880`02f228f8 fffffa80`06124000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!memcpy+0x25e
fffff880`02f22900 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`06124000


STACK_COMMAND: kb

FOLLOWUP_IP:
nt+70600
fffff800`02a8b600 48894c2408 mov qword ptr [rsp+8],rcx

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+70600

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

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

Sorry it's very long I know, but this is only a mini dump :confused

I know I am using the wrong symbols, but they are the most up-to-date ones on Microsoft's site :confused

The proble seems to be, "ntoskrnl.exe ( nt+70600 )". Could that be wrong due to the incorrect symbols even though I've re-run it a few times? If not, what is it & how do I fix it?

Thanks for taking the time to read it & extra thanks if you can help

:major2-Bit-Geek:major

 

Yes. You're going to have to use the correct debugger symbols to get an accurate mini-dump analysis.

Any chance you can attach the latest crash dump instead?

 

Thanks for taking a look

If I could find the correct symbols for an OEM Windows 7 Pro 64Bit (Think it's an upgrade version, does that matter? It's upgraded from an old XP SP2 32BIT I had lying around :-D) I would, the ones I have found on the Microsoft site are the latest aparently :confused I just have no idea why they wouldn't work.

That is the most up-to-date crash dump & the test was run several times to make sure the results were the same.

:major2-Bit-Geek:major

 

Thanks for taking a look Halo

I cannot attach DMP files to MG it seems to be an invalid file :confused

I havn't try'd in safe mode, but I will have by next reply

It's a fairly new mobo (ASUS M4A78-E) so I did indeed get ahold of all the W7 64BIT drivers needed.

I have no yellow exclamation marks in device manager, it's the first thing I looked at & there are still none.

It was a custom install of a student W7 Pro 64BIT, all you really need (as far as I understand) is a copy of windows XP or later. I was using W7 RC 64 BIT before that so I had to do a clean install of XP & before I installed anything on it I "upgraded" to W7. I don't fully understand it myself but, I have had 0 issues other than BSOD from this Corsair XMS2 RAM. I had no issues with the Kingston Hyper X I had before on W7 RC 64BIT :confused

:major2-Bit-Geek:major

 

Does anybody have any ideas at all?

:major2-Bit-Geek:major

 

Do you get told it's an invalid file when trying to upload the file, or when you export it from the Error Viewer?

Also what does your BSOD say? I haven't spent much time on Windows 7, but on earlier version of Windows the message typically mentions a particular file (driver) that caused the crash. Most of the time it's a DLL for your graphics card which often indicates heat problems, though I also often see them relating to hard drive failures. If you get errors just trying to generate the list in the Event Viewer, that can definitely mean a hard drive failure.

However given your first post, a problem on your RAM would definitely match the results your seeing. When you first start your computer and heavy use are the two times you're accessing lots of RAM (although they are also times you access lots of locations on your hard drive too).

If you actively want to run tests to lead to the solution yourself, then I'd suggest burning an Ultimate Boot CD and then using it to:
a) Scan your memory using Memtest - let it run overnight
b) Scan your hard drive - select the correct hard drive manufacturer, and the scan will take an hour or so
c) Connect your monitor to the motherboard rather than your graphics card, and see if the problem persists

Other than that, we'd really need to get a hold of your error logs, and the details of the BSOD.

 

I got this message from the MG (manage attachments) file uploader: Upload Errors
061810-25474-01.dmp:
Invalid File

Well windows debug had this to say: Probably caused by : ntoskrnl.exe ( nt+70600 ), Though having the wrong syimbols, (which the MS site said were correct) I am not sure how accurate that is... or even what that exe is for :confused

I know my GPU is not too hot as it never even gets to 60C & it's safe to run it up to 100C aparently As for the OS HDD it's only 3 months old & on it's first OS, it is a bit hotter than the other HDD's but that could just be down to the fact that it's the only HDD that's active all the time. It's at 42C atm, but it is a very hot day here in the Uk today, it's above freezing & everything lol :-D

RAM is a where it gets sketchy, it's 2X Corsair XMS2 PC8500 1066MHZ (TWIN2X-4096-8500C5 G) isn't in my mobo's RAM QVL :confused

I have had bother with RAM for years now, I had X4 sticks of Kingston Hyper X DDR2 1066 & that wouldn't go up to 1066MHZ without crashing or becoming unstable, now I have Corsair XMS2 1066 I have the same problem & it could be causing the BSOD :cry I hate RAM lol

Though, the BSOD isn't as soon as my PC starts up, it's about 10-15 mins into use, sometimes longer, rarely not at all. But then there are random crashes during gaming.

I have burned The Ultimate Boot CD & will run the mem test tonight & try the HDD test tomorrow, as for hooking the moniter up to the mobo's DVI, I'll give it a go tomorrow too.

Thanks for helping, I'll keep you updated

:major2-Bit-Geek:major

 

Don't rule out the hard drive just yet. Heat is one factor in them failing, but there's a bunch of causes. It sounds like you take pride in your comp, which probably tells me you have a huge hard drive. The larger the hard drive, the more likely they'll fail, simply because you'kk have one or two more platters than normal, meaning more laser thingies (the name escapes me atm) to crash against a platter, more heat, more vibration etc etc.

ntoskrnl.exe is a critical component of Windows 7 by the looks of it. 'ntos' would translate as the Windows NT family of Operating Systems, and 'krnl' translates as the Kernel, which is the very basic piece of software that runs directly to the hardware of your computer. I haven't looked it up in close detail, but I expect it's Windows 7 kernel executable. If this is the file crashing in the BSOD then either:

1. The Windows installation is corrupt
Rare really. The cure for it also cures several other causes, so people like to diagnose it as such out of laziness. To fix it try updating or reinstalling Windows (which also has the effect of refreshing all your drivers, which is much more likely to be the cause).

2. Bad hardware or hardware driver
This one's quite possible for your situation. It means some piece of hardware did something it wasn't supposed to, and rather than the driver presenting an error, the problem stayed hidden until the kernel tried to act on the odd information, which made it pop up with an error. The solution is to update/rollback the bad driver, or replace the faulty hardware. Unfortunately that's very vague indeed. I see some google hits for your ntoskrnl.exe BSOD suggesting graphics cards being the cause, keyboards, webcams, and lots more. Ask yourself if you can tie the error with specific tasks or dates that relied on particular hardware. Do you get a BSOD with the monitor connected to the mobo rather than the graphics card? Did this problem first arise the day you installed your new webcam? So on like that.

3. Hard drive or RAM fault
These two both looks very similar on paper, and happen to occur often at random when some program happens to try to read/write to the bad location on the HDD/RAM. As you have 4gigs of RAM I'm guessing your page file isn't used much (where Windows resorts to using the HDD as emergency RAM because you're running low). As you suggested this happens mostly during game play rather than, say, moving files around or using particular programs, then it's more likely to be the RAM. However every now and then you'll be unlucky and a faulty location of the HDD happens to fall in an area the operating system reserves for itself, in which case you'll get effects very, very similar to RAM errors.

The scans you plan to do will very quickly tell you if situation 3 is the cause. Be sure to let the memcheck scan run for hours (1 full scan is great, 2 is overwhelming evidence). Also make sure the HDD scan is the long scan not a short one, and definitely rerun the scan if errors are found and fixed.

I wouldn't reinstall Windows just yet because it can be a pain, especially if you want to do it properly and wipe the hard drive. Updating Windows is quick and painless though, and therefore well-worth trying.

Identifying hardware/driver problems is the most annoying of the three, so I'd do it last unless some piece of hardware immediately suggests itself as a likely cause. The approach is very simple though: stop using or temporarily replace a piece of hardware for a while and see if the problem goes away.