4 TB DISKS NOT RECOGNIZED ON SATA PORTS AFTER 2012 INSTALL

There have been 31 views of this post at this time with no responses from anyone here.
So here goes my 2 cents.....

Acronis uses a filter driver to control the hard disks during backup, apparently this filter driver does not work with your 4TB drives when connected via SATA but has does not interfere when connected via USB.
USB docking stations and external USB drives are presented to the operating system differently than drives connected via SATA and PATA. Most USB docking stations and external drives work well with Acronis.
This problem you are having with the 4TB drives needs to be reported to Acronis support.
I would like to be able to offer some advice, but I don't have access to 4TB drives at this time.
BTW....from what I have learned, Seagate has discontinued the 4TB external USB 3.0 drive, and has halted production on the XT 4TB internal drive. Reviews of both the internal and external 4TB drives have been very poor (ie. reliability/compatibility issues).

In addition, you could try enabling the >2TB drive utility which you will find on the Tools and Utilities tab of 2012.

I've been having much worse behavior than this fellow experienced after recently acquiring two Seagate 4TB internal SATA III drives (ST4000DM000). I had already been successfully using Acronis True Image Home 2012, but after attempting to install these drives I began experiencing a series of blue-screen events, which are not at all a common occurrence for my system. Early on I observed that the proximate cause of some of them was vsflt67.sys, which is an Acronis driver. My latest step to identify and eliminate the cause of them was activation of the Verifier tool to stress all the non-Microsoft drivers.

The immediate and consistent consequence of employing Verifier is that now every single non-safe-mode restart is punctuated by a blue-screen event during the initial Windows splash screen. At first this was causing an immediate reboot so fast that no part of the details could be read, and with no .DMP file as evidence. I disable the auto-reboot option, and the next few reboots identified the cause: fltsrv.sys, another Acronis driver. It was specifically an event triggered by Verifier.

This seems like a pretty obvious bug or shortcoming, possibly caused by the 4K-sector issue or something else specific to these high-capacity high-density drives. Even though such drives were rare when this version was released, Acronis could reasonably be expected to have anticipated issues that might arise from them. My laughably brief warranty period has lapsed and so my only support option would require me to fork over cash to discuss an issue that is clearly not of my making. Has this issue been fixed with a patch to correct the misbehaving drivers? Was this version kicked to the curb and the problem addressed in a new version that would be supplied to me gratis to correct the problem? If not, I see no reason to give Acronis any more money for either new product or support; I will find an alternative developer that takes a more generous approach to correcting such issues.

Mark,

I'm not sure off hand whether there is another SNAPAPI build for 2012, but just in case there is, what build is your snapman.sys and and fltsrv,vsflt67.sys ?

Colin:

The snapman.sys driver has to my knowledge never been an immediate cause, but perhaps it's a silent conspirator? I have just uninstalled both Acronis products - Disk Director wasn't behaving either I discovered minutes ago - in an attempt to sidestep the nightmare that started six days ago; since uninstalling True Image can't be done from safe mode, and safe mode was the only environment accessible while Verifier was still active, I had to disable Verifier so I could once again at least boot into protected mode and do so. I haven't rebooted yet, though, and the drivers are still visible, so here are the driver versions:

snapman.sys: 4.2.0.668
fltsrv.sys: 1.2.0.49
vsflt67.sys: 1.1.0.67
vsflt61.sys: 1.1.0.61

Does that hint at a quick resolution?

Mark Craig

After removing both Disk Director and True Image, the filter drivers may still be installed (via registry entries).

One issue I can see is the multiple versions of the disk filter drivers.

I would suggest that you also download and run the 2013-2011 cleanup utility located here: http://kb.acronis.com/content/34876

Be sure to NOT let the cleanup utility reboot your system until you look at the following registry keys for the presence of any of the filter drivers you listed above, and remove them (only them, no other entries!) from the registry. You do not need to remove the actual files from your system.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318} and
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F}
in both of the UpperFilters and LowerFilters entries.

When using Disk director together with 2012, the recommended method of install is DD first then 2012, as 2012 uses a newer version of the filter drivers.

I would check for proper operation of your system after running the cleanup tool, then again after installing just 2012 to see if the 2012 versions of the filter driver are creating your issues.

