TIH2012 backing up to attached usb drives

It has been reported elsewhere on the net that the Seagate drives attached via USB 3.0 suffer from timeout/power down problems. This seems to be related to the drives firmware. A suggested workaround is to download from the Seagate support site the SeaTools app.. Install the app and in the drive manger you presumably can disable the sleep timer for the drive. This will now make the drive run 24/7 which some believe to be a problem and is definitely a waste of energy but will end the timeout problem. If you do this I think it possible to use Windows power management features to spin down, idle, and even power down the drive when not in use.

Thank you for the reply.

I have the seatools app (ver 1.2 0.8) on the machine - obtained for another reason - and ran it. That app has a variety of simple and advanced tests it can run on disks, but setting disk operating parameters such as the sleep timer does not seem to be a feature. It does link to the microsoft windows control panel system area. And in the device manager property detail for that usb3 seagate (1Tb) drive, the quick removal policy is active (write cache on drive and in windows is disabled). Is that likely to be a cause? If there is another tool that would enable this device sleep parameter to be disabled on the drive, please advise.

Concerning an HDD sleep timer, note that when I use explorer to display disk contents after the TIH crash, everything appears normal, ie fairly immediate response, no long delays while the device 'wakes' up.

I also have the usb suspend timer disabled on the HP laptop as part of the (windows control panel) power options, advanced settings for any usb device: I did that some time ago on all my machines to prevent windows explorer from detecting a usb device but not displaying it when attached (which seemed to be a fairly common problem). There is a sleep timer option in that advanced settings list, but the details appear to apply to the computer, not the external disk.

Davidk

The Seatool has a variety of tests for disks, but does not appear to include an ability to set disk parameters, eg disabling a sleep timer.

However . . .
Some time ago I was exercised by a problem of usb drives being detected (the OS sounds a tone) but only intermittently being shown in the explorer window. MS advised that a power plan (save on battery/power) can have this effect, and the fix was to disable the usb disk suspend setting in the control panel/power options/advanced settings for usb devices. Which was done on the affected machine some many months ago, and appears to have the effect of not allowing a usb drive to "sleep". Not encouraging, in the context of this 'backup failed' problem, as sleep is apparently already turned off. As part of checking that, I noticed that the usb disk driver properties (control panel/system/device manager) had a policy for quick removal set. I changed that to write caching for better performance (on the thesis that this would make faster and more frequent disk accesses, avoiding any 'sleep' or timeout issues) and a single trial backup of the C drive on that affected laptop to the same attached usb drive (failed 4 previous times in a row) now worked.

This made a bit of sense as I've noticed that TIH really does grab the computer's resources by the throat during a drive backup (even a screen saver works in jerks of about several minutes apart), so it does not seem unreasonable that a long wait between writes could have an impact. The intriguing part is that this has only just begun to happen - as tho the slowly bloating OS has crossed a fault line (from working to broken) somewhere in the backup process.

Davidk

To clarify that prior comment about a threshold in a slowly bloating OS . . .
I also speculate on a backup size threshold that might trigger this - the size of the C: drive has been steadily growing despite a lot of care in putting applications and data on separate logical drives: sometimes the app just won't allow that. Plus, regular cleanups using cclean. Backing up junk is pointless. And thus, before changing the usb driver setting to cache writes, even with the backup options set for max performance, max compression, DVD-size files and a full backup, it calculates then starts, and somewhere about 20% done (say, 6-9gb of a 28Gb total compressed file) TIH began to show that error 'can't find the target drive' when previously it didn't.

Davidk

The seatools app has been updated to version 1.4.0.2. I would download the new version, install it and give it a try.

You state above that you have max compression set on the backup task. That will increase the total time of the backup and could be allowing for the USB drive to enter a sleep state while the TI app is compressing the data.

I've done that - removed old seatools version and installed the latest one.

No substantial difference in the tool facility - a more colourful user interface, but nothing new in terms of disk data. 3 screenshot attachments (I hope this works):
1. seatools 1- the availability of drive info in the menu
2. seatools 2 - the info on the selected drive. This is the one which was being used as the backup target when TIH "lost sight" of it. No indication at all in that list about a sleep timer - enabled or not.
3. seatool 3 - the seatools 'system tools' menu - which links directly to the windows control panel items of the same name.

