Error 'Unknown Status' failure after 2021 Upgrade

I will certainly try out that suggestion - after the backup I referred to in my last post completed and validated, I changed over the disk to run a monthly backup - and it failed. fsutil showed no corruption this time, but after running a CHKDSK /F on the C drive the backup ran.  Will post back, and thanks once again both for your time spent on this.

Hi,

I am also facing similar errors on my entire system disk backups. Also upgraded from ATI 2020 to 2021 and errors started after the upgrade. 

Same "unknown status" error and today I also got "The file is corrupted" error. Run Acronis VSS Doctor tool and it showed some warnings and an error on the NTFS system (Method failed with unexpected error code 3). Don´t know exactly what that means. Run CHKDSK /F on C: and D: partitions with no errors.

My system (a DELL XPS 8700) has a DIAGS partition, which I deselect in an attempt to perform the backup successfully, but it resulted in the same error.

Also tried to create new backup tasks, but always terminate with the same erros.

Strange that we are facing these errors using ATI 2021, after upgrading from 2020.

Heraldo

Can you post the log from VSS Doctor?  That way we can investigate further.

@Enchantech - got to the 'Delete Volume' in step 3 of your instructions and received a warning "the partition Simple Volume' is currently in use, to force the deletion of the volume click Yes. WARNING: Forcing a deletion may cause unexpected errors in the application using this partition. Do you want to continue?.  Stopped at this point.

Also don't understand why Disk Management and Minitool Partition wizard show a different number of partitions, Disk Management shows 6, MTPW shows 7.  MPTW shows a 128MB partition (File System='Other' Type= GPT (Reserved Partition) that does not show up in Disk Management. 

Hi Enchantech,

Thanks for the reply!

I am trying to upload the VSS Doctor log, but system is saying "The file could not be uploaded".

Anyway, I downgraded to ATI 2020 (removing ATI2021 thru control painel failed, had to use cleanup tool from acronis), restored backup config and system disk backup worked as expected.

I think something with the upgrade process or ATI 2021 itself is messing with disk system backups. Folder backups worked as expected in 2021.

DrMopp,

Presumably you still had Explorer open and viewing the sonysys partition when you received the warning message.  Attempting to Delete the partition/volume in that case would produce the error.

As for the 7 partitions listed in MiniTool, specifically the Reserved Partition, such partitions exist on all Windows OS disks however, Disk Management does not display it.

Heraldo,

Since you have downgraded to TI 2020 and things are working I would stick with that.  The log file is probably to large in size to upload here by the way.

OK now my problem is identifying the SONYSYS partition in Disk Management as it doesn't show any 'SONYSYS' partition label and the two 260MB partitions, of which I had assumed SONYSYS to be one (I do see the label in MTPW) are both shown in disk management as 100% free.  which SONYSYS can't be as there 29MB of data in it. (the data I copied to a USB stick) I can assign the drive letter in MTPW - would you consider carrying out your instructions in MTPW as safe as in Disk Management?

Okay, look at the previous screenshots you provided for both Disk Management and MiniTool.  In the Disk Management screenshot the sonysys partition is (Disk 0 partition 2).  I know this as in MiniTool the label sonysys appears and is on the second partition of the disk following partition 1 which is the Reserved partition.

So looking at the graphical representation in MiniTool we see that sonysys is the second partition on the disk.  In Disk Management we see that graphically the sonysys partition is the first partition simply because partition which is the Reserved partition does not appear by default.

Another way to look at it is that the sonysys partition is the partition that precedes the Windows RE Tools partition.

@Enchantech I still get the 'currently in use' error even with Explorer closed (pretty sure it was the first time too) . I do understand that the first partition shown in the graphical Disk Management view is the SONYSYS partition and had started through your script on that assumption, but these errors (including the preceding warning that the volume was not created by Windows) and the fact that the partition shows as 100% free when there is 29MB of data in it made me cautious.  I really want to get through this as your theory of the corruption in SONYSYS being written to the Shadow Copy makes a lot of sense, though Heraldo's choice of going back to ATI2020 seems increasingly attractive!

