Windows 7 clean install on SSD - Now BSOD errors galore

[Crane358]

Hi Everyone,

First time poster but I have often lurked and found solutions here. Yeah!

This time though I'm not sure what to do to get my computer up and running again. I'm happy to say that I've rarely had a BSOD and now while rebuilding my system I'm getting them all over the place.

Here's the short version. I built myself a nice gaming / multimedia system about 18 months ago. (I do web and multimedia work with video, cd, dvd etc.). On a daily basis the computer is heavily used. Adobe Master Collection by day, Battlefield 3 by night.

I first installed a new hard drive, partitioned and installed Windows 7 to the C Drive. The next thing I always do is install Acronis True Image and Disk Director. I then archive the clean install install all my apps to the E Drive and then do another archive.

A couple months later I installed an SSD drive (60 GB) and restored my Windows 7 archive on it. Ran great but always running out of room on C Drive.

Eventually upgraded to a 120 GB Vertex Agility 3, installed OS from Acronis Image and again all was well for a while. Agility 3 started acting wonky and I read of the sandforce firmware issues. I was about to start a big job so I got an ADATA S510 120 GB on sale and it immediately that cleared up those instability issues I was having and allowed me to finish my job. Its been running great. Yeah.

Over the past 3 weeks though my system has been lagging. Just opening a directory in Windows explorer was unsually slow but the system would work. So I would just say hmmmm to myself and keep going.

Well after a few weeks of this I thought okay, I have time now, lets figure this out. I decided to do a clean install of Windows 7 on the ADATA SSD and all my apps. That's when I started down the rabbit hole and its been hell ever since.

After a clean install of windows, followed by some mobo and graphics drivers I let Windows run some updates. Well I can't seem to run Windows updates without a BSOD. My faithful Acronis True Images will not install properly and so on.

Lots of BSOD and I'm now doing learning curve on all that. Event Viewer, mini dump etc. I've noticed a lot of MsiInstaller errors and 7001 errors but its mostly new territory for me so here I am asking for help. Please find attached my latests BSOD logs as per the forum sticky.

Thanks,
Crane358

 

[Vir Gnarus]

All of the crashdumps point to an ancient snapman.sys driver (2006) that's part of Acronis True Images. The installation of it may be corrupt which would cause this problem. I went ahead and googled a bit and came up with this thread that explained how to manually uninstall it.

 

[Crane358]

Hi Vir,

Thanks so much for your speed reply.

Zonds ... my old faithful Acronis True Image looks like its the culprit. Maybe its just a bad install. I've been using TI for years and currently home version 2011 and this is the first time I've had or heard of this issue. I'll uninstall and forge ahead and see if I can get back to normal day to day operations.

I'll post my outcome for others.

Cheers,
Crane358

 

[Crane358]

Hi Vir,

Quick follow up. I think Disk Director must also you this snapman.sys file. When I try to uninstall Disk Director I get the BSOD. The link you mentioned for manual uninstall is fairly old so I'm concerned I may follow the steps and yet still miss something. Indeed it I may just start my clean Windows install from scratch and simply avoid the Acronis apps altogether for now.

I'm curious though, in the minidump files and logs where are the snapman.sys references located? I would like to understand all this debugging better. To start with I've downloaded the BlueScreen Viewer app.

Thanks,
Crane358

 

[Vir Gnarus]

Disk Director may be the cause of the BSOD, but if I'm correct, snapman.sys may be a filter driver (most likely), and if that's the case any I/O that would be relevant to it (like disk operations) would have to pass through it (hence the name 'filter driver'). So while Disk Director may have triggered the fault, the actual cause would've probably been snapman.sys (and therefore Acronis).

Kernel debugging is a pretty intense field, and those who specialize in it (escalation engineers) are one of the highest level IT positions in the industry. It requires a rather broad and deep knowledge of OS functionality, hardware, and both high (C-based, etc.) and low (Assembly) level languages to get a comfortable grasp of what's displayed in a crashdump. It's definitely a big step up from the average troubleshooting defined in A+ exam curriculum or even more advanced server administration courses.

I personally am still a novice at the stuff, and though I started with only a intermediate grasp of PC troubleshooting, not knowing a thing about what a BSOD was telling me, my curiosity with the output of BSODs and crashdumps and my passion for forensic troubleshooting (basically "PC detective work") led me to where I am now. I believe anyone with the interest in how PCs tick would be able to commit themselves to learning this kinda stuff no less than I.