I haven't attempted to explore the tests menu because they actually test (which often destroys any data) the disk.

The most applicable parameter setting being done for that usb disk still seems to be in the OS itself..

Davidk

David,

I must apologize, the Seatools app is not the right tool for the task at hand. You will need what is called the Dashboard utility for making the power management change. I am providing a link, sorry for the inconvenience.

http://www.seagate.com/support/software/dashboard/

Hi,

I went there, and reviewed 2 youtube tutorials on the dashboard product: installation and manage. the dashboard is really IMHO a 'not as good' backup/restore package as Acronis TIH. Only a small bit of it deals with disk sleep parameters, and the tutorial indicates that while sleep options can be set in minutes, the default is 'never' (sleep). Since I have never knowingly touched it, that is what it should have been. And sleep options set on disk are only available for windows: for MAC it relies on the OS itself. The dashboard tutorial makes it fairly clear that the sleep options are for power saving in much the same way as windows runs it's power plans.

I'm reluctant to load another less capable backup package just to get control of a disk operating parameter which should have been defaulted off anyway. If there was a separate tool which just did that (set operating parameters on disk) - fair enough. Which is really what I expected to find in the Seatools package.

Regarding my TIH setup, I use the max compression high performance options to deliver backup files in 4.7Gb chunks (to enable copying to DVD's if necessary) which will use the least amount of disk space. And I have had to use it to restore - not very often, but enough to make me glad I had it.

In the context of usb drives going to sleep, for comparison, on my main desktop machine also running TIH 2012 I have a logical drive that just stores video camera recorded files (data)(the largest partition on the machine, but not the only one). Currently, 97Gb big, and on a full, max compressed backup it generates 22 DVD-size images. It takes a while to do - once every 3 months - and the target drive is an usb3 2Tb external drive. It's configured in windows for a disk write caching policy, and there's never been a problem with any of the large backups I do using it. So it seems that the
- disabled suspend setting for USB drives in the power management pages and
- the write caching policy setting in disk properties
"overcomes" sleep. or at least, doesn't cause TIH to go bananas

So at the moment I am inclined to leave it and see how the changed settings using a write caching policy for usb drives on the laptop does. The incident that led to this thread was a monthly backup of just the C drive, and in 3 weeks time the next full machine (every partition on it) is scheduled. I might be back here after that, but who knows?

Thanks for the help.

Davidk

I'm back, and still having problems backing up to an external usb3 drive. But there is more information.

Summary
3 computers, 1 desktop and 2 laptops run TIH2012 latest build available. All have external drives (smallest 500Gb, medium 1Tb and largest 2Tb) attached using usb3 connections, and these are the targets for the compressed backup tib files of the primary and logical drives on the main machine. All run Windows 7 home premium sp1 latest MS patches. The desktop and 1 laptop are 32bit machines, and these 2 attach the largest (desktop) and smallest (toshiba laptop) external drives. Every machine now has windows configured to operate a disk cache for all hard drives as a performance issue. The problem laptop is a 64bit HP g6-2002 machine, and it has the medium size external drive attached for backup. It also has the max possible RAM installed (8Gb).

Why am I using external drives for backup?
Basically, to reduce the overall time taken. The disk latency involved in this operation is huge, and with external drives the time taken to do a backup is reduced by half at least.
On the laptops, I also copy the completed backup back to the internal drive (so there's always a copy available 'on board' when out and about), and on all machines saving a copy to a large LAN store.

The Issue, revised.
Consistently (3 tries out 4), the 64bit laptop running TIH2012 fails when partway into a backup cycle for the main C drive. Non-primary partitions don't seem to be affected, but they are a minority of use cases. For example, every month, the primary partition is backed up. Every 3rd month, 3 additional non-primary partitions are included in the backup job, each one as individual tasks. The failures have only affected the primary partition task. AND ONLY ON THE 64bit MACHINE.

The failure mode is extreme: the whole screen nearly whited out, application controls unresponsive, the cntrl-alt-del sequence to get to task manager so jammed up it literally takes minutes to respond, and once appearing, says TIH is not responding but attempts to cancel the task looks dead. Often , I've had to simply remove all power and battery before a cold start to get control back.

In the most recent case, 9Gb (2x4.7Gb files and a 3rd empty file found) compressed out of a final version of 26gb. (final version achieved by 1) deleting the most recent backup from the internal drive to make room, not without some concerns - deleting a backup on a platform with a problematic backup suite isn't casually done - and then and after some effort as explained above, 2) repeating the backup task using the internal HDD.

It seems very obvious that TIH 2012 on windows 7 64bit has a consistent failure with external usb3 drives, whereas it runs sweetly on the windows 7 32bit platform and the same target. What it looks like is that TIH2012 on the 64bit laptop thinks that the target disk drive has been disconnected during the cycle, and won't publish an error and stop, it just goes on waiting . . . . . and waiting . . . . and meanwhile locks up the whole PC. Pretty much like the continuing issue with TIH2105 that's outlined in the release notes.

No other item of software on the laptop does this. For example, windows explorer (often called exploder due to its propensity to blow up in use) copying the completed backup files - 30Gb of them - from the external drive to other internal and external drives runs without fault.

Newer versions?
Been watching that. But local backups is all I am interested in - a cloud-based backup file is useless whenever the network links break, and that's often enough. And I've not seen any details of later versions that address a 64bit version of TIH, nor do the limited (my version and the current one on sale - can't find any release notes for 2013 or 2014) available release notes discuss any fixed problems that specifically relate. There's been no incentive to upgrade. I have noted that TIH 2015 release notes do discuss a continuing issue with a removed disk drive, and I suspect that is similar to the problem I am having. If so, an issue that's unresolved over 3 major version releases is not conducive to an upgrade without some really positive fix statements.

Feedback
Some feedback from Acronis would be appreciated. Such as
1) release notes for all versions published on the webpages, whether the version has been bought or not. These can be supportive to any upgrade decision.
2) Is TIH now also available in a 64bit version?
3) if the answer to 2) is yes, when (which version) did that release occur?

