Answered by:
Connection marked dead by transport - automatic backup fails

Question
-
What could cause this?
All scheduled nightly backups are failing. I had one successful manual backup of the entire machine, and then did the following:
Attempted a Win7 upgrade
Upgrade failed, so I rolled back to Vista (successfully).
allowed automatic backup to run that night, but it failed
uninstalled the WHS client, and reinstalled
allowed automatic backup to run the next night, but it and all subsequent backups have failed the same way.
Backup duration is 0 seconds. Failure details are simply "The network connection between the computer and server was lost. Connection marked dead by transport".
Now what? How do I troubleshoot this?
thanks,
KenSaturday, January 31, 2009 3:10 AM
Answers
-
Finally, success....
I tried Olaf's suggestion about trying Windows backup as well, and it too failed. The error message was:
File backup failed. The error is: The backup cannot finish because another program is accessing temporary files used by the backup process. Stop or close any anti-virus programs, and then try the backup again. (0x810000F3[0xC00000EA]).
I use CA Etrust antivirus, and have never had it interfere with a backup before, so discounted this as a possibility but I did have a concern about remaining corruption in the filesystem. I decided to run chkdsk again (once from within windows, and then after that at boot time with the /B option). The first run, from a windows cmd prompt, had these unique entries in the event log:
Cleaning up 6966 unused index entries from index $SII of file 0x9.
Cleaning up 6966 unused index entries from index $SDH of file 0x9.
Cleaning up 6966 unused security descriptors.
The second run, at boot time as chkdsk /B, appeared to remove two clusters from the bad cluster map, but there's no record of the run.
After reboot, I let WHS backup run as normal, and it completed successfully. It appears that several runs of chkdsk were necessary to clean this up.- Marked as answer by Ken Kiesow - MSFT Monday, February 9, 2009 5:32 PM
Monday, February 9, 2009 5:32 PM
All replies
-
Ken Kiesow - MSFT said:
What could cause this?
All scheduled nightly backups are failing. I had one successful manual backup of the entire machine, and then did the following:
Attempted a Win7 upgrade
Upgrade failed, so I rolled back to Vista (successfully).
allowed automatic backup to run that night, but it failed
uninstalled the WHS client, and reinstalled
allowed automatic backup to run the next night, but it and all subsequent backups have failed the same way.
Backup duration is 0 seconds. Failure details are simply "The network connection between the computer and server was lost. Connection marked dead by transport".
Now what? How do I troubleshoot this?
thanks,
Ken
Hi Ken,
Please submit a bug for this. We will need client and server CABs in order to troubleshoot.
Thank you
Lara Jones [MSFT] | Program Manager
Community Support and Beta | Windows Home Server Team
Windows Home Server Team Blog
Connect Windows Home Server
Windows Home Server- Proposed as answer by kariya21Moderator Friday, February 6, 2009 12:36 AM
Saturday, January 31, 2009 3:27 AMModerator -
bug report has been filed. The server cab was uploaded, but the on the client, talq.exe reported a failure to upload the watson report. The talq.zip file for the client was added to the bug report as an attachment. This is bug ID 409244.Saturday, January 31, 2009 5:06 AM
-
Hi Ken,
what happens, if you attempt a manual backup?
Please check also the client event log for any errors around the failed backup - maybe those can give a better hint what happened.
Best greetings from Germany
OlafSaturday, January 31, 2009 3:34 PMModerator -
Thanks Olaf.
Manual backup fails after some percentage, usually between 13 and 20%.
This error appears in the event log on the client:
Backup set 8 on KSWHS failed: System.Runtime.InteropServices.COMException (0x8007045D): The request could not be performed because of an I/O device error. (Exception from HRESULT: 0x8007045D)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.HomeServer.Common.Client.Win32.ThrowLastError()
at Microsoft.HomeServer.Backup.NTFS.VolumeBuffer.EndRead()
at Microsoft.HomeServer.Backup.NTFS.ClusterRangeReader.Next()
at Microsoft.HomeServer.Backup.BackupOp.BackupOperation.DoClusterPass2()
at Microsoft.HomeServer.Backup.BackupOp.BackupOperation.RunWithoutCatch()
at Microsoft.HomeServer.Backup.BackupOp.BackupOperation.Run()
at Microsoft.HomeServer.Backup.BackupOp.BackupSetOperation.RunWithoutCatch()
at Microsoft.HomeServer.Backup.BackupOp.BackupSetOperation.Run()
Saturday, January 31, 2009 4:12 PM -
Hi Ken,
could you run chkdsk /f /r in a command prompt started as Administrator for the volume, on which the backup fails? Seems to me like some file system corruption or damaged sectors on the disk.
Best greetings from Germany
OlafSaturday, January 31, 2009 6:20 PMModerator -
alright, running. it'll be some hours before that's done. I'll report back later.Saturday, January 31, 2009 9:11 PM
-
Ken,
If Olaf's suggestion doesn't clear it, (chdsk cures 99% of Client problems), then the following might help:
On the Client, open computer properties | Advanced system settings | System protection tab.
Uncheck your drive (and others if you have more than one), then Apply. (This will disable and remove any Restore Points).
Re-enable the drive(s), then Apply again. The 0x8007045D error has been associated with corruption in a Restore Point, amongst other things.
Good luck,
Colin
If anyone answers your query successfully, please mark it as 'Helpful', to guide other users.Saturday, January 31, 2009 9:35 PMModerator -
chkdsk did not fix the issue. If volume restore was somehow involved in my Win7 rollback, I could see that being related. I'll try that later when I get home.Monday, February 2, 2009 9:32 PM
-
I turned off the restore points functionality for all the drives, and applied the changes. I then re-enabled the functionality. The backups are still failing the same way, unfortunately.Friday, February 6, 2009 5:34 AM
-
Hi Ken,
did you try also a backup while the system restore functionality was disabled?
Does your client have multiple drives?
If so, also any USB drives? Try to detach those first before performing a backup.
If this does not help, try to exclude the first volume from backup via console and check, if backup completes for other volumes.
In another context I have read also, that a running SQL server on the client may cause error 0x8007045D.
Best greetings from Germany
OlafFriday, February 6, 2009 8:46 AMModerator -
ok, some new results.
There are main internal drive volumes attached to this system, plus one external USB drive. The boot volume is C, and other internal volume is G.
Backup attempt with no volume restore active:
Attempt C and G, USB drive disconnected: failure
Backup attempt with no volume restore active:
Drive G only, USB drive disconnected: success
Backup attempt with no volume restore active:
Drive C only, USB drive disconnected: failure
I have not attempted backing up only the USB drive, it's not relevant in this case as it's been excluded from backups all along.
Only backups from drive C are failing in this test. I've run a thorough chkdsk /f /r at reboot, and there are no errors being shown.Saturday, February 7, 2009 8:43 PM -
Hi Ken,
how did you do the rollback to Vista? Restored from WHS Backup?
Or performed a fresh install?
Did you leave the volume or did you recreate it?
Is there more software on the system than before?
Chkdsk did not log any errors in the event log?
Best greetings from Germany
OlafSaturday, February 7, 2009 11:41 PMModerator -
The rollback was performed by Win7 setup, when the upgrade failed. I don't know exactly what Win7 setup does to restore the prior installation, but I know that the volume itself is intact throughout the process. I believe that it mainly restoring the prior directory structure and file locations, but I don't know what occurs with the MFT or other areas of the disk.
There isn't any more than before. This volume is approximately 298gb, of which around 112gb is free.
Chkdsk did not report any errors in the event log.Sunday, February 8, 2009 1:01 AM -
I wonder if perhaps excessive fragmentation in the MFT could cause this? Or a permissions error (perhaps the Win7 install modified ACL's and didn't fully restore everthing properly?)Sunday, February 8, 2009 1:05 AM
-
Hi Ken,
in this case it might be interesting, what caused Windows 7 Setup to initiate the rollback. Maybe its the same reason which now causes WHS backup to fail. Assuming you have Vista Ultimate - does the integrated Backup still work for you or would it fail as well?
I don't know, if a fragmented MFT can be a reason for the failure. If there would be a permissions error, you usually should see some related warnings in the event log as well.
Could the WHS team analyse your CABs already?
Best greetings from Germany
OlafSunday, February 8, 2009 12:23 PMModerator -
The Win7 upgrade issue was caused by a bug in Win7 setup that has since been fixed, and so that's unrelated.
Unfortunately, I haven't heard back from the WHS team yet.Sunday, February 8, 2009 10:18 PM -
Finally, success....
I tried Olaf's suggestion about trying Windows backup as well, and it too failed. The error message was:
File backup failed. The error is: The backup cannot finish because another program is accessing temporary files used by the backup process. Stop or close any anti-virus programs, and then try the backup again. (0x810000F3[0xC00000EA]).
I use CA Etrust antivirus, and have never had it interfere with a backup before, so discounted this as a possibility but I did have a concern about remaining corruption in the filesystem. I decided to run chkdsk again (once from within windows, and then after that at boot time with the /B option). The first run, from a windows cmd prompt, had these unique entries in the event log:
Cleaning up 6966 unused index entries from index $SII of file 0x9.
Cleaning up 6966 unused index entries from index $SDH of file 0x9.
Cleaning up 6966 unused security descriptors.
The second run, at boot time as chkdsk /B, appeared to remove two clusters from the bad cluster map, but there's no record of the run.
After reboot, I let WHS backup run as normal, and it completed successfully. It appears that several runs of chkdsk were necessary to clean this up.- Marked as answer by Ken Kiesow - MSFT Monday, February 9, 2009 5:32 PM
Monday, February 9, 2009 5:32 PM -
Also, I want to thank everyone that responded to this for keeping me thinking about the issue and trying new things. I appreciate all the help, particularly that of Olaf Engelke. Your MVP role is well earned.
thanks again,
Ken- Proposed as answer by John Zielke Tuesday, February 9, 2010 1:12 PM
Monday, February 9, 2009 5:46 PM -
The problem I found is large files - If you have files over 1 gig it can make backups fail. I had many ISO and zip files that I moved to a new directory and then told backup to exclude the directory. Everything started to backup correctly. You can move the files back to test which one/ones break it but I think it is the size of a file or the combined size of a bunch of files. I never got to the point of moving files back as those files are replacable and will take alot of space if backed up. Maybe shadow copy has an issue with file sizes.
Hope that helps.
-JohnTuesday, February 9, 2010 1:17 PM -
I backup my Vitual Machine Disks using Windows Home Server. It handles files well over 20GB each on a nightly basis without problem. If you are experiencing a problem with large files then it may be highlighting a problem somewhere else.
--Tuesday, February 9, 2010 1:58 PM -
It handles large files in different direcories if that is the only large file in it but if it contains many large files in the same directory it seems to fail. I too have large VMware files and those backup fine. Do you have many large files in the same directory? Easy to test, duplicate one of the vmdk files and see it there is an issue. I will see what happens.Tuesday, February 9, 2010 2:58 PM
-
I just did and it backed up fine. I've never come across this problem before and I doubt there actually is a bug with Windows Home Server and backing up large files - the act of backing up large files is most likely exposing a weakness with your system. I wonder if you have RealTek network cards - seems to be a thing about them recently.
--Tuesday, February 9, 2010 4:41 PM -
Not sure if you solved this but I just did solve it for me. I got error, "File backup failed. The error is: The backup cannot finish because another program is accessing temporary files used by the backup process. Stop or close any anti-virus programs, and then try the backup again. (0x810000F3[0xC00000EA])." While doing backup. I am running Disk Keeper, " Build: (14.0.903.0)
Diskeeper® for Windows®
Copyright© 2010 Diskeeper Corporation
www.diskeeper.com"And had to exclude my backup drive from auto-defragement and that fixed it. I guess Microsoft Backup does not like it when the backup drive to be messed with while it is writing to it. I hope this helps. -gk
- Proposed as answer by Coastiegreen Monday, June 21, 2010 4:33 PM
- Unproposed as answer by Ken WarrenModerator Monday, June 21, 2010 4:38 PM
Monday, June 21, 2010 4:30 PM