DrMopp,

What are the contents of the sonysys partition you copied to a new location?  Can you list them for me please?

The message you get when attempting to delete the partition is a warning confirmation message that is saying to you, are you sure?  There is no turning back from this process.

Answering yes to the message is the same as using the diskpart command delete partition override command.  It is a force delete of a partition on a system disk.  MS does this to make users not sure of what they are doing stop as you have, and go no further.

If you are unsure here then I suggest that you stop.  If you wish to revert back to TI 2020 I suggest you do so.

i recognize that all of this is a bit scary to anyone not familiar with the processes.  I also recognize that my advise may not be trusted and that's fine as well.

Do what you are comfortable with by all means.

I will say however that I believe TI 2021 has superior corruption detection methods over previous versions including TI 2020.  This would explain why TI 2020 backs up a disk without issue where TI 2021 will not.  Of course I have no definitive proof of this but in my testing of the TI 2021 product this appeared to be the case. 

@Enchantech - the SONYSYS partition contains a single folder 'EFI' - and that folder contains three subfolders -

1. Acronis, which contains:-
    asrm.efi
    asrm.xml
2. Boot which contains:-
   boot64.efi
   together with 34 what look like language folders i.e en-us, de-de, etc. each containing a single file, boot64.efi.mui
3. Microsoft which contains a single folder, 'Boot', which in turn contains:-
   boot.stl
   bootmgfw.efi
   bootmgr.efi
   memtest.efi
   winsipolicy.p7b
   and also has the language (?) folders each containing:-
   bootmgfw.efi.mui
   bootmgr.efi.mui
   memtest.efi.mui
    

It really isn't a question of not trusting your advice, merely feeding back to you what I see in order to confirm there is nothing I've missed. Reverting to ATI 2020 would be absolutely be the last resort, but you can understand my concern when I don't really understand what the function of the SONYSYS partition is, and why it is becoming corrupted so regularly.  

From the contents of the SONYSYS partition and given this is just 29MB in size, then I would suggest that this partition was used as part of a Factory recovery feature for this PC, so the boot entries in this partition would be pointing to another larger partition on your drive which would hold the actual recovery images that would be used to reset the PC to how it was shipped from the factory some years back, along with the original Windows OS and installed base applications that came with.

I have seen these partitions on older Dell, Lenovo and other make PC's, especially laptops, and have to say that I have never had cause to use them, primarily because the factory OS was obsolete in most cases, having been upgraded to later versions of Windows. 

Key question here: do you have a Sony factory partition present in this PC that the SONYSYS partition would link to for any recovery action?  If not, then I would suggest that the SONYSYS partition no longer has a purpose, especially as your listing of the contents doesn't look to show any diagnostic tools type folders or apps?

As to why this partition keeps becoming corrupted is a mystery unless Windows is trying to verify the links contained in the boot files from that partition, or there is some Sony application trying to do the same?

DrMopp,

Thank you for posting back the contents of the sonysys partition.  I must agree with Steve that this partition contains old factory OEM recovery files designed to assist in restoring the factory default operating system.  I suspect that this old factory OEM install is contained in partition 6, the 1,011MB partition ahead of the last partition on the disk which is labeled Recovery.

Your current Windows installation looks to hold your EFI, system boot files on partition 4 which is the other 260MB Fat32 partition.  If you look at this partition in the graphical view you can see it contains the EFI folder which is where UEFI will look for the boot files for Windows.

