[magusprimex]

Hello. I was directed to go here with my problem by wrench on the building forum after a little bit of trying to work on this, from over in this thread. Basically we ended up seeing a drop on the 12v line and tried a new PSU to see if that would handle it,. but the BSoD's continued. A little under a year ago now I put together the first PC I've built, and surprisingly it worked very smoothly. However, a few months ago, say mid-January maybe, I started encountering random BSoD's. They started off not too bad at first, maybe one or two every day or two, but they've become significantly worse. I tend to see multiples of BSoD's every day, sometimes while booting Windows, and even the rare, but occasional failure to POST.

The BSoD's seem to be random. I've probably written down ten or fifteen different error messages at this point(PAGE_FAULT_ERROR, IRQL_NOT_LESS_OR_EQUAL(probably the most common) System tried to reference a page it did not have access too, USB_BUGCODE etc.),. They occur randomly as well. Sometimes I can run a high stress game like a tweaked Oblivion for hours, other times the system can be idling for only a few minutes and I'll get a BSoD. Because of this I do not believe it is a temperature issue (that and my system is very well ventilated). I can't seem to do anything to willfully reproduce them.

I've since been working for the past few months attempting to diagnose my problem. I've reformatted the hard drive twice by now, so I think I can safely say it's not a software issue. The RAM I use has passed several Memtests now and not shown a single error. I've also played roulette and removed each of my four sticks so that the system has run with only one of each of them at least once by now, without problem. In regards to the ram, I checked the QVL list on Asus' website for the RAM: here. My ram, an EOL OCZ stick, wasn't explicitly listed, but a very similar stick was( this one), and like I said, the system ran stable for months and this RAM has passed several Memtests, so at this point I've put the ram at very low likelihood of being the culprit. I had noticed that the RAM timings were incorrect and underclocked, so I adjusted them to what the manufacturer recommended n the BIOS. Remarkably this did actually seem to increase my stability for awhile. Not solved it, mind you, but increasing the RAM voltage and timings seemed to make an improvement in how many BSoD's I'd see in a day. For awhile anyways.

I have also updated the BIOS since the BSoD's began (not before, mind you), and some of the notes mentioned increased compatability with various RAM (again, ruling the RAM out a little more). The BIOS update went smoothly.

Everything physically has been reseated, I've made sure to dust with an air can. Since the recent reformat, very little has gone back onto the computer yet, and virtually nothing did was on it before the first BSoD's since. I'd greatly appreciate any further help or assistance you can provide and trying to solve what this problem is!


My Specs:

CPU: IntelQuad Core 2 2.4GHz
RAM: OCZ Flex 1024 x4
Motherboard: Asus P5N32-E SLI Plus
OS: Microsoft Windows Vista Home Premium (currently without the 1st service pack, although before the recent reformat it has had it) OEM copy
Hard Drive: Samsung HD501LJ
PSU: Corsair 750TX
GPU: nVIDIA GeForce 8800 Ultra

 

[jcgriff2]

JHi -

Thank you for the files - and being prepared.

You mentioned SP1 not in - are you having SP1 installation problems? I'd like to get SP1 in b/c you have Vista 2006 drivers running with device drivers from 2008/ 2009 written with SP1 in mind/ This in itself can be an unnecessary disruption and can cause BSODs that lead us away from the real cause.

jcgriff2

.

 

[magusprimex]

Thanks for responding! I'm sorry, I should have read that more carefully when I posted it. I am currently on SP 1, and I made those attached files after SP 1 was installed. When I started this on the building forum I hadn't updated yet since the reformat. SP 1 has now actually been on for little under a week.

 

[magusprimex]

I thought I'd add one last bit of information I just got on this. I finally got a blank CD recently to make myself an Ultimate Boot CD, and just started running HUTIL to run a self diagnostic on the hard drive about an hour ago. Windows' hard drive check passed it, and hutil's first set of scans passed as well, but now it's about 30% of the way done the full read surface scan and found two errors so far (one Media error detected and an Ecc error). I'm not sure what those mean or if that'd be related to other elements in the system, if they're fatal flaws in the HDD or what, and it still has 70% to go (probably another hour or two at this rate), so who knows how many more it'll find.

 

