Sector 63 Issue Revisited - Here is a Prime Example of Acronis Support

I agree. If you read Article 1514 it is pretty obvious that Acronis doen't really have a good understanding of this problem or how to fix it. It is like they are throwing stuff at it in hopes that something sticks.

With the massive issues and problems with B&R 10 I would think that Acronis would go out of ther way to make Echo Server as rock solid as possible. It would give customers something solid to fall back on while this whole B&R 10 disaster gets resolved.

I would like to ask too. Acronis do you really understand this Sector 63 issue and what causes it? Do you have a 100% sure fire way to fix it as opposed to guessing?

It looks like Acronis is ignoring this question too. Care to comment Acronis?

I too would like a concrete fix to the Sector 63 issue. I have tried everything in article 1514 and the problem will go away for a while but always comes back. I agree that it looks like Acronis is just guessing at a fix.

It doesn't look like Backup & Restore 10 will be anywhere near usable in production for quite some time and I would like to keep running Echo Server until it is. So in your opinion Acronis why does this issue keep recurring and why haven't you come up with a known, permanent fix? Any rational behind the problem?

Hello all,

The problem with disk read errors is related to the handling of disks without MBR during partition analysis performed by Acronis True Image. This limitation was made by design to prevent hard drive corruption.

Our QA Team hasn't reproduced the issue with build #8398 yet, however I've already created a task for them and they'll look into it as soon as possible.

The mentioned build #8398 was the last on for Acronis True Image Echo line, since developers are working to improve Acronis Backup&Recovery 10 products (where that issue has been fixed already).

Thanks Ilya. That is the first honest, straight forward response I have ever gotten from Acronis. Direct and to the point. It is refreshing!

Just three days ago I had two customers that out of the blue started getting the Sector 63 error. They had both been running fine for over a year. One was build 8203 and the other 8353. I upgraded both to 8398 and it, at least in the short term, fixed the problem.

I won't jump for joy yet. That seems to be the the senario. The problem will go away for months and then for some reason rear its ugly head again. I'll keep you posted.

No joy. Of the two servers that were giving me the Sector 63 error only one of them seems to be working properly. The second one is still giving me the Sector 63 error. It is on the lastest build. 8398. So what now Acronis?

Hello Jim,

I need some additional information to create a new test case and to forward this information to our QA Department.

Could you please gather that information by the means of AcronisInfo utility as described at this KB article and attach it to your reply?

Additionally, could you please clarify what did you try to back up (drive/partition or just certain files/folders) and where did you try to save created archive (internal/external drive, network share, etc...)?

I'm looking forward to hearing back from you at your earliest convenience.

Thank you.

Attached is the AcronisInfo.zip file you requested. There is nothing special about this backup. I am backing up the entire server hard drive to an external USB hard drive. A Seagate FreeAgent Go drive to be specfic. If you look at the many, many threads about the Sector 63 error both here and elsewhere on the net the senerio is almost always the same. Backing up to an external USB hard drives. It will run fine for a long, long time and all of a sudden the Sector 63 error will rear its ugly head.

The original article 1514 was created on 12/14/2005 and updated on 9/1/2009 so this problem has been in existance for about four years now. Still prevalent and still in existance. For the record I am running Echo Server Build 8398. The latest and greatest. Time to put this issue to bed. Please let me know where we go from here.....

Hello Jim,

Thank you very much for the provided information, I have forwarded it to QA department and the fix will be available soon. I'll keep you updated.

Thank you.

Hi Ilya. Forgive me for being pessimistic but I won't hold my breath. This sector 63 issue has been going on for four years now and Acronis doesn't seem to have a firm grip on it yet. Can you give me a case number or something for my reference?

Hello Jim,

Your case number is #00464070. I have also sent you a PM with additional explanations.

Thank you.

Any reason why we can't have the additional explanations on the thread so that we can all learn, rather than just in a PM to Jim?

Thanks,
Dave.

Hi David. I agree. Here is the PM:

Unfortunately, the responsible developer is on vacation until 11th of January, so there will be no fix until that. Once it will be available, we'll update KB article 1514 and I'll notify you.
Also, please note that I have already mentioned this is more likely a "hack", not a "fix". That limitation on working with hard drives without MBR was made by design.
Thank you.

Ilya this PM brings up a whole new set of questions. Article 1514 in summary says to replace trueimage.exe, trueimageservice.exe and the snapapi drivers. First question: Sinice I am running Build 8398 there are no newer versions of those files then come with Build 8398 are there?

Second question: If Build 8398 has the latest exes and snapapi drivers and I am still getting the sector 63 error wouldn't that imply that article 1514 was a "guess" going all the way back to December of 2005?

Third question: Related to the second question. If the problem is related to no MBR on the USB drive and that was by design and the updated exes and snapapi drivers did not change the design of the program what was the point of article 1514?

What I am getting at is it seems like article 1514 was a total waste of time and effort wasn't it? Article 1514 was an update. A fix not a hack. Nothing in article 1514 changed the fact that Echo Server is looking for a MBR on the USB drive did it? Nothing in article 1514 put a MBR on the USB drive did it? I guess I am questioning why article 1514 even exists other then to make us feel warm and fuzzy that it might be a fix which by your definition is isn't.

Hi Ilya. In retrospect I think I really missed the boat here. Let me start buy quoting you:

"The problem with disk read errors is related to the handling of disks without MBR during partition analysis performed by Acronis True Image. This limitation was made by design to prevent hard drive corruption."

This Sector 63 issue is intermittent. Jobs will run flawlessly for weeks or months and then the Sector 63 issue pops up out of nowhere. Then after messing with it, updating exes, snapapi drivers and stuff it will go away for a while but then come back.

I guess the obvious question would be why it happens sometime and not other? Why it will go away for months and then all of a sudden reappear? If it were directly related to the external USB hard drive not having an MBR I would think it would happen every time without fail during partition analysis wouldn't it?

Please don't take this the wrong way but I still have a nagging feeling that Acronis doesn't really have a grip on what causes the problem and without a known cause a known fix doesn't seem likely. What scares me most is the comment by Acronis that the issue has been fixed in BR10. Has it?

HI Jim,

I have seen what's been going on around. Now, that keeps me wondering, why some hard drive failed and why some doesn't. We seems to trust too much around hard drive manufacturer. I have had this strange issue once. One hard drive failed and one doesn't. Doesn't that sound something? I have no doubt Acronis have some flaws, but the question here is why some work and some doesn't? With the kind of ongoing trend of "Updates" going on, "new releases, new drivers, new hotfixes" I believe Acronis too, is trying to keep up with the IT World. I am still waiting for the U1, wondering if it is truly up to date. I will keep you posted. Meanwhile I will experiment on things.

Hello all,

Jim, there are no new files for build #8398 in KB article 1514 yet. They will be available after 11th of January. Updated modules from were built especially to get rid of that "Failed to read data.." error. Actually the error still persists, but those modules just skips it, since it will not anyhow affect the backup process and created image consistency. It's a kind of a permanent fix, so after you replace trueimageservice.exe, etc.. the error shouldn't occur anymore (until you upgrade the software to the next build).

The issue was fixed in very early builds pre-release builds of Acronis Backup&Recovery 10.

Thank you and Happy New Year!

Hi Ilya. I just want to make sure I understand what you have said. The files in Article 1514 are custom written to address the Sector 63 error. They are not "updates" that have been included in Build 8398 correct? So in essence what I have done by upgrading some customers to Build 8398 is nullified the supposed fix in Article 1514?

I will agree that there are occassional bad hard drives but here is what I still don't understand. If not having an MBR on the USB hard drive causes a Sector 63 error then 100% of my backup jobs would be failing because 100% of my USB hard drives are missing a MBR. That is not the case. There has to be some other contributing factor to the Sector 63 error over and above not having a MBR on the USB hard drive. Thoughts?

I don't know if this is at all relevant, but I had persistent archive validiation failures on a file backup until I removed the "System Volume Information" folder from the source file list. So it turned out the errors had nothing to do with the USB archive disk after endless attempts to figure out what was wrong with it.

