Solved BSOD dont know how to read dump files but have attached

[pinksock]

Hi,

I get random BSOD a lot since updating from 8 to 8.1. I don't know how to interpret these files, but I followed the instructions to make a zip with the diagnostics tool. I've attached this file, anyone who could help me interpret what is going wrong would be greatly appreciated.

Thanks

 

[Arc]

Hi pinksock.

Your BSODs are all stop 0x109 and they are not showing any possible cause.

Test your RAM modules for possible errors.
How to Test and Diagnose RAM Issues with Memtest86+
Run memtest for at least 8 passes, preferably overnight.

If it start showing errors/red lines, stop testing. A single error is enough to determine that something is going bad there.

Stress test the CPU.
Hardware - Stress Test With Prime95

If those tests are free from errors, enable Driver Verifier to monitor the drivers.
Driver Verifier - Enable and Disable
Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.

   Information

Why Driver Verifier:
It puts a stress on the drivers, ans so it makes the unstable drivers crash. Hopefully the driver that crashes is recorded in the memory dump.

How Can we know that DV is enabled:
It will make the system bit of slow, laggy.

   Warning

Before enabling DV, make it sure that you have earlier System restore points made in your computer. You can check it easily by using CCleaner looking at Tools > System Restore.

If there is no points, make a System Restore Point manually before enabling DV.

   Tip

• If you fail to get on the Desktop because of DV, Boot into Advanced Boot Options > Safe mode. Disable DV there. Now boot normally again, and try following the instruction of enabling DV again.
• If you cannot boot in Safe mode too, do a System Restore to a point you made earlier.

Let us know the results, with the subsequent crash dumps, if any. Post it following the Blue Screen of Death (BSOD) Posting Instructions.
__________________________________________________________________________________________________

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a01f58967ff692, b3b72bdee8ff2c6d, ffffe00000fc20d0, 1c}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f58967ff692, Reserved
Arg2: b3b72bdee8ff2c6d, Reserved
Arg3: ffffe00000fc20d0, Failure type dependent information
Arg4: 000000000000001c, Type of corrupted region, can be
    0 : A generic data region
    1 : Modification of a function or .pdata
    2 : A processor IDT
    3 : A processor GDT
    4 : Type 1 process list corruption
    5 : Type 2 process list corruption
    6 : Debug routine modification
    7 : Critical MSR modification

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


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x109

PROCESS_NAME:  System

CURRENT_IRQL:  2

STACK_TEXT:  
ffffd000`20994088 00000000`00000000 : 00000000`00000109 a3a01f58`967ff692 b3b72bde`e8ff2c6d ffffe000`00fc20d0 : nt!KeBugCheckEx


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  BAD_STACK

Followup: MachineOwner
---------

 

[pinksock]

Hi,

Thanks for your suggestions.

I should add that I ran the driver verifier and my computer would not boot, it would constantly BSOD and reboot. Would this be evidence that it is a driver and not hardware problem? I had zero BSOD under windows 8, and they started immediately after I upgraded to 8.1. Unfortunately when it goes into a boot-loop from driver verifier it doesn't seem to make any dumps.

I will run the stress test and have the memory test run while I'm at work today.

 

[pinksock]

all hardware tests came out fine. I wiped everything clean and reinstalled/upgraded to 8.1. Everything seems to be working fine so far. I guess something just got corrupted during the first upgrade.

 

[Arc]

It may be.

Good to know that it is working fine now