[jcgriff2]

There are no dump files in the zip folder.

Please see if there is a file c:\windows\memory.dmp

If so, what is the size?

jcgriff2

.

 

[magusprimex]

I'm sorry, don't know how I missed that. The Memory.DMP file is 364 MB, which only compresses down to a 86MB zip.

 

[magusprimex]

I'm not entirely sure if these would help you as well, but the minidump folder was 86MB, which I was able to compress down to 720 some KB.

 

[usasma]

The last 2 minidumps point to a system/system service issue, and were in Yahoo Messenger and in Steam. The next to the last one has a similar issue to one that I've been working on at work (the "::FNODOBFM::" string in the stack text). The system at work has had a virus cleaning done on it, but it's still giving BSOD's.

What's the date on the memory.dmp file? If it's recent, try following these instructions to generate an analysis that you can post here:

Please note that though this process may appear long and daunting, it has been explained in such a way so that the steps will be easy to follow.

A memory dump is what happens when Windows crashes. The memory is dumped into the pagefile and saved for the next reboot. Once Windows reboots, it reclaims the memory dump data from the pagefile and saves it to a file, which usually ends with the .dmp extension. Analyzing these dump files can help to figure out what's causing your system to crash. While they don't offer a "sure" fix, they provide clues to the cause of a crash so that we can work on fixing them. In my experience most system crashes are caused by faulty/corrupted drivers, malware, or hardware failures (in that order). Following the steps below will help us determine what may be causing your computer to Blue Screen, or crash.

A. The first thing to do when your system crashes is to reboot. Doing so will create the memory dump file so it's able to be accessed. Windows may also ask permission to send the file for online analysis. I suggest that you always allow it to be sent. Most times you won't get anything back, but occasionally it will point out the problem and save you a lot of work trying to determine it on your own. Also, quite often the first crash is the only crash as Windows will fix the problem when it reboots, so there's no need to worry unless Windows crashes repeatedly. If you can't get into Windows, either in normal or Safe Mode, then just post straight to the appopriate forum and we'll help you from there. The various forums that we help diagnose crashes are:

    * Windows Vista Forum
    * Windows XP Forum
    * Windows 2000 Forum

B. The next thing to do is to ensure that you are free of malware. If malware is present on your computer, it may have corrupted your installation, and be the cause of your crashes. I suggest you perform one of the free online scans that can be found at the following link:

    Free Online Malware Scanners

C. Once you have completed an online scan, or two, please search your hard drive for files ending with the .dmp extension. There are several types of memory dumps that Windows may create. These are distinguished below:

   1. A complete memory dump or a kernel memory dump that are usually saved in the C:\Windows directory and named MEMORY.DMP.
   2. A small memory dump, aka a minidump, which are usually saved in the C:\Windows\Minidump directory. These are named Miniwwxxyy-zz.dmp, where the ww is the number of the month, the xx is the number of the day, the yy is the number of the year, and the zz is the number of the crash dump that day. For example, a minidump with the name of Mini070108-03.dmp is the 3rd minidump generated on July 1, 2008.

On some systems the directories where the dump files are stored are protected by being Hidden and System files.

To show Hidden and System files in Windows Explorer, click on the Start button, then select All Programs, then select Accessories, and finally select Windows Explorer.

   1. Once opened, select the Tools menu and then select the File Options menu item. In Vista you may have to press and hold the Alt key to view this menu.
   2. Then go to the View tab and check the box labeled Show Hidden Files and Folders and uncheck Hide Protected Operating System Files
   3. You will now be at a dialog that asks you if you're sure you want to do this. Click on the Yes button to allow the change to take place.
   4. Then click the OK buttons at the prompts to exit the dialog. You will now be able to view hidden and system directories.

Warning - These files are hidden for a reason and messing with some of them may cause problems with your system.

D. Once you've located the memory dump file(s), then you'll have to get a debugger to analyze them. The one that I'm familiar with is the free Microsoft Debugging Tools for Windows. Download the version, 32 or 64 bit, that's appropriate for the operating system that you'll be running the debugger on. The debugger can be found at the following link: Debugging Tools for Windows