I have a suggestion for you, you obviously have one or more backups of this disk.  Using your latest backup open the folder containing this backup file in Explorer.  Click on the backup file to select it then, right click on the file to produce a context menu.  In that menu look for Acronis.  Hover you mouse pointer over the Acronis True Image entry to expand the menu and you should see two choices, they are Mount and Validate.   Click on Mount to mount the backup file.  The True Image Mount Wizard will appear prompting you to allow assigning drive letters to the partitions of the backup.  Click Proceed to continue.  The Wizard will advise when drive letter assignment has completed.

At this point you will find the assigned drive letters in Explorer along with partition labels if they exist.  If labels do not exists for a partition then you should see Local Disk followed by the assigned drive letter.  Locate partition 6 and click on it to select it.  In the right pane of Explorer you will see the contents of that partition.  I would expect you to find folders containing the old OEM installation files that could be recovered using the sonysys partition recovery files.

You can do the same for the other partitions of the backup.  Looking at partition 4 you should find the following folders, EFI, expanding EFI you should find folders Boot and Microsoft.  Expanding Boot you should find file bootx64.efi.  Expanding the Microsoft folder you should find Boot and Recovery.  Expanding those folders will reveal the necessary boot and recovery folders/files needed for your current system.

Once you finished with the mounted backup file you need to unmount all the partitions. To unmount the partitions again using Explorer, click each partition to select it.  Once selected, right click on it to produce the context menu then, hover your mouse again of Acornis True Image in that menu.  You will see the Unmount choice, select it to unmount the partition.  Once all partitions are unmounted you can then close the Explorer window if desired.

In all honesty I have no clue why you would want to retain the sonysys partition or its associated OEM old install folder but you have expressed a desire to do so.  My instructions are offered to assist you in doing just that.  Again, I believe that the sonysys partition on your disk contains a dirty bit.  This dirty bit is persistent.  It can be cleared using chkdsk /f but will return.  This is a known issue for Windows which MS has not addressed.  It is possible to use a Hex Editor to change this bit on disk a fix the problem.  Problem is that doing so does not guarantee a permanent fix.  What will offer a permanent fix is a deletion of the data contained in the partition followed by a full format of that partition which is why I offered that solution to you.

This is the best I can explain it to you.  Hopefully it will be enough for you to make a decision on how to move forward.

Steve, Enchantech, once again thank you for the time you have spent on this.  Firstly let me say I will carry out the exercise you described. I really have no desire to keep a facility which restores what is now a Windows 10 machine to Windows 8. I think I said in an earlier post that my concern was the function of the 'Assist' button, which has allowed me to boot an otherwise unresponsive machine on at least a couple of occasions when all else has failed.  I have no idea how that button functions, but it does, and my concern is that it will do no longer. Having said that, I do have (numerous!) backups from which I could presumably restore should that problem arise.

Look below for info on the Assist button:

Sony Assist button

Sony Assist Recovery

Thanks, the only thing this doesn't point out explicitly is the connection with the SONYSYS partition.. However I it seems I wouldn't lose much. Would quite like to get rid of all the Sony software and go back to a standard W10 installation, but some hardware functions (e.g. keyboard backlight) seem to require VAIO software to function.

DrMopp wrote:

Thanks, the only thing this doesn't point out explicitly is the connection with the SONYSYS partition.. However I it seems I wouldn't lose much. Would quite like to get rid of all the Sony software and go back to a standard W10 installation, but some hardware functions (e.g. keyboard backlight) seem to require VAIO software to function.

Any feature software for such as keyboard backlight will be installed as part of your Windows 10 OS so would be unrelated to any software in the other Sony partitions you have.

I have seen the same issues with Dell, Lenovo and Samsung laptops which come bundled with all sorts of 'extra' bloatware and which have rarely made any real difference when I have done clean installs of Windows (or Linux) on those same laptops!  If you visit the Sony Support site for your machine you should be able download any such utilities if needed and if available for your version of Windows OS.

