Gigabyte GA-X48-DQ6, blue screen problem

Did you do the requisite "Load Optimized Defaults" at startup?

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:
http://www.tomshardware.com/forum/ [...] abyte-tale

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
http://www.microsoft.com/whdc/devt [...] fault.mspx
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:
.symfix
.reload
kb

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:

STACK_TEXT:
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:
http://www.adopenstatic.com/cs/blo [...] art-1.aspx

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...