Be sure to try the last version build 7133 of 2012 when testing.

The latest version of the filter drivers (for 2012) is here: https://kb.acronis.com/sites/default/files/content/2005/12/1515/snapapi… and documented here: http://kb.acronis.com/content/1515

James:

Thank you for reminding me of the Cleanup Tool. It did appear to be necessary to completely remove stragglers. Not enough time nor activity has elapsed to be proof of a cure yet, but it's been some hours now since I uninstalled the Acronis apps and no further blue-screening mishaps have arisen.

Could I also cure the problem by reinstalling True Image and updating the filter drivers as you proposed, or laboriously identifying and removing co-conspirators? Possibly, but honestly that was the pre-release job of the Acronis beta and QA teams, and I don't work for Acronis. (You and Colin apparently don't either, in spite of your efforts and apparent experience.) I simply need backup software that works in my chosen Windows ecosystem, not software that requires a sandbox and a leash and days of my time yanking on said leash. I've lost much productive time because of Acronis' failure to anticipate (this change in) my ecosystem and identify problems and conflicts and preemptively resolve them. There are so many alternatives, some of them even free of charge... what's my motivation for reinstalling and doing unpaid QA work when a productive result is no more guaranteed than choosing one of those alternatives? Been there once, got paid for it!

Mark Craig

Mark,

I can not predict your results with Acronis products and the 4TB hard disk drives, and I agree that Acronis should be the responsible party for QA of the products.

If you were to try 2012 again, I would test with build 7133 without running the separate filter driver update first. If the drives do not show up or instability of the system returns, you could then try the filter driver update.

Using Disk Director with such large capacity drives would not be something I would recommend as that program has not been updated for quite some time (long before 4TB hard disks came along).

James F, Colin B:

Thank you both for the suggestions and information. This response is tardy because I've had a LOT to do to recover a working system. There may have been other misbehaved players in the situation that actually caused or contributed to Acronis software misbehaving and appearing to be the direct cause of the "exceptional" problems. Notably, the maker (Gigabyte) of this motherboard, just recently installed a couple months ago, did not bother to design their software installation process to forcibly install drivers for ALL the potential usage scenarios of the motherboard. In particular it ONLY installs SATA drivers for the CURRENT mode - IDE, AHCI, RAID - that the ports were configured in the BIOS to use at the time of installation.

This had a devastating effect - TWICE - for me with these 4TB Seagate drives. They were prepped as GPT and formatted as single large 4TB volumes in AHCI mode, which had been the mode the (Intel Z77) ports were in since I first installed the motherboard, meaning that the ONLY current drivers that were present in the system were for AHCI. Shortly after that I decided that I wanted to install two 1TB drives and create a RAID 0 pair of them, so in preparation I configured the Intel Z77 ports - which must be configured as a group - for RAID mode. Remember, NO current driver for this mode exists, because Gigabyte didn't preemptively install it.

Doing this caused Windows to revert to a THREE-YEAR-OLD Intel driver that didn't support either GPT or 4K-sectors or 4TB drives, which then caused Windows to misidentify the drives' geometry, capacity, and partition sizes. Initially this didn't cause any actual loss of data, but I misunderstood the nature and cause of the problem and, thinking it was something else, used TestDisk to reinstate the correct partition info and get Windows to reassign a drive letter. Once I did that, corruption began to occur almost immediately to one of them as writes to the drive began to occur; I had used the drive as a target for most of the Windows "shell folders". I didn't realize immediately at the time that corruption was occurring; it was much later before I realized in hindsight what had happened and that it had all been "simply" a driver issue. Fortunately I had used TestDisk to make copies of all the files (which took days) before this happened.

To shorten the rest of the story, the author of Hard Disk Sentinel helped identify the driver problem - I was sending him reports from that software - but not before I had reverted to AHCI and then back to RAID a second time and caused a SECOND wave of corruption. Eventually a current Intel RAID driver was installed, corrupted data replaced. Meanwhile I was understandably still unnerved by what had happened with Acronis, since the blue-screening was dependent upon it, and so was very hesitant to reinstall it. I looked for other options, and found one called MirrorFolder. I installed it and set it up to do "realtime" software mirroring of several partitions and intermittent mirroring of one. Once I had a bit of fault tolerance again, I decided to reinstall Acronis.

