cancel
Showing results for 
Search instead for 
Did you mean: 

Error EA390013: AT END OF SOMETHING during restore

gilgamesh-aus
Level 4

I'm having a problem restoring images for Windows 8.1 32bit both Home and Professional versions using SSR 2013 SP2.

I have created various desktop images in VMWare Workstation version 10 which I plan to deploy to physical hardware using SSR and the Restore Anywhere feature. All of the systems created using MBR have been tested by restoring them onto new Virtual Machines also using Restore Anywhere. All of them were successful with the exception of Windows 8.1 32bit. The successful restores also included the 32bit windows 8 and 64bit versions of Windows 8.1, it is just the 32bit versions of Windows 8.1 that have this error that pops up towards the end of the restore process..

SSR Error.JPG

All of my backup images were created with a cold backup. I recreated the SSR backup images for windows 8.1 in case something was wrong with them but the error still occurs.

In the searching I did there were suggestions that this error was associated with resizing disks, this is not the case on my part. The virtual disk used by the recovery virtual machine is the same size as the source virtual disk. The article TECH215429 (http://www.symantec.com/business/support/index?page=content&id=TECH215429) has two workarounds. Unfortunately both workarounds failed for me (and in workaround 2 I substituted size=350 for SIZE=100 because it is Windows 8.1).

The article TECH215429 also had the following in bold "NOTE: Customers experiencing this issue are encouraged to contact Symantec Technical Support as data is still being collected to assist in resolving this issue.". I was quite willing to contribute information to assist with resolution but the only way I could find to contact technical support was to raise a case, which I did so. Unfortunately I no longer have an active support contract so the request for a case was denied.

************************************************************************************************

Edit 26/May - Additional information

I have carried out further testing. As a normal step I always check the "Check File System after Restore" option as I want to be confortable something has not gone wrong during the restore process. It seems that choosing this option under for a Windows 8.1 32bit (either Home or Pro editions) restore causes this error; as when I don't check this box the restore is successful (though my comfort levels are decreased).

As I mentioned above the error is occuring during a restore of an MBR BIOS system. I have since carried out testing on a UEFI based system (Win 8.1 32bit) and I can confirm the same error with the check file system option occurs there as well.

I'm sure someone will suggest that there is a problem with the system I took the backups off. But the same problem would have to occur on four separate installs (win 8.1 32bit home and pro on both MBR and UEFI) so I don't think that's likely.

11 REPLIES 11

Markus_Koestler
Moderator
Moderator
   VIP   

Let me escalate this to support for you.

criley
Moderator
Moderator
Employee Accredited

This is an issue that is still under investigation so this really does need a support case to be opened I'm afraid.

gilgamesh-aus
Level 4

A pity as the technical document asked for people who have the problem to contact technical support but I'm unable to do so to provide information to help them. At least I provided details here where they may find it.

criley
Moderator
Moderator
Employee Accredited

In the searching I did there were suggestions that this error was associated with resizing disks, this is not the case on my part. The virtual disk used by the recovery virtual machine is the same size as the source virtual disk.

The issue described in the TechNote is specific to restoring to smaller volumes so it seems you may have a different issue, despite seeing the same error (some errors are generic in nature and can have multiple root causes).

That said, it sounds like this may be easy to reproduce. Can you confirm; you see the issue when restoring Windows 8.1 32bit (MBR or UEFI) from VM #1 to VM #2. Both VMs have the same configuration (i.e. disk sizes are exactly the same). Is this correct? If you can confirm, I can test this here.

gilgamesh-aus
Level 4

Thank you. Yes both VMs are the same configuration.

When I was testing I copied VM#1 to VM#2 to ensure consistency. Then on VM2 I ran the following in the command shell within the SRD

diskpart

sel disk 0

clean

And I let the SRD restore process re-initialise the MBR disk.

 

For the UEFI system I had to do things a little differently. The 32bit version of the SRD does not boot in a UEFI environment so I had to use the 64bit version. The VMWare machine settings lets me swap the windows version setting back and forth between 64 and 32 bit, so I can have 32 bit when booting the OS and 64bit for the SRD.

For the BIOS/MBR system I used both the 64bit and 32bit SRD to create and restore backups with the same results.

The results on both BIOS/MBR and UEFI/GPT have been consistent with the error popping up everytime I used the “Check for file system errors after recovery” option

criley
Moderator
Moderator
Employee Accredited

So you only see the error when you enable verify then?

gilgamesh-aus
Level 4

That's correct. When verify is not enabled then the recovery is successful.

criley
Moderator
Moderator
Employee Accredited

OK, so restore is successful with verify disabled? At least you have an easy workaround.

Let me try and test this here - make take a couple of days.

criley
Moderator
Moderator
Employee Accredited

Quick question; do these 32bit Win 8.1 machines have Update 1 for Windows 8.1 installed?

gilgamesh-aus
Level 4

These systems were built as a fresh Windows 8.1 install rather than installing Windows 8 first and upgrading to 8.1. I know that's not what you asked but extra information can't hurt.

All updates available from Windows Update had been installed on the 8.1 systems prior to backups. The MBR backups were made on the 5th of May and the UEFI backups were on the 20th of May. As I understand it all the patches for Update 1 were released on the 9th of April so they should be included in my backups.

criley
Moderator
Moderator
Employee Accredited

This is not something that I can reproduce here, even when Update 1 is installed.

This tells me that there is something specific to your environment that is causing this error (unless I am missing a vital piece of information that helps me to reproduce this).

As I mentioned earlier, I think this will require a support case so it can be investigated in more detail.