2

I recently followed these instructions[1] to shrink my main Windows 7 volume on my SSD. They involved temporarily disabled System Restore and Paging. Since doing so I have gotten a few blue screens. I used WinDbg to examine memory.dmp as well as the core dumps in my C:\Windows\Minidump folder. They all indicate a CRITICAL_STRUCTURE_CORRUPTION (109). The MSDN page is at [2].

Microsoft suggests:

  1. Use System Restore. I cannot do this because when I disabled System Restore to do the volume shrink it deleted my restore files.
  2. Use the Action Center. Yeah right.
  3. Check Windows Update. Done.
  4. Search for drivers on the manufacturer website. Unless I know which driver is problematic, this is just trial and error.
  5. Use Safe Mode. What would I do in Safe Mode that I haven't already done?
  6. Check for hard disk and memory errors. memtest and chkdsk both indicated no problems.

I assume the problem has something to do with shrinking the volume, but the error codes indicate a driver problem.

Is there anything else I can do to help narrow the problem down? A more thorough chkdsk that will make sure Windows is happy with the location of its paging file, etc. now that the volume is smaller?

Is there any way to view drivers chronologically in Windows?

[1]http://www.brandonchecketts.com/archives/how-to-shrink-a-partition-with-unmovable-files-in-windows-7 [2]http://msdn.microsoft.com/en-us/library/windows/hardware/ff557228%28v=vs.85%29.aspx

WinDbg output:

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 (removed link) 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: a3a039d8959c8728, Reserved Arg2: b3b7465ee81ac29e, Reserved Arg3: 00000000c0000082, Failure type dependent information Arg4: 0000000000000007, 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: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x109

PROCESS_NAME: System

CURRENT_IRQL: 0

STACK_TEXT:
fffff88002fd95d8 0000000000000000 : 0000000000000109 a3a039d8959c8728 b3b7465ee81ac29e 00000000c0000082 : 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

Micah Nance
  • 29
  • 1
  • You will need to attempt to repair your installation. I suggest you follow the appropriate instructions to do that.. – Ramhound Mar 10 '13 at 08:17
  • Windows boot partitions are flakey, ssd's are flakey, you messed with both man... double boo boo. I hope you get it sorted, but until you wipe the entire disk, repartition and re-install windows, you'll always be waiting for the next BSOD. – SwiftD Mar 10 '13 at 12:15
  • Did a repair install (wiped out MBR grr) but so far so good. I'll wait a week or so before I declare it actually fixed, though. – Micah Nance Mar 14 '13 at 00:45

1 Answers1

0

I did a repair install and things have been going smoothly ever since.

Micah Nance
  • 29
  • 1