6 weeks of computer issues with random reboots....help!

[Kellnos]

Alright, I am not sure if this is the right forum area for this, but here goes.

P4 hyperthreaded 2.8 gig processor
1 gig ram
400-450ish watt power supply
abit vt or v7 motherboard (can check if needed)
creative audigy gamer sound card
geforce fx 5700 ultra video card
....all the latest drivers I can find

About 6 weeks ago I was putting new ram in, but apparently the ram was bad and fried my old mobo (I put the ram in correctly, with all power off and plugs out, and while I was grounded, but still my computer got screwed).

After having a new mobo put in, and a computer shop working on my computer (as it wouldnt boot when the new mobo was in), the shop reinstalled xp and sent my comp home. The first night it rebooted, but I thought perhaps it was just a random one time thing (and I didn't exactly have the money to pay the shop again for more labor).

I then had a multiple week period where my computer would randomly freeze, reboot, go BSOD, etc. Both sticks of ram in my computer were bought after the initial incident, and both have been memtested for a long time with no errors.

Eventually I found a flash utility for clearing my cmos and flashing my bios, so I used that utility. My computer was fine for about two days, but then it started doing weird things again (though less than before the flash utility was used). Since then I have checked forums, sent in windows xp errors, etc., but I have been unable to solve the problem.

The good news is that my computer has ceased for the most part to reboot when I am just browsing the web, chatting, etc, but I can't play games without it eventually rebooting on me. Can anyone make any sense of these?:

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

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


BUGCHECK_STR: 0x7f_d

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804e1be8 to 806ff427

STACK_TEXT:
f78e2d3c 804e1be8 863c3e18 863c3da8 804e22d6 hal!KfLowerIrql+0x17
f78e2d48 804e22d6 80568010 805694fc 863c3da8 nt!KiSwapThread+0x8d
f78e2d74 804e238e 00000001 00000001 00000000 nt!KeRemoveQueue+0x22a
f78e2dac 80574128 80000000 00000000 00000000 nt!ExpWorkerThread+0xcc
f78e2ddc 804efc81 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
nt!KiSwapThread+8d
804e1be8 8bc7 mov eax,edi

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiSwapThread+8d

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250f77

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x7f_d_nt!KiSwapThread+8d

BUCKET_ID: 0x7f_d_nt!KiSwapThread+8d

Followup: MachineOwner


and...



UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

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


BUGCHECK_STR: 0x7f_d

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804dc605 to 806ffae4

STACK_TEXT:
ba14fc30 804dc605 00000020 e39df170 00000000 hal!KeReleaseQueuedSpinLock+0x3c
ba14fc50 bf8018df bf89b5da bf000444 000015b8 nt!ExReleaseResourceLite+0x8d
ba14fc54 bf89b5da bf000444 000015b8 ba14fd4

0 win32k!GreReleaseSemaphore+0xa
ba14fc58 bf000444 000015b8 ba14fd40 bf000749 win32k!DxEngUnlockShareSem+0xb
ba14fc64 bf000749 e39df170 ba14fc80 ba14fd64 dxg!D3dUnlockContext+0x1c
ba14fd40 804dd99f 2e40001c 0a400016 0008fc00 dxg!DxD3dDrawPrimitives2+0x29f
ba14fd40 7c90eb94 2e40001c 0a400016 0008fc00 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0006fcb0 00000000 00000000 00000000 00000000 0x7c90eb94


FOLLOWUP_IP:
win32k!GreReleaseSemaphore+a
bf8018df ff25bca798bf jmp dword ptr [win32k!_imp__KeLeaveCriticalRegion (bf98a7bc)]

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: win32k!GreReleaseSemaphore+a

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 422511a2

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x7f_d_win32k!GreReleaseSemaphore+a

BUCKET_ID: 0x7f_d_win32k!GreReleaseSemaphore+a

Followup: MachineOwner




I have other minidumps as well, but these are the two most recent. Any help or thoughts would be greatly appreciated!

 

[klash89]

klash89

hey have u tried updating your drivers

 

[Tedster]

Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP

The UNEXPECTED_KERNEL_MODE_TRAP bug check has a value of 0x0000007F. This indicates that a trap was generated by the Intel CPU and the kernel failed to catch this trap.

This could be either a bound trap (a trap the kernel is not permitted to catch) or a double fault (a fault that occurred while processing an earlier fault, which always results in a system crash).

Parameters

The first parameter displayed on the blue screen specifies the trap number.

Here are some of the most common trap codes:

* 0x00000000, or Divide by Zero Error, is caused when a DIV instruction is executed and the divisor is zero. Memory corruption, other hardware problems, or software failures can cause this error.
* 0x00000004, or Overflow, occurs when the processor executes a call to an interrupt handler when the overflow (OF) flag is set.
* 0x00000005, or Bounds Check Fault, is generated when the processor, while executing a BOUND instruction, finds the operand exceeds the specified limits. A BOUND instruction is used to ensure that a signed array index is within a certain range.
* 0x00000006, or Invalid Opcode, is generated when the processor attempts to execute an invalid instruction. This is generally caused when the instruction pointer has become corrupted and is pointing to the wrong location. The most common cause of this is hardware memory corruption.
* 0x00000008, or Double Fault, is when an exception occurs while trying to call the handler for a prior exception. Normally, the two exceptions can be handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault:
1. A kernel stack overflow. This occurs when a guard page is hit, and then the kernel tries to push a trap frame. Since there is no stack left, a stack overflow results, causing the double fault. If you suspect this has occurred, use the !thread debugger extension to determine the stack limits, and then use the kb (Display Stack Backtrace) debugger command with a large parameter (for example, kb 100) to display the full stack.
2. A hardware problem.

The less-common trap codes include:

* 0x00000001 — A system-debugger call
* 0x00000003 — A debugger breakpoint
* 0x00000007 — A hardware coprocessor instruction with no coprocessor present
* 0x0000000A — A corrupted Task State Segment
* 0x0000000B — An access to a memory segment that was not present
* 0x0000000C — An access to memory beyond the limits of a stack
* 0x0000000D — An exception not covered by some other exception; a protection fault that pertains to access violations for applications

For other trap numbers, consult an Intel architecture manual.
Cause

Bug check 0x7F usually occurs after the installation of faulty or mismatched hardware (especially memory) or in the event that installed hardware fails.

A double fault can occur when the kernel stack overflows. This can happen if multiple drivers are attached to the same stack. For example, two file system filter drivers can be attached to the same stack and then the file system can recurse back in, overflowing the stack.
Resolving the Problem

Debugging: Always begin with the !analyze debugger extension.

If this is not sufficient, use the kv (Display Stack Backtrace) debugger command.

* If kv shows a taskGate, then use the .tss (Display Task State Segment) command on the part before the colon.
* If kv shows a trap frame, then use the .trap (Display Trap Frame) command to format the frame.
* Otherwise, use the .trap (Display Trap Frame) command on the appropriate frame. (On x86 platforms, this frame is associated with the procedure NT!KiTrap.)

After this, use kv again to display the new stack.

Troubleshooting: If hardware was recently added to the system, remove it to see if the error recurs. If existing hardware has failed, remove or replace the faulty component. Run hardware diagnostics supplied by the system manufacturer, to determine which hardware component has failed. The memory scanner is especially important; faulty or mismatched memory can cause this bug check. For details on these procedures, see the owner's manual for your computer. Check that all adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure adapter card contacts are clean.

If the error appears on a newly installed system, check the availability of updates for the BIOS, the SCSI controller or network cards. Updates of this kind are typically available on the Web site or BBS of the hardware manufacturer.

Confirm that all hard disks, hard disk controllers, and SCSI adapters are listed in the Microsoft Windows Catalog.

If the error occurred after the installation of a new or updated device driver, the driver should be removed or replaced. If, under this circumstance, the error occurs during the startup sequence and the system partition is formatted with NTFS, you might be able to use Safe Mode to rename or delete the faulty driver. If the driver is used as part of the system startup process in Safe Mode, you need to start the computer using the Recovery Console in order to access the file. Also try restarting your computer, and press F8 at the character-based menu that displays the operating system choices. At the resulting Windows Advanced Options menu, choose the Last Known Good Configuration option. This option is most effective when only one driver or service is added at a time.

Overclocking (setting the CPU to run at speeds above the rated specification) can cause this error. If this has been done to the computer experiencing the error, return the CPU to the default clock speed setting.

Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. Disabling memory caching of the BIOS might also resolve it.

If you encountered this error while upgrading to a new version of Windows, it might be caused by a device driver, a system service, a virus scanner, or a backup tool that is incompatible with the new version. If possible, remove all third-party device drivers and system services and disable any virus scanners prior to upgrading. Contact the software manufacturer to obtain updates of these tools. Also make sure that you have installed the latest Windows Service Pack.

Finally, if all the above steps fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can also cause this error.