Hi Ilya. I went back and re-applied the trueimage.exe and trueimageservice from Article 1514 to Echo Server Build 8398 and the Sector 63 issue disappeared immediately. It might be a good idea to update Article 1514 with the following:

1) It is not just Echo Server Build 8353 (I can't vouch for True Image Home) that has the problem. I had it rear its ugly head on Build 8203 and I am sure it happens in other builds. Someone reading that article might think it is not applicable to them since they are not explicitly running Build 8353.

2) You might want to point out that the files in that article are custom fixes and are not incorporated in newer builds. I was under the assumption that the issues were fixed in Build 8398 and immediately started upgrading my customers to build 8398 thinking that would fix the problem. It did nothing more then re-interject it.

3) You might want to point out that this problem is particularly relevant to backing up to external USB hard drives. I have never had to go as far as updating the snapapi drivers. Replacing trueimage.exe and tureimageservive.exe has without fail worked in all of my cases.

So as we speak I am running Echo Server Build 8398 with older versions of trueimage.exe and trueimageservice.exe That can't be good. Please let me know when you come out with patched trueimage.exe and trueimageservice.exe for Build 8398.

We too have serveral clients who have purchased echo server, based on our recomendations. It worked great for a period of time backing up to external USB drives. Just like everyone else points out here we started seeing failures at most of our clients randomly.

Acronis says B&R 10 resolves the problem. However, unless they are giving existing customers free upgrades to B&R 10 that is not an option. How can we convince a client to purchase a new version of a product that the old version isn't working? And, the customer paid for the old version and should expect that version to be supported and all issues resolved for a certain period of time. The End Of Life cycle for a product has to be more than 1 year. We need a new build for echo server that works and any and all fixes incorporated in it. Or, at least a service patch to address issues or something.

I have a server (Server 2008 x64 Standard) running Exhcnage 2007 in a poduction environment that has an external USB 1.5TB HD with daily (FULL SYSTEM IMAGE) backups running flawlessly for 11 months. The Acronis Version is Echo Server (build 8203) This server runs a pair of RAID mirrors.

A second server with the EXACT specs was built to handle an accounting system. The ONLY difference in the two systems is that this 2nd box runs RAID 5. (instead of RAID mirror)

I purchased a second license for this box 3 months ago and installed the same TI build (8203). This box durring the 1st part of the backup causes an unexpected reboot of the server. Sometime the server has to do a volume consistancy check on the RAID array after the sudden reboot. The last entry in the Acronis log is "Locking partition C:\"...

I have upgraded to 2 different builds and am now running TI Echo Server 8398... The issue remains. I have fixed issues with "unable to read from sector...blah blah " by doing a volume verification on a RAID array. This issue however gives me no errors.

Acronis support asked me to remove "snapman 380" entries from the registry (caused more problems) and also send me a "snapapisetup.msi" (no dice there either).

I found a fix on a 3rd party forum that worked for me for 5 days. The fix was a registry change. It was as follows:

------------------

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\snapman\Parameters registry key;
- Add Parameters key if it does not exist yet;
- Add new DWORD Value;
- Set the new item's name to MaxSplitBlock and its value equal to 100 (decimal);
- reboot the server

---------------------
I thought it was fixed as I was able to run several successful backups after making this change, however after 5 days the problem reappeared.

I'm wondering if this has anything to do with the issues labeled "sector 63" issues.

The problems (according to Acronis support) lie in their volume spanshot portion of the software.

I hope a permanent fix is comming soon as my customer would have already asked for a different product if it wasn't for one server working flawlessly.

James Lindsay
Computers Unlimited
james@cupcs.com

And just in case this would possibly fix some of the other user's issues... (Failed to read from sector errors.. [from the source disks in a RAID array])

IF you are running a RAID array. (ie: Intel ICH9, ICH10) :

