Multiple BOSD's

[carnageX]

Computer was working fine last night...Woke up this morning to find the breaker got tripped somehow for part of my house (part that my PC is on, unluckily). Was hooked up to a backup UPS, but it only lasted 10 minutes (this happened while I was asleep/didn't hear the UPS beeping). So, I go to turn my computer back on after i close the breaker. POSTs fine, and then after it gets to the logon screen, it gives me a BSOD. I think it was a 0x8E (or 0xBE...one of the 2). Try a few more times to try and boot back up, and each time gives me a different BSOD; 0x8E, 0xBE, 0xD1, were the ones I remembered off of the top of my head. I remember the latest one gave me a ntfs.sys call-up as well.

I ran Memtest86+ last night, and RAM checked out fine. Ran Spinrite (lvl4 diagnostics), and a majority of it had checked out good (it didn't finish, because I wanted to try and see if I could get my comp to boot; but I can continue from where I left off to test the rest). Tried booting and got the 0xD1 BSOD w/ the ntfs.sys being the driver it issued it with. So, I've tested RAM and HDD so far and both checked out fine. I decided to try taking off my OC, and see if that helped, and now I'm posting from the desktop that couldn't boot...now I just need help figuring out what hardware is failing on me. Here's my minidumps if anybody wants to help me out:
RapidShare Webhosting + Webspace

Thanks a lot, I appreciate it.

 

[KSoD]

Carnage,

The first minidump is corrupt. But i got info from the rest of them. Here is the 2nd one:

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: 80000058, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000001, 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: 804f861d, address which referenced memory

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


WRITE_ADDRESS:  80000058 

CURRENT_IRQL:  1c

FAULTING_IP: 
nt!KeBugCheck2+407
804f861d ??              ???

CUSTOMER_CRASH_COUNT:  2

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

LAST_CONTROL_TRANSFER:  from 00000000 to 80543930

STACK_TEXT:  
a978433c 00000000 80000058 0000001c 00000001 nt!MiFreePoolPages+0x1ce


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  0xA_W_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  0xA_W_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner

That is a Driver.

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: c0000046, The exception code that was not handled
Arg2: 804fc79d, The address that the exception occurred at
Arg3: b7e96900, Trap Frame
Arg4: 00000000

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000046 - An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.

FAULTING_IP: 
nt!KeContextToKframes+313
804fc79d ??              ???

TRAP_FRAME:  b7e96900 -- (.trap 0xffffffffb7e96900)
Unable to read trap frame at b7e96900

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

LAST_CONTROL_TRANSFER:  from 804fc824 to 804fc79d

STACK_TEXT:  
b7e96cc0 804fc824 00000001 00000001 00000000 nt!KeContextToKframes+0x313
b7e96cd8 8060a716 805630e0 00000000 805d1989 nt!KeContextToKframes+0x39a
b7e96cfc bf82607a 000004cc b7e96d48 e2f9ca28 nt!NtSetSystemTime+0x172
b7e96d14 bf90d597 000004cc b7e96d48 b7e96d64 win32k!zzzBltValidBits+0x4a5
b7e96d38 bf90d701 000004cc 000001f4 00000000 win32k!xxxPollAndWaitForSingleObject+0xe6
b7e96d50 8054086c 000004cc 000001f4 00000000 win32k!xxxWaitForInputIdle+0x87
b7e96d64 7c90eb94 badb0d00 0083fdf4 66db2bf6 nt!Dr_kit10_a+0x78
WARNING: Frame IP not in any known module. Following frames may be wrong.
b7e96d68 badb0d00 0083fdf4 66db2bf6 9759ef4e 0x7c90eb94
b7e96d6c 0083fdf4 66db2bf6 9759ef4e 00000000 0xbadb0d00
b7e96d70 66db2bf6 9759ef4e 00000000 00000000 0x83fdf4
b7e96d74 9759ef4e 00000000 00000000 00000000 0x66db2bf6
b7e96d78 00000000 00000000 00000000 00000000 0x9759ef4e


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!zzzBltValidBits+4a5
bf82607a ??              ???

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  win32k!zzzBltValidBits+4a5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  47e0e106

FAILURE_BUCKET_ID:  0x8E_win32k!zzzBltValidBits+4a5

BUCKET_ID:  0x8E_win32k!zzzBltValidBits+4a5

Followup: MachineOwner

That is win32.sys which is not a good sign.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: d06a4498, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ba48eb87, address which referenced memory

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


WRITE_ADDRESS:  d06a4498 

CURRENT_IRQL:  ff

FAULTING_IP: 
Ntfs!NtfsReadFileRecord+6b
ba48eb87 ??              ???

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

BUGCHECK_STR:  0xD1

LAST_CONTROL_TRANSFER:  from 00000000 to 80543930

STACK_TEXT:  
b4916e04 00000000 d06a4498 000000ff 00000001 nt!MiFreePoolPages+0x1ce


STACK_COMMAND:  .bugcheck ; kb

FOLLOWUP_IP: 
Ntfs!NtfsReadFileRecord+6b
ba48eb87 ??              ???

SYMBOL_NAME:  Ntfs!NtfsReadFileRecord+6b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME:  Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  45cc56a7

FAILURE_BUCKET_ID:  0xD1_W_Ntfs!NtfsReadFileRecord+6b

BUCKET_ID:  0xD1_W_Ntfs!NtfsReadFileRecord+6b

Followup: MachineOwner

This is the Drive IRQL which caused the NTFS.sys error.

Overall not a good sign. It seems that the shutdown corrupted part of your system files. Is this a XP desktop or Vista? If XP do a repair isntall. If Vista you might be forced to reinstall.

Cheers,
Mak

 

[carnageX]

Luckily my desktop is XP.

I was thinking of a repair install, but I figured I'd ask here to see what anybody else thought... When I saw the win32.sys one I figured I better ask if I should do a repair install, or a total reformat.

 

[carnageX]

Did a repair install yesterday, and have been able to reboot several times without problems. Put my overclock back on, and all is well.

Thanks for the help Mak, appreciate it.

 

[KSoD]

Not a problem Carnage. Glad it is working for you now.

Cheers,
Mak

 

[KurrentEweser]

Registry corruption can happen when the computer loses power unexpectedly. In your case the UPS battery died. I use a program that backs up the registry daily and before and after program installations. So I always have recent copy to go back to when things go wrong. I also image my C: drive once a week. I never trusted a repair install or system restore point to leave my system in a more stable state then before a problem occurs. I'll either restore the most recent copy of the registry or the latest image.

 

[carnageX]

I normally make images of my HDD as well, but I had gotten lazy for a few weeks, and not done my weekly backup...so I have kind of an older image on my backup drive.