CRITICAL_STRUCTURE_CORRUPTION (109) BSOD very frequently

[ARQuattr]

I purchased a refurbished Lenovo laptop from Tiger Direct this week and the first couple of days while I was installing software and setting it up it worked OK with no BSOD. Then for the last couple of days it has been giving the BSOD frequently (at least once per hour on average). Every time I saw it happen it referred to CRITICAL_STRUCTURE_CORRUPTION.


I tried uninstalling some of the software I had installed, and stopped or ended most tasks in the task tray or task manager, but it didn't help. I ran the mdsched to check the memory but it passed with no issues. It doesn't seem to matter what applications are running, and sometimes it will happen when just sitting there idle with no applications running.



I followed the posting instructions however when running perfmon it gave a “The operator or administrator has refused the request.” error, even though the command window was run in admin mode. I did however run windbg and attached the report below. It doesn't look very helpful to me, but you guys are the experts.


Thanks for any help you can offer,
Angelo




· OS - Windows 8.1 x64
· What was original installed OS on system? Windows 8.1
· Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)? It came pre-installed
· Age of system (hardware) – Purchased this week as refurbished, label shows mfg date Aug 29, 2014
· Age of OS installation - have you re-installed the OS? Original installation after refurbishment (not sure if it was reinstalled)

· CPU - Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40 Ghz
· Memory – 6GB
· Video Card – Intel HD Graphics Family
· System Manufacturer - Lenovo
· Exact model number – Flex 2-15, 20405

· Laptop or Desktop? Laptop



Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17085.amd64fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0xfffff802`dde70000 PsLoadedModuleList = 0xfffff802`de13a2d0
Debug session time: Fri Jun 26 18:29:23.450 2015 (UTC - 4:00)
System Uptime: 0 days 1:10:00.317
Loading Kernel Symbols
...............................................................


Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

................................................................
.......................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00007ff7`71a6f018). Type ".hh dbgerr001" for details
Loading unloaded module list
............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a00f58b2640735, b3b71bdf04e33d10, ffffe00014134980, 1c}

Page 145581 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

3: 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 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: a3a00f58b2640735, Reserved
Arg2: b3b71bdf04e33d10, Reserved
Arg3: ffffe00014134980, 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:
------------------

Page 145581 not present in the dump file. Type ".hh dbgerr004" for details

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: csrss.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

STACK_TEXT:
ffffd000`203fb088 00000000`00000000 : 00000000`00000109 a3a00f58`b2640735 b3b71bdf`04e33d10 ffffe000`14134980 : 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

IMAGE_VERSION:

BUCKET_ID: BAD_STACK

FAILURE_BUCKET_ID: BAD_STACK

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:bad_stack

FAILURE_ID_HASH: {75814664-faf6-4b70-bbc7-dc592132ecdd}

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

 

[ARQuattr]

I found that there was a restore point created automatically before doing a windows update, and the time that this happened coincided with the BSODs appearing. I tried to restore about five times but it kept giving me the BSOD each time, so I managed to get it into safe mode and start the system restore with rstrui.exe (in safe mode the System Protection option in the System Control Panel is not available), and restore to the point before the windows update. Since doing this the machine has been running several hours with no BSOD. Previously it would typically BSOD every ~10 min on average.

I'm rather convinced now that some driver update cased this. After restoring, Windows is again asking to update and restart, which I disabled so I don't accidentally do that, but there are over 120 updates that it wants to do, at least one of which presumably caused the BSOD problem.

So how do I know which updates to accept and which not to? What about the Windows 10 upgrade? Thinking back I believe the majority of my system problems on various computers came after installing windows updates, service packs, etc. I used to avoid updates entirely years ago with Win XP/7, but I assumed that recent OS releases were more stable and reliable. What is the best practice from forum members? Should I go back to avoiding them, or do I need to create restore points, and maybe update only a few at a time?

Thanks