So far, several days later, there have been no further Blue Screens of Death, though I've only used Acronis so far to convert a few archival backups to VHD format. The conclusion that I draw from all this is that the Acronis services were blind-sided somehow by the bad driver and conflicting information that resulted, and that was what led to the BSoDs. That's my best slightly educated guess, but the guess is all I have.

If any Acronis devs or QA folks are listening, I can round up information on the various good and bad driver versions involved, disk model numbers, etc. for in-house testing.

Guys... Great thread. @Mark, I have one comment. It's not Gigabyte that doesn't preemptively install other storage controller drivers. Its actually windows. Since Windows Vista, only the drivers for the storage controllers operate mode (set in BIOS) are enabled in the windows registry. As you know, this will cause issues if you attempt to change the operate mode of the storage controller in BIOS... AHCI > RAID or vice versa. Windows by design disables the drivers for a storage controllers other operate modes. When a BIOS change is made you must also tweak the registry or STOP 0x0000007B INACCESSABLE_BOOT_DEVICE typically appears. Obviously the size of your disks and their formatting plays an additional role here. Your other observations are spot on.

@shadowsports (since we're doing Twitterish addressing now :-):

In the past I've seen software installation packages for various hardware preemptively install drivers for hardware that isn't even physically present yet. Are you saying this behavior was completely thwarted beginning with Windows Vista, with no workaround possible? If so, the fellow at Gigabyte who discussed this at length with me yesterday is also none the wiser. This would be a shockingly stupid move on Microsoft's part, especially where storage drivers are concerned! Can you cite a source for this change?

Mark,
Grin.. I don't have twitter, my space... Not very much into social media. I value my privacy. Maybe its a bad habit from the other forums I post on.

Here you go:

http://support.microsoft.com/kb/922976

shadowsports:

Just lovely... so in the name of shortening the boot process Microsoft decided to stop detecting hardware or attempting to load all storage subsystem drivers? I had no idea they had pulled this stunt.

That is not, however, what happened in my instance. A RAID-mode driver apparently was present and active and was loaded, but it was simply too obsolete to support the new high-capacity Advanced Format GPT disks. My 300GB MBR boot drive was never affected by any of the drama: no boot failures and no data loss on the boot drive.  Also remember that I had not yet even created any RAID arrays when all this took place, merely switched the BIOS mode, and the new 4TB drives were never destined to become parts of one in any case.

Am I missing something?  Why was that driver present and active, contrary to KB922976, when I had never before used RAID mode? This installation of Windows was carried forward from an earlier AMD motherboard (I did a "sysprep" without SysPrep) and I might have used RAID mode with that motherboard, but it had an Nvidia chipset that would have required a completely different RAID driver. If KB922976 is to be believed, I see no reason why that IASTOR RAID driver from 2010 should have even been present, much less active in the Registry. I should have experienced the complete boot failure described, but I didn't!

Mark,
Indeed you were faced with several challenges. Outdated drivers unable to support the size and GPT formatting of such a large disk. Switching the operate mode of the controller. The presence of one or more Acronis upper/lower filter drivers in the sequence of events. All of which worked against you. Ports on the z77 chipset should be able to handle a switch from AHCI to RAID. The drives you mark as in the RAID Config utility should become RAID members and the other disks should continue to function as AHCI single disks. Alas, what was chosen to support this endeavor (not your fault) didn't work. I agree with your point in regards to not experiencing complete boot failure KB922976 as the corruption you experienced was due to the driver, disk size and formatting, and not the operate mode of the controller.

Test disk is a great app. Have used it many times myself. I'm impressed it was able to recover data from your disks given the situation.

I left Microsoft a bit of feedback about that KB article. Maybe they'll get back to me and help sort what happened? Nah....

TestDisk is an AWESOME app, especially for one that has never had a price tag. Christophe Grenier is a god! TestDisk has saved my bacon several times over the years.

I'm probably safe to resume using Acronis.

Thanks again for the discussion and listening. I guess this marks closure to the issue, if such things are tracked.