Solved Random system files causing BSOD's

[insomniac0418]

Hey all,

I am typically one that like to troubleshoot things, but in this instance, I am at a bit of a loss on how to fix this one. Any recommendations towards a solution would be fantastic at this point.... as I am super busy with work and other things and just simply don't have the time lately to effectively troubleshoot this

Since I have built this system, I have received various BSOD crashes and cannot seem to put my finger on what the problem may be. I say that thinking that perhaps it is the operating system itself. I have a computer build on which I dual boot from two SSDs, one for Windows 7 Ultimate 64-bit, one from Windows XP Professional 32-bit. The XP partition is the one I'm using as of late because of this problem

Seeing various system files being deemed as the root cause of this. The list currently shows as follows, which should show in the DMP files provided:

hal.dll
ntoskrnl.exe
CLFS.sys
nvlddmkm.sys

The operating system when loaded up using the Win7 partition will be doing something as simple as browsing the internet, watching movies on Windows Media Center, or even when I leave for work and leave the PC idle. I cannot determine what is causing this to happen. The other operating system works absolutely fine which leads me to draw away from a hardware issue. Memory and hard drives have checked out ok as well. I was overclocking the processor at first, but since this began happening, I put them BIOS back to default settings to stop overclocking the CPU. Yet, the BSOD's still occur.

I will leave this for review. Again, any point in the right direction with this would be beneficial. I am in the middle of a move and have a lot going on, and hate to put this on someone elses shoulders to look at, but if someone can at least review the minidump files I provided... and even give me a pointer on how to go about learning to review them, I would truly appreciate it. Thanks!

- Mike P

 

[Arc]

Welcome aboard.

As per Carrona.org, STOP 0x00000109: CRITICAL_STRUCTURE_CORRUPTION
Usual causes: Device driver, Breakpoint set with no debugger attached, Hardware (Memory in particular)

Your crash dump says:

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


BUGCHECK_STR:  0x109

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff8000328d1c0

STACK_TEXT:  
fffff880`031cb498 00000000`00000000 : 00000000`00000109 a3a039d8`9c0e54ec b3b7465e`ee8c246a fffff800`0381137c : nt!KeBugCheckEx


STACK_COMMAND:  kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !hal
    fffff8000381142c - hal!XmMulOp+b0
    [ 0b:09 ]
1 error : !hal (fffff8000381142c)

[COLOR=Red]MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption[/COLOR]

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  ONE_BIT

[COLOR=Red]FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT

BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT

Followup: memory_corruption[/COLOR]
---------

So, better it is to check the memory modules.
http://www.sevenforums.com/tutorials/105647-ram-test-memtest86.html
Run it for at least eight passes, per module per slot.

Let us know the result.

 

[insomniac0418]

Hello Arc,

Thanks for the warm welcome.

So may I ask, I have only two RAM slots being utilized right now. Are you suggesting that I take each stick of RAM individually, then run a memtest for 8 hours on each of my 4 memory DIMMs, even though two of them are currently not being used?

- Mike P

 

[Arc]

Mike, I know that the process is time consuming, and and boring. But, memory corruption is caused by not only corrupted RAM modules, but also corrupted RAM slots.

If you think, you may use the slots those are being used only right now.

Best of luck.

 

[insomniac0418]

Hey Arc,

No don't worry I just wanna make sure I am doing the right things here that's all. I have four days off this weekend so I can run tests and follow up with you on my findings. Just may take some time to do since I will be working remotely during the hurricane coming this Monday but when I am done I will follow up with my results. Thanks again!

Also, any advice on how to get adept in reading dump files? Anything in particular that you use to do this?

 

[Arc]

I use Debugger Tool. You may have a try, too.

 

[insomniac0418]

Hey Arc,

Sorry for the long hiatus away from here... finally got power back on Thursday. It's been a rough two weeks here!

Anyway, I kicked off a memtest last night. First stick of memory in the first DIMM slot test fine for 8 hours with no errors or reboots

Turned off the computer. Plugged in the other stick of memory in the same slot and ran the same test. Came home from work today and saw that my computer was rebooted and the OS was there.

I believe that I may have found the culprit. I am running memtest on the working stick of RAM in the other DIMM slot that I was using previously with the other stick of RAM that caused the reboot.

Thanks for the link too. When I am done with the memory testing, I'll give it a shot and check it out. You've been a big help. Thank you sir!

 

[Arc]

 

[insomniac0418]

Hey Arc,

Seems as though like it was the other stick of memory. The memtest for the working one checked out fine on my other DIMM slots. Guess I will be trucking along on 4 GBs of memory until I get the new stick in. Geez I hope my computer can handle it

Thanks for your help. As for that debugger tool, looks like this can be something fun for me to learn as well. Hopefully one of these days I can return the favor to help ya if need be

The system which was rebooting randomly probably every couple of hours, has been on a 24 hour run with no hiccups or reboots. Let me give this til over the weekend as I'm gonna let it run idle and see if I come home to a login screen, which was becoming a normality previously. I'll let ya know what happens!

 

[Arc]

Best of luck mate

 

[insomniac0418]

Hey Arc,

I believe that the issue is resolved. Have not had a reboot since I left it up Saturday night. This thread can be closed

 

[Arc]

Good news. If there are some more troubles, let us know.