Once it's downloaded, double click on it to install it. Once it's installed, open the debugger by doing the following:

   1. Click on the Start Menu.
   2. Click on the All Programs menu.
   3. Select the Debugging Tools for Windows program folder.
   4. Click on the WinDbg icon to start the program.

Once you've opened the program, click on the File menu item, then on Symbol File Path.

E. In the window that opens, insert the exact text on the next line in the Symbol File Path box. This is a critical step, and if done incorrectly you'll end up with symbol errors:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

The easiest thing to do is copy the above bolded text and then paste it into the box. Once that is done, click on OK to exit the dialog. Next, click on File menu and then select the Save Workspace menu option. This will save the symbol path for future use.

NOTE: You MUST be connected to the internet in order to use the Symbol server listed above.

F. Next, click on the File menu and select the Open Crash Dump option. When the dialog box opens, click on the Browse button and browse to the location of the memory dump file and then double-click on it to load it into the Debugger. You may be prompted to save the workspace again, but just click on the No button. A window will now open and the dump file text will fill the debugging screen.

Here's an example of of an analysis report from a Minidump file. If this was a complete or kernel dump, it would be much larger.

    Microsoft ® Windows Debugger Version 6.8.0004.0 AMD64
    Copyright © Microsoft Corporation. All rights reserved.


    Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
    Product: WinNt
    Built by: 2600.xpsp_sp2_gdr.070227-2254
    Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
    Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
    System Uptime: 0 days 0:04:00.921
    Loading Kernel Symbols
    ................................................................................
    ..................................................................
    Loading User Symbols
    Loading unloaded module list
    .........
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}

    Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

G. The next step is to click on the !analyze -v link that's highlighted in blue in the report above.  This will generate more information, which would look something like this:

            Additional Commands (not reflected in the samples on this page): 
            -  I'm starting to incorporate typing !analyze -v;r;kv;lmtn;lmtsmn;.bugcheck into the text box at the bottom of the debugger - thanks to jcgriff2.
            -  List loaded drivers = lm kv
            -  Memory usage = !vm
            -  Current thread = !thread
            -  List all processes = !process 0 0
            -  If driver deadlock detected in verifier = !deadlock


    Microsoft ® Windows Debugger Version 6.8.0004.0 AMD64
    Copyright © Microsoft Corporation. All rights reserved.


    Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
    Product: WinNt
    Built by: 2600.xpsp_sp2_gdr.070227-2254
    Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
    Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
    System Uptime: 0 days 0:04:00.921
    Loading Kernel Symbols
    ................................................................................
    ..................................................................
    Loading User Symbols
    Loading unloaded module list
    .........
    *******************************************************************************
    * *
    * Bugcheck Analysis *
    * *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}

    Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

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


    KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
    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: c0000005, The exception code that was not handled
    Arg2: 84c64731, The address that the exception occurred at
    Arg3: f4fecc3c, Trap Frame
    Arg4: 00000000

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


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

    FAULTING_IP:
    +ffffffff84c64731
    84c64731 ?? ???

    TRAP_FRAME: f4fecc3c -- (.trap 0xfffffffff4fecc3c)
    Unable to read trap frame at f4fecc3c

    CUSTOMER_CRASH_COUNT: 3

    DEFAULT_BUCKET_ID: DRIVER_FAULT

    BUGCHECK_STR: 0x8E

    LAST_CONTROL_TRANSFER: from 00000000 to 84c64731

    STACK_TEXT:
    f4feccac 00000000 00000000 01790000 00000000 0x84c64731


    STACK_COMMAND: .trap 0xfffffffff4fecc3c ; kb

    SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

    FOLLOWUP_NAME: MachineOwner

    MODULE_NAME: Unknown_Module

    IMAGE_NAME: Unknown_Image

    DEBUG_FLR_IMAGE_TIMESTAMP: 0

    FAILURE_BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE

    BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE

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

H. Once this is done, we want to copy the text of the dump file analysis report. To do this, select the Edit menu item in the Debugging Tools window and then select Copy Window Text to Clipboard. Now, return to Bleeping Computer and paste the information into your next post.

I. If you haven't started a topic for your issue yet, you can start one at the appropriate link below. Please be sure and let us know the make and model of your system along with the symptoms that you're experiencing.