OK, just one last thing I am puzzled about, if the SONYSYS is an OEM 'recovery boot' partition, how did it come to contain an Acronis folder? BTW the nightly backup has been running fine all week to the same USB drive, which has been permanently plugged in. Real test will be on Sunday when I change the disk to run the weekly backup. If there are no problems then, I will wait until I do have a problem before carrying out Enchantech's script to delete the data and reformat the SONYSYS partition. Thanks again. 

DrMopp wrote:

OK, just one last thing I am puzzled about, if the SONYSYS is an OEM 'recovery boot' partition, how did it come to contain an Acronis folder?

Did you check to see what, if anything, was contained in the Acronis folder?  No idea why there should be such a folder unless the partition had a drive letter and was picked up in place of one of your backup destinations when a task wanting to use that destination was run?

DrMopp,

I cannot explain how the Acronis folder came to be in the sonysys partition.  Looking back at your list of contents I see that this folder contains the necessary files for Acronis Startup Recovery Manager (ASRM).  It is indeed odd that this folder appears there as it should be found in the EFI partition (the other 260MB Fat32 partition).  I would not think that this would cause the issues you are experiencing however, I cannot guarantee that.

Do you remember activating ASRM on your machine?  When you boot your machine do you ever see "Press F11 for Acronis Startup Recovery Manager" message?  If you do then at some point you must have activated the feature.  I would advise looking in the EFI partition on disk to see if an Acronis folder exists there.  If it does then there may be a problem with that and I am not sure what that might be, possibly the issue you have.

The link below will give you more information about ASRM, what it does, how it works, and how to Activate and Deactivate it.  Since the ASRM folder in question here is found on the sonysys partition and should not be there deactivation of ASRM might remove the folder and files.  If the Acronis folder also exists in the EFI partition then I would suspect that deactivation would remove the folder and files from that location. 

ASRM