Anyways, aside from all that, the answer to your question: snapman.sys was located in the callstack of the faulting thread in every crashdump. A couple of the crashdumps also catch it in an attempt to performing a bad execution.

You can find all of what I'm talking about by following the instructions in the simple tutorial located here. That should get you to where you can run Windbg (Debugging Tools for Windows) and - having set it up properly with symbols - run through the !analyze -v output which is the analysis engine that should do most of the initial work for you. Here's an example straight from one of your crashdumps:

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


Loading Dump File [C:\Users\igarvin\AppData\Local\Temp\7zO9213.tmp\031412-13728-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: symsrv*symsrv.dll*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c12000 PsLoadedModuleList = 0xfffff800`02e4fe50
Debug session time: Wed Mar 14 00:47:58.732 2012 (UTC - 4:00)
System Uptime: 0 days 0:05:12.714
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {0, 0, 0, 0}

*** WARNING: Unable to verify timestamp for snapman.sys
*** ERROR: Module load completed but symbols could not be loaded for snapman.sys
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
[COLOR="Red"]Probably caused by : snapman.sys ( snapman+19089 )[/COLOR]

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


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

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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

TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2

EXCEPTION_CODE: (Win32) 0 (0) - The operation completed successfully.

FAULTING_IP: 
+0
00000000`00000000 ??              ???

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000000000

ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0

BUGCHECK_STR:  0x1e_0

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002c7bc2e to fffff80002c83ed0

[COLOR="Green"]STACK_TEXT:  
fffff880`030af788 fffff800`02c7bc2e : fffff880`00000008 fffff880`00000000 fffff880`030aff90 fffff800`02cb0e28 : nt!KeBugCheck
fffff880`030af790 fffff800`02ca9bed : fffff800`02e90c24 fffff800`02dc9a3c fffff800`02c12000 fffff880`030afef0 : nt!KiKernelCalloutExceptionHandler+0xe
fffff880`030af7c0 fffff800`02cb1250 : fffff800`02dd1b5c fffff880`030af838 fffff880`030afef0 fffff800`02c12000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`030af7f0 fffff800`02cb282e : fffff880`030afef0 fffff880`030aff90 00000000`00000001 00000000`00000000 : nt!RtlDispatchException+0x410
fffff880`030afed0 fffff800`02c8ce20 : 00000000`00000000 00000000`00000246 fffff880`00000000 00000000`00000018 : nt!RtlRaiseStatus+0x4e
fffff880`030b0470 fffff880`01834089 : 00000000`00000001 fffffa80`00000001 fffff880`03088180 fffff880`01846100 : nt!KeReleaseMutant+0x260
fffff880`030b0520 00000000`00000001 : fffffa80`00000001 fffff880`03088180 fffff880`01846100 fffffa80`0dc55528 : snapman+0x19089
fffff880`030b0528 fffffa80`00000001 : fffff880`03088180 fffff880`01846100 fffffa80`0dc55528 fffff880`0182f767 : 0x1
fffff880`030b0530 fffff880`03088180 : fffff880`01846100 fffffa80`0dc55528 fffff880`0182f767 ffffd8f0`00002710 : 0xfffffa80`00000001
fffff880`030b0538 fffff880`01846100 : fffffa80`0dc55528 fffff880`0182f767 ffffd8f0`00002710 fffff880`00e9bee1 : 0xfffff880`03088180
fffff880`030b0540 fffffa80`0dc55528 : fffff880`0182f767 ffffd8f0`00002710 fffff880`00e9bee1 fffffa80`0d741000 : snapman+0x2b100
fffff880`030b0548 fffff880`0182f767 : ffffd8f0`00002710 fffff880`00e9bee1 fffffa80`0d741000 fffffa80`0dc55528 : 0xfffffa80`0dc55528
fffff880`030b0550 ffffd8f0`00002710 : fffff880`00e9bee1 fffffa80`0d741000 fffffa80`0dc55528 fffffa80`0dc4cbc0 : snapman+0x14767
fffff880`030b0558 fffff880`00e9bee1 : fffffa80`0d741000 fffffa80`0dc55528 fffffa80`0dc4cbc0 fffff880`0183959a : 0xffffd8f0`00002710
fffff880`030b0560 fffffa80`0d741010 : fffffa80`0dc55528 fffffa80`0da3a8d0 fffffa80`0d7c9ca8 fffff880`011a284d : atapi!AtapiHandleAtaCommand+0x45
fffff880`030b0590 fffffa80`0dc55528 : fffffa80`0da3a8d0 fffffa80`0d7c9ca8 fffff880`011a284d fffffa80`0de1cb80 : 0xfffffa80`0d741010
fffff880`030b0598 fffffa80`0da3a8d0 : fffffa80`0d7c9ca8 fffff880`011a284d fffffa80`0de1cb80 fffff880`01838f72 : 0xfffffa80`0dc55528
fffff880`030b05a0 fffffa80`0d7c9ca8 : fffff880`011a284d fffffa80`0de1cb80 fffff880`01838f72 00000000`0000003c : 0xfffffa80`0da3a8d0
fffff880`030b05a8 fffff880`011a284d : fffffa80`0de1cb80 fffff880`01838f72 00000000`0000003c fffffa80`0ccc5e10 : 0xfffffa80`0d7c9ca8
fffff880`030b05b0 fffff880`011b49bb : fffffa80`0d741010 fffffa80`0ccc5e10 fffffa80`0d20fa48 fffffa80`0d80a000 : volsnap!VspAsynchronousIo+0x9d
fffff880`030b05f0 fffff880`011b4c13 : fffffa80`0ccc5d00 fffffa80`0d741010 fffffa80`0d20fa30 fffffa80`0ccc5d80 : volsnap!VspWriteTableUpdates+0x29b
fffff880`030b0680 fffff880`0119fbe5 : fffffa80`0fc0ac60 fffffa80`0ddc9290 fffffa80`0dc67190 00000000`00000000 : volsnap!VspWriteSnapshotWriteCompletion+0x143
fffff880`030b06c0 fffff800`02c86516 : fffffa80`0fc0afbb 00000000`00000000 00000000`00000000 fffffa80`0fc0ac60 : volsnap!VspPerformanceWrapperCompletionRoutine+0x55
fffff880`030b0710 fffff880`018f48ee : 00000000`00000000 fffff800`02d36001 fffffa80`0de1cc98 00000000`00000000 : nt!IopfCompleteRequest+0x3a6
fffff880`030b07f0 fffff800`02c86516 : 00000000`00000000 fffff800`031f4156 fffffa80`0d8b1ea0 00000000`00003000 : CLASSPNP!TransferPktComplete+0x1ce
fffff880`030b0870 fffff880`0102b41a : 00000000`00003000 00000000`00000001 fffffa80`0de20010 00000000`00000000 : nt!IopfCompleteRequest+0x3a6
fffff880`030b0950 fffff880`0102b242 : fffffa80`0de20010 fffff880`0102db3b fffffa80`0de1cb80 fffffa80`0d8c21b0 : ataport!IdeCompleteScsiIrp+0x62
fffff880`030b0980 fffff880`01025e32 : 00000000`00000000 00000000`00000000 fffffa80`0ca05500 fffffa80`0d8c21b0 : ataport!IdeCommonCrbCompletion+0x5a
fffff880`030b09b0 fffff880`0102e7ed : fffffa80`0ca041a0 fffffa80`0de20010 00000000`00000000 fffffa80`0de20010 : ataport!IdeTranslateCompletedRequest+0x236
fffff880`030b0ae0 fffff880`0102e0ec : fffffa80`0ca041a0 00000000`00000000 fffffa80`0ca041a0 00000000`00000000 : ataport!IdeProcessCompletedRequests+0x4d5
fffff880`030b0c10 fffff800`02c8f5dc : fffff880`03088180 00000000`3ab0b4be fffffa80`0ca04050 fffffa80`0ca04118 : ataport!IdePortCompletionDpc+0x1a8
fffff880`030b0cd0 fffff800`02c8c6fa : fffff880`03088180 fffff880`03093040 00000000`00000000 fffff880`0102df44 : nt!KiRetireDpcList+0x1bc
fffff880`030b0d80 00000000`00000000 : fffff880`030b1000 fffff880`030ab000 fffff880`030b0d40 00000000`00000000 : nt!KiIdleLoop+0x5a

[/COLOR]
STACK_COMMAND:  kb

FOLLOWUP_IP: 
snapman+19089
fffff880`01834089 ??              ???

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  snapman+19089

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: snapman

IMAGE_NAME:  snapman.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  45265d99

FAILURE_BUCKET_ID:  X64_0x1e_0_snapman+19089

BUCKET_ID:  X64_0x1e_0_snapman+19089

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

The callstack is the section in green. It shows how activity in this thread has passed from one part of code in a module (ataport, CLASSPNP, snapman, etc., are modules) to another (by calling them), starting from the bottom and working up the stack until it reaches the very top, which is the latest code to be executed by the thread. In this case, it the nt module, and the function it was running is KeBugCheck, which is pretty self explanatory (a bugcheck is the technical name for a BSOD).

Note that KeBugCheck is a symbol name for the function. It is provided to give a basic description of what the function does as a convenience to us looking at the crashdump to get an idea what's going on. Otherwise it will just say the name of the module followed by a big number. Obviously snapman doesn't have public symbols available for us to look at, so it makes it difficult for us to figure out what it was doing. It's because of this that one needs to strive to make sure they have not only symbols but proper symbols, as if they aren't correct then they will mention names of functions that actually have nothing to do with what was going on. Because I have my symbols in Windbg set to grab symbols from Microsoft's public symbol server, I can see all the nice and neat function names for anything related to Microsoft products (like Windows drivers). However, often you will not have this luxury with 3rd-party drivers (like snapman.sys), hence why you get the ugly number at the end.

The callstack is not the only section that mentions snapman.sys. The analysis engine at the very beginning suspects it's the cause of the BSOD (marked in red in the above output), and there's a number of other tidbits that mark is as suspect. Note that these are not 100% conclusive, as something behind the scenes may have tripped up snapman.sys and now it's left with the handbag. But given from what I found on google as well as seeing this consistently pop up in your crashdumps, I would be comfortable pointing blame at it.

I plan on making public my articles I've made during my ventures in debugging. I'm not 100% accurate on my stuff but I'm sure I know at least enough to gain a modicum of trust in my articles. There's also a good, more advanced article here then the one previously linked, but the terminology may be above your head a bit at the moment. Most of all, if you are curious and find yourself wanting to pursue this in any way, the book Windows Internals is absolutely imperative. It will start you with basic functions of the OS and important fundamentals and will also cover indepth anything inside Windows. You can also go after the latest version which covers 2008 R2 and Windows 7 here but they decided to split the content and this only covers the first half, whereas the previous book covers everything. Though it's outdated, all that much has not changed internally from Vista to Windows 7, so much still applies (plus the fundamentals are all there).

It's up to you where ya wanna go with all of this. I can understand if it appears intimidating, because it is. But if you have any curiosity about this stuff as I do you'll find the challenge utterly intoxicating.

 

[Crane358]

Wow, great reply, thanks so much. I totally understand how specialized this type of trouble shooting is. It is tremendously complex. I do appreciate that you and others have time to help others in these forums. I do hope to get enough of a primer in BSOD de bugging that I can identify guilty drivers.

I'm still feeling a bit jilted by Acronis. I've used it for years with no trouble. Once my system is re-built I'll need to find a different utility to replace what it does.

Wouldn't it be nice if we just got a dialog box telling me Acronis installed an old buggy driver. But I guess that would ruin all the fun for you

Cheers,
Crane358

 

[Vir Gnarus]

That 'dialog box' is actually the BSOD. The BSOD is there to inform, not to threaten (as many people feel it does). Microsoft tries to discover and snuff out bugs discovered in 3rd-party software so that they can generate informational dialog to users. That's what the WER (Windows Error Reporting) thing is all about (the one where you send your report to them). While it does manage to catch some common device driver bugs, it's a whole different story for random bugs like this. Microsoft is not responsible for the problems risen by faulty code from 3rd-party organizations, nor are they responsible in ensuring that users update their software (I mean, the Acronis driver snapman.sys IS from 2006, so I would figure it is not Windows 7 friendly). Ultimately, they can only do what they can with what they have.

As for getting a primer in BSODs, aside from the articles I mentioned earlier as well as the Windows Internal book, your other interest should be to start learning Assembly. That will greatly assist you in figuring things out. There is the free Art of Assembly online, but do be a bit careful in that the assembly it presents is not identical to the "raw" assembly code you'll see when debugging crashdumps. The stuff in crashdumps are the raw opcodes that are sent to the CPU, while Art of Assembly's "higher-level" assembly language compromises accuracy with some more user-friendly code that looks very similar but not identical. Still one of the best publications out there on it, and it's free, so can't beat that!

Also a great start is to watch Mark Russinovich's Webcasts. He is incredible at presenting detailed stuff like this with very basic terminology that anyone with some PC troubleshooting knowledge can pick up easy. I recommend the Case of the Unexplained series, Hang & Crash Dump Analysis, and Mysteries of Windows Memory Management Revealed. They're all free, except for the ancient Sysinternals Library at the very bottom.