Davidk

David,

You certainly have a confounding issue. I believe though that your issue is not with your external drives but with the laptop machine itself. One thing you said that I make note of is that on your last failed attempt you say that you had to delete a prior backup on the internal drive of the machine in order to make room for the backup task you were attempting to complete. I assume from that that available space on your internal disk in the machine is available space limited to below the 26GB size of the backup unless you delete the previously stored backup on that machine, is that correct?

I am going to make a guess here and it may not be right but given all of the above information I can think of nothing else. First I would encourage you to make certain that you are using the most current version of the 2012 application. Another question I have is have you ever updated the snapapi module of the application? I am thinking that because of the suspected limited available space on the internal disk of your machine this program module which handles the volume snapshot operations of the app might not be able to handle or complete its process because it runs out of space to do so. I am thinking that this is caused by the number of total files that are being created by the backup task you have created. If you have never updated the snapapi module it may be worth a try to do so. I am providing a link below for an updated snapapi file for TI 2012. It is a ZIP file so you will need to unzip it then run the executable to install. Again, this is a guess on my part and you may wish not to do this.

https://kb.acronis.com/system/files/content/2011/09/25370/atih2012_snap…

Hi E,

Nice to talk to you again. Seems I'm always presenting the interesting problems . . . .

Version running .... all the machines have TIH 2012 update 2.1 build 7133 installed. A consistent user interface is really what I was after, jumping between 3 machines for the end-of-month back-up runs. There's nothing more recent on the support page than this. The support page also does not provide little patches and updates like the snapapi item you supplied. More on that below.

Machine HDD capacity . .. the 3 machines have a used (explorer properties) primary partition (c; drive) and compressed tib files as at yesterday, as follows:
desktop 32bit - 41.7Gb, backup files 24Gb max compression (using the 4.7gb DVD file size option)
Toshiba 32bit laptop - 38.9Gb, backup files 17Gb
HP 64bit laptop - 56Gb, backup files 24gb.

Memory capacity
As to memory capacity to manage lots of files - the 32 bit machines have only 4gb RAM, whereas the HP 64bit laptop has 8Gb RAM. One would therefore think it has more than enough memory to work with, especially as the 32bit machines have no problems.