1. Install the Intel Storage Matrix manger (or the software that would be the equivalent for your system... (it would depend on the make and model of your RAID controller)

2. Run a RAID Volume Verification (takes several hours, but syncs the data across the RAID volume)

3. Try the Acronis backup again

This has fixed several systems of mine with the "Failed to read from sector..." issues involving Acronis trying to read from the source disks in a RAID array.

James Lindsay

Hi James. Your post points out a problem with my initial thread. I wasn't specfic enough. If you stand back and read Article 1514 it is something like "Try this. If that didn't fix it try this. If that didn't fix it try this. On and on...". I think they tried to address too many different "Sector 63" issues in one article and at best it is very difficult to understand.

The specfic Sector 63 error I was refering to was "Unable to read from sector 63 of disk X" where X is a external USB hard drive and is the destination of the backup. The error occurs during partition analysis and the very start of the backup. I started out listening to support about the chkdsk and snap drivers and probably sent back more good USB drives they I want to count. I also hit disaster messing with the Snap380 drivers as you mentioned above.

I have found through trial and error that Ilya seems to have defined this particular error and the fix quite well. Replacing trueimage.exe does truely seem to fix this particular sector 63 error. I have about 15 customers running Echo Server and backing up to external USB hard drives. This particular error has occured on all of them at one time or another for no apparent reason. It seems to be the most common sector 63 error.

I have yet to experience any other flavors of the sector 63 error and Lord forbid I ever do :) I don't need any other problem keeping Acronis running right :)

Ah.

OK, I was referring to an issue reading from sectors of the source disks. (The RAID volume verification has fixed many of these for me...)

I would like to try this fix for an issue I'm having. Although there is no error reported, the symptoms are the same.

When you say "replace trueimage.exe" ... What would I be replacing it with?

Thanks in advance.

I also noticed that Ilya said to replace the "truimageservice.exe" ... (not the trueimage.exe)

I just want to make sure I understand the solution before I test it, as this is a production environment that I am working with.

And to be very specific about my issue, I am experiancing an unexpected reboot durring the "Locking partition c:\..." portion of the backup. The system (win2K8 x64 SP2 RAID 5) just reboots suddenly after the start of the backup process and shows no errors in the windows logs / acronis logs before this sudden reboot.

Thanks again.

It is confusing isn't it? You download the files from the links built in to article 1514. If you cross your eyes and read article 1514: http://forum.acronis.com/content/1514

It is like a matrix and what you replace depends on where in the backup the error happens. In my case the error happens during partition analysis so all I really should have replaced is trueimage.exe but to be on the safe side (since Acronis didn't sound too sure of themselves) I replaced trueimageservice.exe too. Very transparent. No reboot required. I have done it on 8 W2K3 servers to date without incident.

I didn't notice it but you are correct. Ilya said to replace trueimageservice.exe but if you look at that article (Echo Server on the right, Partition Analysis on the top) it says to replace just trueimage.exe :) I guess that is why I replaced both of them :)

Thanks again for your reply, you seem to know a bit more about Acronis issues than the support tech I've been talking to.

Where would I find these *.exe files on a Win2K8 x64 box?

Second question: Where would I get the new .exe files for the replacment?

Oh are you opening up a can of worms! The only thing I have running on W2K8 is B&R10 and you don't even want to go there! This is where they reside on W2K3 servers:

\Program Files\Common Files\Acronis\TrueImage\trueimageservice.exe and
\Program Files\Acronis\TrueImageEchoServer\TrueImage.exe

It should be pretty much the same on W2K8. I believe when you download the files from Article 1514 they have instructions as to where the ones that need to be replaced are. Once again the links to download the files are included in article 1514.

http://forum.acronis.com/content/1514

As far as knowing more then most of the Acronis Tech... It was not by choice or by learning from them. I have been given more misinformation from them then I really want to think about. It was a matter of survival and trying to keep my customers happy :)

Ah !

I had to open up the chart posted on KB1514. The explinations were there along with the download links.

I have implemented this and I will test today after 5PM CST.

Thanks again for the explinations. I will let you know if this resolves my issue. Since my issue is a very consistant issue, I will know right away if it works and if it may help others experiancing my issue.

I will post with my results.

Sigh...

