locked
Backup fails on 64-bit Vista client RRS feed

  • Question

  • When running the backup feature (manual or scheduled) on a Vista 64 bit client, the backup Stutus indicator stops at 24 % with the following error message: "The backup failed because of a problem with Windows Home Server software. The eventlog on the server contains more details." On the server, the backup Details reports: "Failure for Volum (Local Disk): An unexpected error occured on the server when calling an API. ViritualAlloc 8". Running chkdsk /r has not solved the issue. Backup is completing sucsessfully on 3 32-bits Vista clients on the network. I have so far not been able to complete a single bakup of the 64-bit client.

     

    The issues has been reported on connect (ID 351170) along with logs from server and client. Strangely, the Status has been set to Resolved (Fixed), without any workaround has been posted..?

     

    Any bright ideas, please?

    Sunday, June 22, 2008 12:58 PM

Answers

  •  WITno wrote:

     

    The issues has been reported on connect (ID 351170) along with logs from server and client. Strangely, the Status has been set to Resolved (Fixed), without any workaround has been posted..?

     

    Any bright ideas, please?

     

    The Connect triage team has updated your bug with what this means. 

     

    Sometimes Developers Resolve a Bug when they check-in code, and then it gets passed off to the Test team to verify that the new code does indeed fix the problem you have seen by reproducing your environment and your bug.   After the test team validates that the new checked-in code fixes the issue in their test labs, they then assign it to the Connect triage team to communicate back to the submitter of the bug.  Sometimes bugs will "ping-pong" between Resolved and Active as the test team can reactivate a bug and assign it back to the developer if it doesn't address the issue or it causes a regression in some other part of the product.

     

    hope that helps.

     

     

    Tuesday, June 24, 2008 5:38 PM

All replies

  • Hi,

    As a matter of interest, what size is the Client's hard drive, and how much is free?

    Also, a previous poster with this error went to the trouble of wiping the hard drive and copying the folders back, a couple at a time. After copying them all back, they were able to run a backup successfully. That would indicate, in their case, that there was a disk problem causing the error. So, although you have ran chkdsk /r, I wonder if it would be worthwhile doing a manual defrag and chkdsk /r again, after deleting all temp files etc.

     

    Colin  

     

    Sunday, June 22, 2008 5:47 PM
  •  WITno wrote:

    The issues has been reported on connect (ID 351170) along with logs from server and client. Strangely, the Status has been set to Resolved (Fixed), without any workaround has been posted..?

    Any bright ideas, please?

     

    I am looking into the bug you reported right now.  I will update you via the connect tab and should have some news to share.with you shortly.

     

    Thanks for the follow up and for submitting a great bug!

    Monday, June 23, 2008 8:39 PM
  • I'm sure that this and the preceding post will be censored, but I am going to get this off my chest anyway. Then, I'm not going to waste any more of my time with WHS. Mr. Headerick deleted my previous post because of it being "inflammatory". The definition of inflammatory, in this case, is being critical of Microsoft. I doubt the post would have been removed had I been critical of one of its competitors.

     

    It is mildly irritating that we would have to wait on a PP1 to get x64 support since that is clearly the future. When I chimed in as having the backup problem similar to a previous poster, Mr. Headerick was the first to chide and cojole me into filing a bug report. I read docs on the Toolkit only to find that that too doesn't work with x64. I go through the hoops submitting the bug report with manual acquisition of server and client logs eagerly awaiting word from MS. Then, I get nothing from MS other than "previously reported. we are marking this closed." Not even a "kiss my grits" as far as my problem goes. I do not appreciate my time being wasted.

     

    Also, MS blames "missing file" messages during the WHS installation on bad downloads or bad media and advocates checksum verification and more hoops. I had this problem with downloaded WHS iso's.

     

    Guess what? I got the factory-pressed Eval kit and had the exact same issues. After what had to be a hundred "Retry" hits, it installed over a "51 minute" period that lasted about 12 hours. And this is SP2?

     

    Good luck to you all. You need it!

     

    Monday, June 23, 2008 10:53 PM
  •  WITno wrote:

     

    The issues has been reported on connect (ID 351170) along with logs from server and client. Strangely, the Status has been set to Resolved (Fixed), without any workaround has been posted..?

     

    Any bright ideas, please?

     

    The Connect triage team has updated your bug with what this means. 

     

    Sometimes Developers Resolve a Bug when they check-in code, and then it gets passed off to the Test team to verify that the new code does indeed fix the problem you have seen by reproducing your environment and your bug.   After the test team validates that the new checked-in code fixes the issue in their test labs, they then assign it to the Connect triage team to communicate back to the submitter of the bug.  Sometimes bugs will "ping-pong" between Resolved and Active as the test team can reactivate a bug and assign it back to the developer if it doesn't address the issue or it causes a regression in some other part of the product.

     

    hope that helps.

     

     

    Tuesday, June 24, 2008 5:38 PM