Backup Usage
Rather than get into a description of hard drive usage, I attach 2 screen shot images to tell that story. The Hp laptop has a 360Gb internal drive, which I used DD11 to partition into several smaller logical drives to store various files by function - downloads, applications (programs), data (the data files the programs use) and a scratchpad. The scratchpad is where the backups are stored.

The HP DD11 image attached is of the drive layout as of 3 years ago. The use and sizing has not changed much over that period, altho the content certainly has. The HP Explorer folder image is today's take, showing the backup folders and in particular yesterdays backup files. Altho the scratchpad partition is 100gb large, the steady bloat of windows has meant that whereas 2 years ago, there was enough spare space to store a new backup image before deleting the old one, now there isn't. My 1st solution to that was to use the external HDD to create the new image, then delete old and copy the new one into the scratchpad. But that has not worked - per this thread. So what I am forced to do is make space (delete the prior backup image, and fortunately I have a copy on the external usb drive and on a LAN) and then task a new backup using the local internal hard drive. It takes much longer to complete but it does work. And to make the space, what I am forced to do is delete the C:drive image from the whole of machine backup before storing the new one in the miscellaneous folder: across that whole partition, there's only one backup copy of each folder image.

The consistent part of this problem is the 64bit platform and external usb3 drive. The same TIH code, compressing the same folder source, with an internal SATA drive works fine albeit slowly. The 32bit platforms have not had issues with external usb3 drives. And (since my query about a 64bit version of the application has gone un-commented) in the absence of any self-detecting 64bit code during installation, it's the same code base in each machine. So it seems entirely possible that the 64bit usb3 disk drivers in the 64bit platform are not reacting well with the 32bit code base of TIH 2012. Or possibly TIH2015 - see next para.