@Enchantech, yes when I fist installed Acronis on the machine way back in (I think) 2014 I activated ASRM.  There was a conflict with the 'Assist' button (don't recollect how that manifested itself but I think it left the machine unbootable). I was advised at the time by Sony support that it was incompatible with the 'Assist' button function, and it was deactivated.  I don't get the Press F11 prompt. In the EFI partition (partition 4), there is an EFI folder which contains an Acronis folder, which holds the files bootwiz.efi and bootwiz.xml  

@Steve the Acronis folder contains  the files asrm.efi, and asrm.xml hence the post from Enchantech above 

DrMopp,

In 2014 do you know if at that time your machine booted via Legacy/CSM rather than UEFI?

If yes this may explain why you have Acronis folders in both locations.  This may also be associated with your corruption issue but that is something Acronis would have to verify.

No the machine has always been UEFI. Have to say I have been using Acronis since 2014 and not had any real backup failures until this one. However with immaculate timing, as I was typing this the Acronis nightly backup, which as I said in a earlier post had been running all week, failed - with the same 'Unknown status' so I guess I need to start that deletion/reformat exercise on the SONYSYS partition after all!  

DrMopp,

Can you instead run chkdsk /f on C: again then run the backup task that failed and report back?  Meanwhile I am investigating this ASRM issue.  It may take some time before I have anything definitive.

OK ran CHKDSK /f on c: and backup running.

That's good.  chkdsk /f is obviously able to clear the corruption that exists in the VSS snapshot allowing the backup to run normally.  This in turn suggests that the backup produced would not contain the corruption causing the error.

I still do not understand fully why this change in backup tasks causes this issue.  

I am looking into the Acronis folder and ASRM files.  Since you have that feature disabled it seems to me that these should not be on your disk anywhere.  So I think it is probable wise to delete those folders.  I want to make sure of that before proceeding.  I will be back in touch.

Thanks. Just to clarify, on this occasion neither backup disk nor task had been changed when the problem occurred. It was running the same scheduled task to the same disk as it had done successfully for the previous five days.

Thanks for the clarification.

In case it's relevant - the backup script it failed on was the first one after in which space needed to be freed up on the backup i.e. clean-up is set to store no more than 5 backups and this would have been the sixth following which deletion of the earliest backup would occur.  Following the chkdsk a successful backup followed and deleted the earliest backup as per these settings.

DrMopp,

After a bit of research I decided to test out ASRM on my test computer.  The test computer runs Windows 10 version 2004 and has True Image 2021 latest version installed.

First I activated ASRM then rebooted to verify that the F11 prompt displayed at boot which was confirmed.

Next I used dispart to assign a drive letter to the EFI System partition on the computer.  After assigning a drive letter I exited diskpart and navigated to the EFI System partition/volume via the command prompt.  I then listed all contents of the partition using command tree /f. 

The above yielded a tree result that showed the root of the partition as EFI having directories Boot, Microsoft, and Acronis. 

At this point I brought up the ASRM utility again and deactivated the feature.  Going back to the command prompt and once again running tree /f I verified that the Acronis folder was still present meaning that deactivation had not removed it.

So to answer the question I had in my mind if deleting the Acronis folder and its contents would have any adverse effect on the computer, using the command prompt I navigated to the EFI root directory by typing cd \efi.  Now with the command showing that I was in the EFI directory I used the following command to delete the Acronis folder and the files in that folder by running command rmdir /S "Acronis" .  The /S switch deletes the directory tree including all sub directories and files within the directory.

I then verified that Acronis folder/files had been removed by running the tree /f command.  Having verified the absence of the Acronis folder and files I closed the command prompt and restarted the computer.  All went as expected with no issues on boot or startup at all.

To my surprise after Windows was booted I opened a command prompt and ran diskpart looking to remove the drive letter I had assigned to the EFI partition.  What I found was that Windows upon reboot had removed the drive letter so manual removal proved unnecessary.

Given my test results I recommend that you first delete the Acronis folder and the files it contains from your sonysys partition.  Once that is accomplished see if your backup task runs successfully.  If it does that's a good sign but may not fix the issue you have completely.  If backups continue to fail after some time then the procedure to delete all files from the sonysys partition and reformat it would be an appropriate next step. 

I would also advise that you delete the Acronis folder and its files from your EFI partition using the above outline as a guide.  Clearly if you are not using ASRM you do not need these unnecessary files on your disk especially in your EFI System partition.

@Enchantech, Following on from my post #126, the next nightly backup i.e. Saturday night, failed. So only one successful backup after the CHKDSK the next one failed. I followed your advice (Post #131 above) and deleted the Acronis folder from the SONYSYS partition. I didn't run a CHKDSK, change the backup task, the disk or or touch the connection, however the task was run manually rather than from a script.  The backup ran successfully.

Obviously as the task has run successfully many times before this doesn't signal that the problem is solved, but does seem to be progress. 

Later on today I will be changing over the disk for the weekly backup, running from a script and will post back.

Thank you once again for the time and effort you have put into this.

DrMopp,

Great, progress is good.  Did you remove the Acronis folder from your EFI partition/volume as well? 

Looking forward to your report back.

@Enchantech,  hadn't removed the Acronis folder from the EFI partition when I received your last post, however I did so before changing the disk for the weekly backup, and that backup task is now running (no CHKDSK in between).  There doesn't seem any logical reason why those files would be impacting the backup, but so far so good. 

DrMopp,

I have a theory.  In the instance of ASRM being enabled, the folder and files created are placed by the utility in the System partition.  This is necessary as ASRM is a boot time process meaning that it has function only during boot thus the F11 key option to run the utility.

On Legacy/CSM bios machines this folder and files are placed in the System partition which is a non-lettered Primary partition that holds the boot files necessary to boot the installed OS.

On UEFI booted machines this folder and files are placed in the EFI System partition which is again, a non-lettered Primary partition that holds the boot files necessary to boot the installed OS. (note these are both Primary partitions)

In regards to ASRM, the F11 key is used to cause the boot files in the Acronis folder to be read and then boot the Startup Manager.  For this reason the Acronis folder and files must be placed in the System partition.

When ASRM was originally activated on your system back in 2014 the Acronis folder was created in the sonysys partition (sonysys is probably short for sony system).  This was likely because the sonysys partition was at the time the System partition.  The TI 2014 product placed the Acronis folder and the files asrm.efi and asrm.xml in the sonysys partition.  This is consistent with documentation.

When you upgraded to Win 10, the Win 10 installer created the standard EFI partition which became the default System partition.  This change then introduced the corruption we have been dealing with. 

As you upgraded TI over the years each upgrade would find the Acronis ASRM present on disk and would overwrite the .efi and .xml files in the System partition.  With the upgrade to TI 2021 error checking has improved at the disk level.  That checking found the "error 0xfff0: A device attached to the system is not functioning" shown in your original backup worker log file you post on page 1 post #4.  The device not functioning I presume to be ASRM.

So this error along with the VSS snapshot errors you were experiencing have brought us to this point. 

I am not confident that the issue is resolved given the past, however, you must admit that results thus far are encouraging. 

Indeed I must, especially as the weekly backup has just completed and validated successfully. Your theory sounds eminently plausible, but as you say we have been here before,  although certainly not with quite so much in depth analysis as you have given.  All I can do is to continue to run the normal sequence of backup tasks and post back after a full cycle, (say a month?) or earlier if there is a problem in the meantime.

That sounds like a plan to me. 

Rather quicker conclusion to that exercise than we both hoped for.  Monday night's backup ran on schedule at 1800 without issue. Tonight the same task, same disk and lead failed with 'Unknown Status' ti_demon log file shows , as before, 'Failed to create volume snapshot'  and 'a device attached to the system is not functioning' 

DrMopp,

Well, that's not what was hoped for indeed!  At this point I believe you have 2 options:

1. First, run chkdsk /f on the C: partition, then in your backup tasks redefine your backup source and define the source so as to eliminate backup of the sonysys partition.
2. Perform the reformat of the sonysys partition as I described earlier in this thread.

The choice is yours.  You obviously have a number of backups containing good copies of the sonysys partition so you can feel secure in that.  We know that the sonysys partition does not change over time so there is no need to be concerned that it is damaged in some way.

With option 2 I do not think you would cause any harm in doing the reformat however, there is no guarantee that it will fix the issue permanently for you either.  The dirty bit issue, if it exists, in some cases requires a complete reinstall of Windows itself to remedy.

The one piece of this puzzle that bugs me is the whole VSS snapshot of C: issue.  If I knew more about the error checking that True Image performs of a disk prior to the snapshot I would know more about how to possibly fix the problem.

I'm not intimately familiar with this thread, but in reacting to Enchantech's recent statement about having some good backup copies of the sonysys partition, I will toss in another suggestion as to keeping that partition data...

On your C: (or other data drive), create a folder called sonysys somewhere and copy everything from the real partition (get the hidden stuff too). Then you could just get rid of the actual partition and still have it backed up. This assumes you don't actually need it now. And if you do in the future (doubtful) it could be recreated.

Thanks both, I guess now it comes down to establishing once and for all that the SONYSYS partition is actually the root cause of the problem and so Enchantech's option 1 seems to be the route to take for now - again if any problems with the partition excluded I will post back. 

Hi all, just to let you know I have completed a full cycle of daily, weekly and monthly backups (excluding the SONYSYS partition) now without the issue recurring. So being pragmatic, the problem is solved, by implementing Enchantech's option 1 in post #139 

However the cause of it i.e. the problem with the SONYSYS partition and the change between TI 2020 and 2021 which caused that problem to error in the latter is something of a mystery (again as per post #139).

Once again thanks all for your time and help with this.

DrMopp,

Glad to hear that you have found success.  Hopefully the issue with OEM recovery partitions can be solved by Acronis engineers.