Well this didn't resolve my issue. This particular system reboots unexpectedly trying to backup to an external USB drive. I tried all the steps in the KB 1514 as well as some sent to me by a support tech from Acronis.

Thanks, I will keep searching on this one. I have been working on this one for so long that I wanted to try this solution because some of the environment variables matched.

I'm taking shots in the dark at this point. But again, thanks for you help.

James

I had a "Failed to read sector 63 of the hard disk 3. I found out this was caused by not having my multiple usb connector not electrically plugged in. Once I plug it in I was able to get an image ok. BUT, now I cannot get rid of the box that automatically comes up when you turn on the Acronis Software True Image Home 2009.

Too bad James. Sorry it didn't help. All you can do in a situation like yours is take shots in the dark. I have been moving my customers over to Acronis slowly. Before Acronis I was using Symantec Backup Exec 11d. It sticks in my head that I have had that happen with Backup Exec on occassion. It would reboot the computer somewhere during the backup process. It was quit some time ago but if memory serves me it has something to do with the snapshot providor. Backup Exec let you pick from three different ones. Something else to take a shot at :)

Acronis is saying that they believe it has something to do with the Aconis snapshot service... I will keep digging.

Thanks for all your help, Jim

James

OK, I have made some changes. I added the following registry change and switched from using a local admin account to the domain admin account to do the backup and I have several successful backups ! I may be in business ! Finally...

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\snapman\Parameters registry key;
- Add Parameters key if it does not exist yet;
- Add new DWORD Value;
- Set the new item's name to MaxSplitBlock and its value equal to 100 (decimal);
- reboot the server

-change credintials from localmachine\administrator to domain\administrator

Success for now! Lets see if it sticks.

I spoke too soon. On the 6th attempt at making an incremental addition to the backup the server rebooted.

I am giving up on TI Echo for this server. I am going to move to the next version. Sigh...

That is interesting they mentioned the snapshot service. Same issue I had with BackupExec. Good luck with BR10. It is problematic as you can see looking through these threads. I went from Echo Server to BR10 on my SBS 2008 Server. You can't go back once you do it. Other then the messed up file naming convention I have had no problem with it... and boy am I keeping my fingers crossed...

Thanks to all of you who are contributing to this thread. It appears that, finally, enough of us are angry enough at Acronis' lackidasiacal "support" and "product quality" they MIGHT start getting the message.

I have roughly 100 computers (at client sites, as well as my own) running Acronis products. Without a doubt, I spend much more time on this product and its' flaws than on any other product in the world. Now, I know I['m a mere novice, with only 53 years' experience in the computer industry, but it's apparent that Acronis HAS NO RESPECT FOR ITS' CUSTOMERS. Support is a joke, and talking with real people at Burlington just elicits reams of platitudes and "corporate speak."

Contrast that with the fact that we all WANT Acronis to succeed. But this industry is littered with the corpses of non-responsive corporations who made "almost good" products with inconsiderate support and inept QA.

I've also been a management consultant in my day, and it's easy to diagnose the root problem at Acronis: It's a focus on THEIR world view, unaffected by customers'. As I've said, more than once, "Whare are the CUSTOMER'S yachts?"
You other customers and I have done a great job of identifying the problem (which I had just this morning with yet another client, using Echo Build 8398). It is clearly due to an "external USB drive" problem, no matter what the message says. (I have all my computers in our offices making local backups to a separate partition, then I use a post-command to copy that image backup to a common server over the network...it has never exhibited this problem.)

It appears that ATI scans all drives and partitions before it starts...even drives and partitions it will NOT be reading from to make an image. And, that is where the problem occurs. That "pre-scan" should be limited to the drives that will actually be used in the process.

It appears that the problem occurs when we've CHANGED the external USB drive for the copy of the backup. Apparently, Acronis doesn't understand that external drives are external because we want to CHANGE the drives periodically, so we can store one or more of those drives at an off-site locations.

It does NOT have to do with MBR, in my experience: These are all working systems with valid MBR on all drives, typically under Windows XP and/or various Windows servers at or after V2000.

