System Mechanic is a prime suspect. It has active services that can interfere with AV programs and Windows services. Did your problems start after installing it or setting active monitor options?
To post an image to the forum, use the paperclip in the message tool ribbon (next to the emoticon menu). A popup will appear for message attachments. Browse your PC for the image, Upload then close the window.
Here's the snip. And now I have a newly developed problem. The system now randomly BSOD when it's idle. It happened twice in the past hour, which never happened before. So I reran the diagnostic tool and posted the files. I also uninstalled System Mechanic just now, so hopefully there will be an improvement.
There's only one dump in the last set and it's indicating a complete failure of the memory structure. That lead me back to the system event log and sure enough, there's drive controller errors along with system drivers failing to load. It appears that your disk drive is failing. That's most likely the reason memtest found nothing and the BugCheck codes are all over the place. Windows detected a failure of the drive controller so a check disk (chkdsk) or a drive maintenance/repair will most likely fail too. Your disk is a Seagate Momentus Model ST9500420AS (500GB 7200 RPM 16MB Cache SATA 3.0Gb/s 2.5") and most likely out of warranty. You should start making an attempt to save as much of your data, such as photos, as you can on an external disk or USB drive before the disk fails completely. The problem is that some of the data may already be corrupt.
Code: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 Kernel patch protection for x64-based operating systems 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: a3a039d89e3b24f4, Reserved Arg2: 0000000000000000, Reserved Arg3: 8e1a57b9f6c5bc5d, Failure type dependent information Arg4: 0000000000000101, 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: ------------------ BUGCHECK_STR: 0x109 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80003e77bc0 STACK_TEXT: fffff880`035625d8 00000000`00000000 : 00000000`00000109 a3a039d8`9e3b24f4 00000000`00000000 8e1a57b9`f6c5bc5d : 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 ---------
Quote