Gigabyte GA-X48-DQ6, blue screen problem

Hi all, first i want to say that you guys do a great job on this forum, i've read some threads and saw the help you give anyone here, so i decided to find the help i need here, and i hope to help in what i can to others too.

ok after that said, here is my problem.
I got a GA-X48-DQ6 with a RAM corsair 2x 2GB XMS2-6400, and a CPU Intel @2.66GHz.
Since i built it 'm getting a blue screen during any work in the OS. after it gets the blue screen it restarts, and it does't even pass the POST and doesnt show anything on screen (No video card signal) and it goes off, then on again and the same thing happens X times.
What i tried is:
- Switched the PS off, then back on, it will go pass the POST test go in the OS and after like 5 min off again, and same process started.
-I disconnected every single thing and reconected it, on passs the POST, off again, same process.
-Another video card, same as the other 2.
-Cahnged memory from positions, tried 1, then the other, same exact thing happened.

Well, i've been doing a little research about it, and think it might be the memory, but i really don't know what exactly is.
If need any other info just tell me, i'll do anything to fix this 'cuz is my PC to play and work :D.
Thanks in advance

...Ah ny the way... the error code of the blue screen is "0x0000000A (0x00870000, 0x00000002, 0x00000001, 0x806E4A2A)"
5 answers Last reply
More about gigabyte blue screen problem
  1. Did you do the requisite "Load Optimized Defaults" at startup?
  2. yes i've done that. Since yesterday i changed the momeories from channel again, and the pc gets stable, but no sure if blue screen will appear again, cuz' i havent solved it...
  3. If you are getting random STOP numbers each time your machine blue screens (e.g. the bugcheck is different each time), then it's possible that your machine has a hardware issue. Do some basic hardware troubleshooting first (e.g. run a memory tester application, remove unnecessary peripherals etc) First thin I'd eliminate is USB devices - they are known problems with GB MOBOs - look at this:

    Error: STOP 0x0000000A, (Parameter 1, Parameter 2, Parameter 3, Parameter 4) IRQL_NOT_LESS_OR_EQUAL

    Parameter 1 – The address of memory that was incorrectly accessed (0x00870000 - not very instructive, at this point)
    Parameter 2 – The interrupt request level (IRQL) that was required (0x00000002, which is DISPATCH_LEVEL - thread scheduler and deferred procedure calls [DPCs])
    Parameter 3 – The type of operation, read-0, write-1 (0x00000001 - write op)
    Parameter 4 – The address of the instruction itself (0x806E4A2A)

    Level 2 is a "software" IRQL - Windows uses this IRQL to perform various tasks. Levels 3-26 (for x86) and 3-11 (for x64) are device (hardware) IRQLs (or DIRQLs). When a hardware device raises an interrupt, the IRQL is raised to within this band. The actual IRQL that a particular interrupt raises the IRQL level to is determined by the Windows Plug-n-Play (PnP) subsystem. Above these DIRQLs are certain privileged IRQLs, such as that used by the system clock.

    In the Windows system, higher IRQLs preempt lower level IRQLs. This is why the system clock has such a high IRQL - Windows relies on the clock to know when threads have exhausted their quatum on the CPU and should be preempted by other threads. The actual system thread dispatcher runs at IRQL 2 (Dispatch Level). This allows the thread dispatcher to preempt normal running code (at IRQL 0) and schedule a different ready thread to run on the CPU.

    When an IRQL has been raised, then all lower level IRQLs are temporarily "masked" or ignored until the IRQL is lowered. And because of this, we potentially end up with the IRQL_NOT_LESS_OR_EQUAL bugcheck. The most common cause of this Bugcheck is when a hardware device has raised an interrupt, and the IRQL has been raised. Windows looks in the Interrupt Dispatch Table (IDT) to see what code should be run in response to the interrupt. Typically some device driver software is now run. Suppose the device driver attempts to access some memory, but that memory has been paged to disk. Normally, when memory has been paged to disk we dispatch another thread to perform a file i/o operation to bring the necessary data back into physical memory. However because the system thread dispatcher runs at IRQL 2, and all lower level IRQLs are currently being masked, we end up in a deadlock situation. The device driver won't signal that it's ready to lower the IRQL until it gets the data it needs, but Windows can't get that data from disk until the IRQL is lowered and the System Thread Dispatcher can dispatch a file i/o thread. Windows detects this situation as an unresolvable deadlock and bughecks the system with an "STOP 0x0000000A IRQL_NOT_LESS_OR_EQUAL" error. The "not less or equal" refers to the fact that the required IRQL is not less or equal to the current IRQL.

    If you'd like to confirm the actual STOP error you are getting visually, then you need to change a setting in Windows. By default the system automatically restarts upon a BSOD and you may miss the information that's printed on the screen. To view the actual BSOD use the System Control Panel -> Advanced Tab -> Startup and Recovery Settings button -> uncheck Automatically Restart on System Failure. The System control panel is available in the Control Panel folder, or by right-clicking on My Computer and choosing Properties.

    To determine what is causing the problem we want to use a debugging tool such as WinDBG. WinDBG is available for free as part of the debugging tools for windows
    There are separate downloads for x32 and x64 systems.

    After downloading and installing the Debugging Tools start WinDBG. Press Ctrl+D to open a crash dump, and navigate to %systemroot%\minidump (%systemroot% is where your Windows/WINNT folder is located). Each time Windows has crashed, there should be a minidump file there (by default). Open the minidump file that corresponds to your crash.

    Ensure that your system has access to the internet (in particular the Microsoft Public Symbol Server) and type in the following commands at the kd> prompt:

    After hitting .reload, it may take some time for WinDBG to download the corresponding symbols that match the dump file (depending on your internet connection speed). These symbols allow you to see what functions are being called within files supplied by Microsoft (for third party files, you need to get symbols from those vendors. You can supply your own symbols for you own code). Because the offsets for functions potentially change with each update to Windows (service packs, hotfixes etc) being able to contact the public symbol server allows you to get the correct symbols that match the exact build in the dump file.

    The kb command allows you to get a stack backtrace of the faulting thread. In most cases you can get a faulting driver from the stack. The stack should be read from the bottom up. Here is an example:

    WARNING: Stack unwind information not available. Following frames may be wrong.
    8055052c f94c7ef9 81ae08d8 6600a8c0 6500a8c0 A3AB+0x15d90 <== Our culprit
    8055058c f94c7b19 f9722404 819ab000 818a0ef0 tcpip!DeliverToUser+0x18e
    80550608 f94c780a f97307a0 818a0ef0 00000054 tcpip!DeliverToUserEx+0x95f
    805506d0 f988bf7f 81b184d8 fff0bdc0 ffffffff tcpip!IPRcvPacket+0x6a0
    805506f8 f987354b 81b184d8 00000064 819ae0d8 NDIS!NdisMSetTimer+0x8b
    8055070c f96fdd98 81b184d8 00000064 819ab000 NDIS!NdisSetTimer+0x44
    80550764 804dcaad 81b18500 81b184d8 00000283 A3AB+0x2fd98
    80550880 805508ac 81a915f4 804e4fd5 81aa39c0 nt!KiTimerListExpire+0x122
    80550890 f988f712 00000000 80559580 80559320 nt!KiDoubleFaultStack+0x2d2c
    805508ac 804dc179 81a91608 81a915f4 00000000 NDIS!ndisMDpc+0xff
    805508d0 804dc0ed 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
    805508d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

    The faulting driver isnt always at the top of the stack, but it's generally easy to spot. In this case, a quick search for a3ab.sys lead us to the driver that needs updating (it was for a network card).

    Additional information about the modules loaded can be obtained by using the lmv command at the kd> prompt. In this dump file:

    f96b7000 f96cd680 ndiswan (deferred)
    Mapped memory image file: ndiswan.sys\41107EC616680\ndiswan.sys
    Image path: ndiswan.sys
    Image name: ndiswan.sys
    Timestamp: Wed Aug 04 16:14:30 2004 (41107EC6)
    CheckSum: 00016813
    ImageSize: 00016680
    File version: 5.1.2600.2180
    Product version: 5.1.2600.2180
    File flags: 0 (Mask 3F)
    File OS: 40004 NT Win32
    File type: 3.6 Driver
    File date: 00000000.00000000
    Translations: 0409.04b0
    CompanyName: Microsoft Corporation
    ProductName: Microsoft® Windows® Operating System
    InternalName: NDISWAN.SYS
    OriginalFilename: NDISWAN.SYS
    ProductVersion: 5.1.2600.2180
    FileVersion: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
    FileDescription: MS PPP Framing Driver (Strong Encryption)
    LegalCopyright: © Microsoft Corporation. All rights reserved.
    f96ce000 f973bf60 A3AB T (no symbols)
    Loaded symbol image file: A3AB.sys
    Image path: A3AB.sys
    Image name: A3AB.sys
    Timestamp: Wed Mar 23 14:17:32 2005 (4240DFCC)
    CheckSum: 00072B2D
    ImageSize: 0006DF60
    Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
    f973c000 f975ee80 USBPORT (deferred)
    Mapped memory image file: USBPORT.SYS\41107D6222e80\USBPORT.SYS
    Image path: USBPORT.SYS
    Image name: USBPORT.SYS
    Timestamp: Wed Aug 04 16:08:34 2004 (41107D62)
    CheckSum: 0002F594
    ImageSize: 00022E80
    File version: 5.1.2600.2180
    Product version: 5.1.2600.2180
    File flags: 0 (Mask 3F)
    File OS: 40004 NT Win32
    File type: 2.0 Dll
    File date: 00000000.00000000
    Translations: 0409.04b0
    CompanyName: Microsoft Corporation
    ProductName: Microsoft® Windows® Operating System
    InternalName: usbport.sys
    OriginalFilename: usbport.sys
    ProductVersion: 5.1.2600.2180
    FileVersion: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
    FileDescription: USB 1.1 & 2.0 Port Driver
    LegalCopyright: © Microsoft Corporation. All rights reserved.

    Happy debugging!

    ...mostly from Ken Schaefer - "Causes, and tips for debugging, a STOP 0x0000000A (IRQL_NOT_LESS_OR_EQUAL) bugcheck/blue screen", in its entiretly at:
  4. Most likely you need to set your ram volts and timings manually because they arent running spec.
  5. There is a peculiar discrepancy in the RAM's specs; it might help if you post a full part number (or a NewEgg pointer), but, while the point of sale info says 5-5-5-18 (which, by the way, are fairly awful specs for DDR2-800, most is 4-4-4-12) at 1.8V (which is JEDEC spec voltage), their web-site tech info says 1.9V, and doesn't say what the SPDs read, which means the BIOS 'Load Optimized' may be setting the sticks a tenth low - 'Optimized' simply 'reads' the SPDs on the RAM, and sets the 'auto' parameters from there - if it's off, the BIOS is off...
Ask a new question

Read More

Gigabyte Blue Screen Motherboards