I believe the flaw lies in Acronis' faulty recognition of drives by their SID/GUID codes, which it stores, and when one of those changes, the software failes with the "can't read sector 63" problem. Look at the XML for a script to see what I mean. The proof is in the fact that if you replace a hard drive you must completely reconstitute the script, or you get fatal errors.

In other words, it's a "binding time" issue: The identities of drives are "bound" to variables at the time the script is created, NOT at the time the task starts. You can, in programming, bind the variable "DaysInWeek" to 7; you cannot safely bind the variable "DrivesInstalled" when a task is created; it should, in fact, be bound at the time the image task is commenced (to account for removable drives).

Finally, I am not sanguine about Acronis products for the future:
1. ATI Workstation is being discontinued; I see no intent on Acronis' part to FINALLY fix these problems. Besides, they'd rather force us to buy the new ABR.
2. ATI B&R has the same fundamental flaws as ATI Workstation, but it adds a poorly thought out user interface with novel jargon that confuses everyone. They're following the same path as Veritas BackUp Exec, trying to add features with an excessively complicated GUI...without adding any value.

I, for one, an evaluating several other products to see if I can find a company with products that are reliable and management that gives a damn about customers' experience.

--Carol Anne

Very well put Carol. It is kind of funny. I started moving my customers off of Symantec Backup Exec and over to Acronis because I was sick and tired of BE services not restarting when the server rebooted, sick and tired of error codes not pointing to anything, sick and tired of installation and removal problems and sick and tired of no support. Moving to Acronis wound up being a true case of "jumping out of the frying pan and in to the fire".

The sad part about it is that Acronis didn't start out that way. TI was pretty rock solid and as a rule support was too. Acronis "Pulled a Symantec". The really frustrating part about this Sector 63 error is that it isn't consistent. All my customers swap out external USB hard drives. Things will run great for months then the Sector 63 error will rear its ugly head. Then it will go away for months. No real rhyme or reason to it.

I am still inclined to agree with you. I don't think Acronis really has a firm grip on the problem yet even though Article 1514 was first written back in December of 2005. Replacing trueimage.exe seemed to make the problem disappear more than any other suggestion from support but as I said it will go away for months and then come back with a vengeance so any day I don't get a sector 63 error is a good day :) Have you tried replacing tureimage.exe with any luck?

Thanks for the compliments, Jim. You and I seem to have had similar experiences, which Acronis should be carefully considering. Sometimes, customers have VASTLY more experience than the developers of software products; one ignores their experience at one's own peril.

Yes, I've tried all of the "Article 1514" solutions which seem to work...then fail later. It is impossible for me to conclude the fixes actually repair anything; they appear to fix the problem, but offer absolutely no long-term assurance that the problem is permanently solved. I'm about to try the registry "tweak" described by James Lindsay, above (and, if Mr. Lindsay is reading, I'm utterly impressed that he's found such an obscure solution). I hope that works.

One source of future failures appears to be Windows updates from Microsoft. Because the Acronis codestream lacks "resilience" (and may, for instance, not fully comply with Microsoft's APIs), I find that many errors are detected within the first few ATI executions following an update.

P.S. (for Acronis): Patches don't improve products, especially in the helter-skelter way they're provided on this website. Like "Testing," which only proves the EXISTANCE of bugs, not their ABSENCE, patches are an implicit admission of poor programming and design in the first place.

More WEIRDNESS to report:

Build 8398 apparently uses an obsolete version of SnapMan.sys. See http://forum.acronis.com/forum/7573 for details

James Lindsay's clever fix appears to work for me, but I wondered how it works (and I'm really curious, James, how you figured this one out!).

Here's my guess, from an inadvertant test I conducted:

I set up the registry key and value, but forgot to change it from 0. ATIW then reported "Sector 63" errors on Drive 0, then Drive 1, and so on.

When I changed that value to the specified "100" the problem went away.

My GUESS is that this specifies the lowest drive number to inspect (with a default of "1"?) foir the "missing MBR" issue, so drive numbers under the value for MaxSplitBlocks will never get checked.

Does anyone have a better explanation for WHY this registry patch works?