That unresolved issue with TIH 2015 (release notes) re error failures with external drive removal during operation is so like what I am seeing that I am making a specific mention of it (for the developers who might see this and think there's a long time bug in there somewhere).

Patches and fixes.
Acronis does not seem to go in for small patches and fixes, and since reading your response I've re-checked the support pages looking for the snapapi item and this build of TIH. It's not there. So, some queries on the snapapi item:
- what it is supposed to do? and is that relevant with 8gb RAM available?
- is it part of the update 2.1 build 7133 that is the latest version release of TIH 2012?

Davidk

Do you have any issues just copying large files from the 64 bit machine to the USB drive?

I have a HP Pavilion that I dual booted the 32bit and 64bit versions of Windows 7. I had no issues with the 32bit version, but the 64 bit version would lock up when transferring large files across USB. I had to request a hotfix from Microsoft to resolve the issue. It was a compatibility issue with Windows 7 x64, Nvidia chipset, and having more than 4GB of memory. I suspect your having a similar issue.

https://support.microsoft.com/en-us/kb/976972

Here is a link to the knowledge base to see if it applies to your system.

Hi joey,

All input gratefully read.

The chipsets
I read the MS Kb at the link you supplied. Not all HP pavillions are the same. As I found out when I was upgrading my RAM about 2 years ago. My g6-2002 pavilion is an AMD A6-4400M chipset unit in the main. No apparent nvidia items in it. The display is a Radeon chipset, and I cannot establish the maker of the usb EHCI bits, but the drivers are supplied by AMD and certified under the MS compatibility program, so I suspect those parts are AMD too. A windows search on key nvidia turns up nothing. It is feasible that the MS OS on my g6 has a bug in it, but it seems more likely that as TIH is only program (see below) I have with the issue that the problem is mainly with it in a 64bit environment interfacing to external usb.

Transferring files.
I guess it depends on what you call "large files". I have TIH configured to create the backup tib files in 4.7gb file sizes - so I can if needed burn a DVD with them. Years ago when I first began to use TIH, 2 or 3 DVD's like this was my off-line backup. Now, I need a LAN, and the 4.7gb filesize is a useful habit which allows me to identify roughly when something went wrong. The (hindsight) results for the most recent failure yesterday is in the post above - 3 files each 4556mb, and one size 0kb. So it's calculated for a bit, then compressed/written 2 sets of files to the external usb drive before blowing up during the 3rd.

When I've generated the C drive backup on the internal HDD, I use explorer to copy it to the external usb drive (to get my off-PC backup file). Basically, block select (click on 1st file, shift key held down and click on last file) to highlight the backup tib images and then copy/paste them to the external drive/folder. 24Gb total over 7 files. I've never had a problem with the windows copy doing this. The duration is about 10 minutes and the green ribbon just rolls across the progress panel.

Davidk

David,

Since you confirm that you are in fact running the latest version of the TI application I think it pointless to install the snapapi file I supplied as I would think the latest version includes it.

Just to clarify somewhat, the snapapi is the snapshot manager that the TI app uses to capture a disk/partition snapshot prior to running a defined backup task. The purpose in this is so that the app can use this snapshot to work from which frees up the machine so that the user can still use the machine while the defined task is in progress. This does not apply when making a backup of the system disk however as that process requires the system be rebooted into a Linux environment from which the task is carried out.

Which brings me to another question, does this issue occur when you are making a system partition image or a data partition image?

Joey brings up a very valid point concerning AMD and Windows, it would behove you to chase that rabbit a bit and see where it leads.

Another thought came to mind on this as well. You should investigate if there might be a firmware update available for your troublesome external USB drive. Had a poster some time back whom had similar issues with a Seagate USB drive and the solution was to apply a firmware update on the USB drive. If you find that there is an update available make certain that if you apply it that it will not cause data loss as some do.

If I can think of anything else I will let you know.

Hi E,

Joey did not mention AMD in his post, and the processor and other support chipsets vary a lot across models of the product.

Firmware. I spent quite a few minutes searching thru the Seagate site looking for support downloads of firmware for the product, which is a 1Tb, usb3, portable expansion drive. The part no searches OK but the details are only of the current version. And no field firmware updates are available for the product range.

Backup process.
Interesting remarks. I mentioned that the whole of computer image was only done every 3 months, and the most recent of those is dated 31 May 15. My process is to do the smaller drives first, leaving the big one for last (the time stamps on the tib files that result confirms this), and the problem only occurs when backing up the C drive or primary partition. In the 31 May backup cycle, there's a large time gap - over an hour - between the other folder images, and the C: drive one I generated after fussing thru this problem. For comparison, the largest logical drive (G) backup (see the DD11 drive map image posted above) on that date was marginally larger than the C drive image and took about 15 minutes to do, based on the tib file time stamps. The C drive image took well over twice that - 40 minutes.

Your comment about booting to linux to do backup of the primary partition is not apparent to the user - on the screen display the windows desktop and application window et al are all still shown until the windows screen saver if enabled kicks in at ultra-slow display speed. I know that the boot recovery disk used for recovering drives from backups at least to start uses a linux boot image, which came to light some years ago when I posted about the difference in drive letters being shown to a user with the recovery disk.

Given that the problem is only evident on the 64bit machine, the evidence still says there is something different about the way the software operates with external usb that makes it seem as tho the drive has disconnected on the 64bit platform which causes the issue, yet does not in a 32bit environment.

Davidk

David,

AMD and Nvidia have always had a close partnership relation so I tend to think they are synonyms with each other even though I know that is not so It is logical that AMD uses nvidia USB EHCI drivers and HP supplied those for your system. I would think that HP could confirm this.

Disregard my comment about reboot during backup, I was incorrect there, not thinking clearly which happens from time to time after one of my unplanned 24Hr. work events.

Has this machine always exhibited this problem you are having or is this something new? Have you run a chkdsk on the C: partition of the drive to check for errors? Something you may wish to consider.

I understand your logic thinking that the problem is with the True Image app however, it would also be logical that if that were the case the problem would have surfaced with other users besides yourself and I do not think that is the case here.

Have you had a look at Windows event viewer to see what if any exceptions might be shown when this problem occurs? That is well worth doing as it can lead to discovery of the underlying problem whether it be an application fault or other.

Keep digging as persistence pays off!

Hi E,
This (current external portable) disk is the second I have used for external storage. The first one died and got buried when DD11 ran chkdsk and turned up a bunch of errors in test 4 or 5 that could not be fixed (from memory). I ran chkdsk on this one before using - no issues. Running chkdsk on this size of drive is non-trivial - takes about 3 hours to do one complete 5-test pass, assuming an NTFS format (which it is). I normally use it for multi-media storage, and since I had it in the bag with the laptop, decided to use some of its capacity as a backup archive for the laptop it was used with. I began using the drive for backups a few months ago, before I first posted in this thread, put up with it for a while and then tried to find out why? The reason - when the windows bloat made space on the internal drive insufficient to create a new backup there without deleting the old one first. I mentioned that earlier. With the issues backing up to the drive I find have to do that anyway.

I've put a query to the Microsoft Answers crew, about whether the KB article linked by Joey might also apply to cases where other non-nvidia ECHI chipsets managing the USB host controller in 64bit windows. It is clear that the issue is a combinational one involving windows 64bit, an external usb drive and TIH. Any of those components in other situations works fine, just together they don't. I don't expect an answer from MS for a day or so.

Chkdsk on C: drive? One would think that any issues there would be manifest in any normal operations, and if there was a sleeper there that butted heads with TIH, then why does it not happen when the backup target was the internal SATA drive?

keeping the shovel shiny . . .

Davidk

Hi David,

So I take it then that the problem exists with the current drive, did not exist with the previous dead drive, is not a problem with an internal drive partition, and I presume id not a problem with other external drives, is that correct? If yes then logically it could be an issue with this particular drive.

Do you have USB 2.0 port on this HP laptop which you could use to run the C: backup? If yes you should try that. If the backup succeeds then I would think that the problem could be possibly driver related or, the issue Joey pointed out.

Errors on disk can exist and not be apparent to the user. Running chkdsk on the C: partition on the disk would take that possibility out of the picture or reveal that an error does exist although I do agree that logically such an error would cause the problem when backing up to your internal disk.

Hopefully you will get some information from Microsoft that will help out.

Hi E,

Several points to address.

1. use of previous HDD. No, I did not use the dead HDD for this function - at the time, the space on the internal drive was more than enough for a C drive backup, and I just used it. It was only when that space became insufficient that I tried using the external drive - which by that time, had become the one now in use. So this current disk is the only one which has exhibited the problem. The previous one may have - but I never used it for backups so don't know.

2. Usb 2.0 port. Yes, I have one - usually for the mouse. Per your suggestion, I've tried connecting the external drive to it and doing a C: drive backup. The TIH app started, got past the calculating phase and then crashed, as before. This time, task manager just did not start, the app eventually closed and then everything on the desktop was dead: even shutdown did not work. To get control back (as reported before) I had to remove the battery to get it shut down, and then start windows normally. Which it does. Once started, the evidence on the disk is the same - 2 files each of 4550820Kb, and a 3rd file of 0Kb.

Whatever the cause of this turns out to be, the way TIH handles the error and crashes the computer is pretty serious: there's a semi-whited out screen and a small panel saying TIH has stopped working, click OK to close the application. Doing that does close the panel, but otherwise there's every indication of a blue screen crash with the TIH desktop as background. This needs some urgent attention by Acronis: if it crashes it should not be doing this.

3. I've heard back from MS - they basically disowned it: saying in part "You need to check with the software manufacturer the cause of the problem and compatible version". I am going to dispute that - MS is the manufacturer of the OS. but I'll keep digging.

4. Running Chkdsk. Doing it now but will take some time. Updates on that later.

Davidk

This post is for Joey . .
On what model of pavilion notebook did you have the issue you gave the weblink for in the thread above?

I understand that you patched your system with this fix - from the look of it, file be file. And that it worked. Would you confirm?

I'm planning to:
1. bounce this to HP for a statement of differences in the EHCI chipsets used for usb transfers between Joey's machine and mine; and then
2. re-quiz microsoft about it.

Davidk

And this one is for Enchantech

I've run chkdsk on the external usb drive (J:) under DD11 and with both the fixit tabs checked. The user interface is much easier to use and understand this way. It took over 3 hours to do the 5-stage test cycle and I screenshotted the result: attached. No issues. The drive checked is the one (disk 2) at the base of the drive images.

Next I tried the same thing on C: drive - with a lot of trepidation. As far as I can tell the operating system on the notebook runs fine. Because of that I left the fixit tabs unchecked for this run - just report the unexpected, don't change anything. And it aborted in stage 2 with several file index errors. Most (but not all) of the files with errors listed looked like part of the AVG security suite. Indexing to me means that the file size in the NTFS sysfile matches what the file data actually says (the number of sectors to store the file matches the file size in the name data), but maybe I'm wrong. Sometimes security files fuzz that as an anti-hacking measure. An explanation of file indexing and how Chkdsk uses it would be useful.

But we seem to be drifting off the topic. Everything on this problem turns into a puzzle. In this case - I can use TIH to backup the C drive to an internal SATA interface drive, but not to an external USB3 interface unit. The AVG security suite runs every time I have the notebook on, including updates, scheduled scans on every disk drive including the external one, etc. And there's never been a problem reported or apparent. Other demanding apps like Corel Video Studio (there are 3 versions installed on the notebook - X6 (32bit), X7 and X8 both 64bit) and all of them work fine on the machine several times a week, including using the usb3 external drive, primarily to read from, but occasionally to render files to. The only app that's giving consistent erroneous results in normal tasking once a month is TIH, and thus my focus on it.

Davidk

Hello David,

Although you did not provide details of the chkdsk error you obtained other than the fact that it was an indexing error, I did some searching and found the Microsoft kb article below that may interest you. You can determine if it applies to your situation or not.

https://support.microsoft.com/en-us/kb/976329

I would advise running chkdsk /v c: which can be used to clean up old index entries that no longer apply to your system any longer. You can also use the /i switch with chkdsk so that chkdsk does not scrutinize such files as heavily.

David,

It was an HP pavilion a6403 desktop pc. The hotfix resolved the USB issues on my system. I have used True Image 11, 2010, 2013, and 2014(all 32 bit programs) on this system with Windows 7 x64 and had no issues backing up to USB 2.0 and 3.0 disks. For all the love Windows 7 gets, I have to say I haven't had a single driver compatibility issue with Windows 8/8.1.

Have you tried performing an uninstall and reinstall of True Image 2012? You may also want to check out the optional Windows 7 updates and look into the issues they resolve.

Macrium Reflect provides both the 32 and 64 bit versions of their program. You could try installing the 32bit version of their free program and test performing a backup with it to the USB drive. If it crashes in the same way as True Image the odds are you have a hardware compatibility issue with Windows 7 x64.

Thanks to you both. I've posted a query to HP to establish whether two models in the same "family" use the same EHCI usb parts. Designers often do - it's easier that way.

As to kb976329 mentioned by E, the article states that it was included in service pack 1 for Windows 7, and that was long since applied to all the machines including the HP notebook. So, evidently not relevant to this problem.

I also searched the microsoft knowledgebase about chkdsk functions and switches. Two documents came to light which were lengthy but readable: kb187941 which dealt with the /C and /i switches, and a word document at www.microsoft.com/.../docs/Windows 2000 CHKDSK Management.doc which describes in some detail how chkdsk runs and includes command line switches that can be used and their effect.

I note that the description of indexing is what I understood it to be - a check that all the file entries in the ntfs management table exist in the folder, and that files present in the folder have entries in the management table. It discusses what is done either case but not the other is true. Somewhat disturbing tho is the clear statement that run in auto mode chkdsk can generate phantom errors because it does not lock the folder in that mode - and thus files in use can change during the check, generating the errors. Which seems to be what happened to me - I ran it auto mode because I wanted to know the state before anything was changed , and here's MS saying that any errors reported in that mode are probably erroneous. One does wonder why it exists in that state.

Which leaves me in a quandary. The notebook is used as a teaching platform for video editing. The only problem I have with the machine is this TIH backup to external usb drive failure. The TIH backup mode I use is the partition mode - which as I understand it just copies compresses and saves whatever is contained by the sectors/cluster of the disk. The contents of those clusters - good or bad - should not be a issue for the backup itself. If I run chkdsk on its C drive in fixit mode, the changes it makes may completely screw it up. The machine came with the OS and related software like webcam drivers etc installed, so the only re-install mechanism I have is a TIH 2012 backup 1) of the base installation as at July 2012, and updating that would be a massive pain with no guarantee the problem will be fixed; or 2) most recently a week ago with all the updates and patches applied, which will have the same issue it presently does.

Davidk