That Reg edit came from a 3rd party forum and I also got it from Acronis support. The problem I am running into is that the patch works, but only for a limited amount of time. My issue is that the server runs a backup and several incremental additions to the main backup, then the problems resurfaces and the server reboots unexpectedly durring the backup process. It is ALWAYS durring the step where the log entry says "locking partition x:\..."

I haven't reached a permanent solution as of yet.

James

Well I am blury eyed! I went back and looked at registry entries just FYI:

Echo Server Build 8353 on SBS 2008 (X64): No reference to snapman. Just snapman380. This was a clean install. Don't say this too loud but it is one of the few installations that just ran like a champ. James are you really seeing references to snapman and snapman380 in the registry under services?

Echo Workstation Build 8398 in XP Professional W/SP3: Another clean install and still no reference to snapman. Just snapman380.

Echo Server Build 8398 in 2003 Server: Another clean install and still no reference to snapman. Just snapman380.

I know it was snapman before it was snapman280. No doubt in my mind. I forget which build they came out with 380 but it was a while ago. It might be that if you have both you have one too many :)

I have spent time cleaning out registry entries, files and folders too trying to get rid of Acronis in hopes a fresh install would solve issues. Just the other day I came across the "Acronis Removal Tool". It seemed to work. I hate to keep saying "Acronis pulled a Symantec" but the removal tool is one more example. It doesn't un-install clean so they finally had to write a tool to do it :) You might give it a try and do one last (ya right) clean install to see what you end up with in the way of snapshot providers.

Hi Jim... Thanks for reporting your research.

Upon further inspection, I was able to FULLY purge the registry and files from a build 8245 and install ATIWe 8398 on a Windows XP SP3. The reporting of two Services was wrong, and an artifact of my own early efforts; the reinstall--like yours--now refers only to snapman380 (probably identical to snman380.sys in Article 1514).

I agree on uninstalling Acronis products. I have four levels:
1. Regular Uninstall, run under auspices of Revo Uninstaller
2. Phase 2 of Revo Uninstaller, which cleans up much stuff Acronis leaves
behind
3. (after a reboot), the Acronis Uninstall script download; it picks up a few
more files and registry entries.
4. A manual search on many keywords (*) to find other lingering stuff
Acronis STILL left behind.

(*) Responsible, professional programmers use a common naming convention, for example using ATI )for Acronis TrueImage (**) as the first letters in filenames and registry keys. The current naming chaos is a serious PITA.

(**) Responsible programmers and marketing folks using a consistent spelling of product names; I never know with Acronis to search for "trueimage" or "true image".

Finally, isn't it appalling to you, dear reader, that we busy profesionals, Acronis' ardent customers, are having to do all this spelunking and sustaining a dialog to try to understand how Acronis' products break, so we can work around 'em? Where're Acronis' qualifified technologists to engage with us, here, now, about the product THEY SOLD US?

Hello all,

I'd like to inform you that our developers almost completed the new modules for build #8398 and we'll update article 1514 with a new download links them very soon.

I'll keep you posted.

Thank you.

Thanks, Ilya.

We're all waiting to test what we all hope will be the final and definitive fix.

I can't speak for others, but all these problems appear to be related to changing external, USB-connected drives. I can now say conclusively, that once ATIW is working, it works fine...so long as we never change the external drive.

The issue is not unplugging and replugging the same drive, but rather, unplugging Drive A, then plugging in Drive B. At that point, the next backup (usually) throws the dreaded "Sector 63" error. If I reboot the system, or reconstruct the ATI task, the problem never appears again...until we swap drives the next time.

But, of course, my clients need to change those drives (e.g., once a week), so they always have one or more off-site backups in case the building burns down or the computer goes up in flames.

Ilya wrote:

Hello all,

I'd like to inform you that our developers almost completed the new modules for build #8398 and we'll update article 1514 with a new download links them very soon.

I'll keep you posted.

Thank you.

Hi Ilya. Where do we stand on the updates? Carol by Acronis's own admission I have been told the Echo Series just doesn't handle USB devices well at all weather it is hard drives, flash drivers, whatever. I agree when it works it works flawlessly and the only issue is switching usb hard drives. That is the only time I encounter problems too. I hope this is the "final fix" and that it works. I have no intention of moving to B&R 10 until they have ALL the bugs worked out. I hope I live that long :)

I am still waiting...

I am stil waiting for these promised updates. In the meantime, my clients are suffering because of this long-standing, unfixed bug.

I have now conclusively proved, as documented below, that ATI Workstation Echo v9.7.8398 DOES NOT PROPERLY RECOGNIZE USB DRIVES,  We frequently make backups to USB drives, so we can take them off-site for safe storage.  The problem with ATIWe is shown in the three attachments.

1. I plugged in an external USB drive to a working Windows XP Pro computer with ATIWe installed.
2. I used Explorer to show all drives on the system (attached as ATI Disks 1.jpg).  You can see that the N: drive is properly recognized.  I can confirm that the disk can be written to and read from with simple commands.
3. I then launched ATIWe, and navigated to Edit the existing Task.  At the "Partitions Selection" dialog box, notice that "Disk 2" is represented with a Volume name of "None", and the entry under "Type" shows "FS: None" (but, later on that line, identifies the File System as "NTFS.")  See the attachment ATI Disk 2.jpg.

   ATI products are THE ONLY PRODUCTS in my experience over several years that do not properly recognize the attachment of a newly-plugged-in USB drive!.

4. I then exited ATIWe, rebooted the computer, and repeated the steps above, at #3.  The drive is properly recognized, as shown in the attachment ATI Disk 3.jpg

I have two questions of Acronis' developers:

1. Why does your software (and yours, alone, of thousands of software products) refuse to properly respond to Windows' notifications of a new USB drive being installed?
2. Whey does your software insist on scanning ALL drives, even though they are not involved in the image to be made (note that Disk 2 is NOT selected to be included in the image (We write images to partition X: on Disk 1)?

My problem is a BSOD, SYSTEM HARD LOCK, or Unexpected REBOOT. (Not sector 63 read issue)...

Jim... I only saw snapman380 entries (not snapamn)

But here is a new development for me.

I found a difference in the systems that I am running.

I have 2 systems I'm using to try and identify the issue:
(Both are production systems unfortunatly...)

1. Server 2008 X64 SP2 running Exchange and Acronis TI Echo Server build #8398 -(THE ACRONIS BACKUPS WORK LIKE A CHARM)

2. Server 2008 x64 SP2 running SQL 2008 and Acronis TI Echo Server build #8398 -(THE ACRONIS BACKUPS CAUSE SYSTEMS HARD LOCKS, BSODs, and SUDDEN REBOOTS)

----------------------------------------------------------

When I log into system number one (FUCTIONAL BACKUP) and run an elevated command prompt with the "vssadmin list providers" command it lists only two:

1.
Microsoft Software Shadow Copy provider 1.0
...
..
Version: 1.0.0.7

2.
Acronis VSS HW Provider
...
..
Version: 1.0

---------------------------------------------------------

When I log into system number two (NON-FUCTIONAL BACKUP) and run an elevated command prompt with the "vssadmin list providers" command it lists three:

1.
Microsoft Software Shadow Copy provider 1.0
...
..
Version: 1.0.0.7

2.
Acronis VSS HW Provider
...
..
Version: 1.0

3.
Acronis VSS SW Provider
...
..
Version: 1.0

-----------------------------------------------------

I am also getting numerous VSS errors in the event log when running Microsoft Backups on server number two.

Event ID 22 and Event ID 12292

Maybe the Acronis VSS or SnapAPI is wrong or corrupted on system two?

I hope this helps with a diagnosis.

I am going to remove acronis and its VSS providers from system two to see if that resolves the error in the event log and MS Backup. I will post what I find in the next few days.

James

James: Are these the same two systems you discussed in this thread back on January 5th?

It seems that RAID 5 system was the more problematic back then, as well. Are they the same two systems, and #1 and #2, respectively?

When ATIS presents the "...sector 63" error, what happens if you click the "Ignore All" button?