Failure to create working WinRE rescue media
I recently upgraded a Dell Latitude laptop from Windows 7 to Windows 10. I removed ATI 2014, ran the cleanup tool and installed ATI 2020.
I tried to create a Simple Rescue Media. The creation process went OK but then when I booted it failed. It first showed the 4 pane blue window and the spinning balls as expected. But then, it went to showing the old style 4 paned colored flag thing and said "Starting Window". It looked like the old Windows 7 boot. But it never got past that point... just seemed to hang there.
I was later able to create a Linux boot, but it was running unbearably slow so I gave up on that. I created a WinRE boot drive on my old Sony laptop that has a fresh Windows 10 on it. I booted it on the Dell and the boot was successful. The backup ran far faster than the Linux version.
Before installing ATI 2020, I booted an ATI 2018 WinRE created on one of my PCs and it too booted fine on the Dell and I was able to create a backup easily. I'm wondering if there is something in the WinRE environment on the Dell that is not right, but not sure what to check into. Any advice?
And one other non-related issue. On the Dell, there is no notification icon for Acronis as I thought there should be.
Hi Mustang, thanks for chiming in.
I ran reagentc /info and results look good as seen belo. There's also a shot of the Disk Management map. It says partition 4 is the recovery partition. I also see that partition 2 is labeled recovery. Out of curiosity, I was able to assign a drive letter and look at it. It has a wim file but the date on that is the manufacture date of the laptop (in 2010). I can't assign a drive letter to partition 4 so I have not looked at it yet.
Anything I can check next?
By the way, when I do the same thing on my main PC, the reagentc identified partition is labeled OEM partition instead of Recovery Partition. But no problems on that one.
That confirms my suspicion were correct.
Did you try the MVP Tool? It should find the correct winre.wim and work.
As for the Acronis media builder, you'll need to delete or rename winre.wim in the second partition. It's the original Windows 7 version. After you assign a drive letter, you need to take ownership of the winre.wim and then remove the system and hidden file attributes before you can rename it
Not sure it confirms your suspicion as the partition where I found the Windows 7 wim was not the partition identified by reagentc.
Out of curiosity, I decided to create a Windows Recovery disk. It's been running for about 45 minutes now and is around 3/4 done. I don't know why it takes so long, but this is a 10 year old system running an I3 with only 4GB memory and USB 2.0 for the recovery drive.
I do plan to do the MVP tool, but I really want to figure out this weirdity first. Since rolling back to Windows 7 is considered an option for 10 day (or maybe 30 days), I may wait until Windows 10 has decided to no longer allow a rollback and see what happens then. I did find some notes online about similar issues.
The problem is that Acronis is not using the WinRE identified by reagent. I don't know what procedure they are using, but I do know 100% that I am right.
You should confirm the Windows Recovery disk works before going any further.
Renaming the Windows 7 winre.wim will not cause you any harm. If you do decide to roll back to Windows 7, all you would need to do is rename the file back to winre.wim.
OK, I'll give it to you. It does make sense.
Still waiting for the Windows recovery disk to complete. I think it's been running well over an hour now and looks to be about 80%.
No intention to go back to Windows 7. I'm not sure what all Windows does (other than delete Windows.old) when the rollback period times out.
Can you advise any good online reference to how all this recovery stuff works?
Finally, the Windows recovery drive was created. I booted it. It looks like it did the right things. It first asked for the keyboard layout and then gave me 4 main options...
Recover from a drive
Reinstalls Windows from the recovery drive connected to this PC. This will remove all your files and apps.
Continue
Exit and continue to Windows 10
Troubleshoot
Restart your PC or see advanced options
Turn off your PC
Nothing about Windows 7, at least on these options. I did not pursue the tree further.
Does this indicate that there may be a bug isolated to the ATI rescue media builder?
Bruno,
I cannot say if Acronis Media Builder has a bug or not. I wonder though that because Win 10 does not support its own Backup and recovery features but instead relies on the old Win 7 tools to do so if that may be part of the equation as to why Acronis choose the wrong wim file to create media from.
Now that you have created the Windows recovery drive maybe you should run Acronis Media Builder again and make another WinRE disk and see if it uses the correct wim file now. I have a feeling that it just might do so.
No such luck in running the Acronis Media Builder again... same result.
My plan is to wait out the Windows rollback period. I'll try again after that to see if things are in better shape.
I don't know if I'd call it a bug, it's more of a misstep. It starts with Microsoft doing a very poor job of updating from one version of Windows to the next. They are leaving the old recovery partition in place without doing anything to disable it. Then they create a new recovery partition. Not knowing exactly how Acronis is searching for WinRe.wim, I can only speculate they are starting at the beginning of the disk and finding the first instance they come across. In most cases this would not cause a problem. Most Windows 10 disks have two recovery partitions. The first is at the beginning of the disk and was created when Windows 10 was first installed. When an upgrade happens that first partition is too small to hold the new bigger WinRE.wim so they create a new recovery partition at the end of the disk. As long as the two recovery partitions are from Windows 10, there is no problem using the wrong one. They will both work. The problem only arises when the system was upgraded from Windows 7 to Windows 10.
Bruno,
Thanks for giving it a whirl. Now I know for sure that does not work. Mustang is right of course, this is a misstep in how MS implements an upgrade.
While I can agree that Microsoft may be sloppy in how it handles recovery partitions, I'm not yet willing to let Acronis completely off the hook when it comes to finding the right recovery partition.
When I found the wrong winre.wim file, it had a timestamp of 08/06/2010, the date my laptop was built with Windows 7. If it is possible to find multiple recovery partitions, then it should be able to 1) determine which is the right one to use, or 2) perhaps ask the user so that if one fails the other can be chosen on a redo.
Is there no way to look at a winre.wim file to determine what OS it is for?
I think Paul (Mustang) may be better able to answer your question since he has in depth knowledge of the method used by the MVP tool.
I agree with Paul about the misstep by MS in that had MS built backup and recovery into Win 10 as a feature of that OS and not remained using the Win 7 version your issue may not exist. I cannot prove this of course, but having run into numerous issues with Win 10 directly due to MS programming since the release of the third Win 10 major version upgrade, I cannot excuse them from this issue entirely as well. I am not saying that some fault does not belong to Acronis but I will say that in their case it is more likely an oversight than anything else.
Issues like this, until discovered, are not viewed as an issue until they are discovered. As Paul says, MS in leaving Win 7 recovery active, is a problem. I suggest that you report this to Acronis so that they can take steps to remedy the problem on their side. Obviously it can be done as the MVP tool works just fine.
To answer some questions here, I'd say Acronis is entirely responsible. They need to be able to deal with whatever Microsoft throws at them. Waiting until the rollback period is over and Windows.old is removed won't help. The Windows 7 recovery partition will remain with its winre.wim intact. The only way around the issue now it to delete or rename with Windows 7 winre.wim.
The carryover of the Windows 7 Backup method into Windows 10 is not an issue here. That doesn't use the Windows 7 WinRE. It works fine on Windows 10 clean installs that don't have any access to the Windows 7 WinRE.
It's difficult to look at a winre.wim file for version information. The file itself has no version information as regular files do. You can't learn anything be mouse hovering or right click/properties. I can tell you how winre.wim is located in the MVP Tool. The output from the command:
reagentc /info
is examined. I just revised it in another thread dealing with a German language problem. I was able to make it language independent by searching for the string with \\?\ to get the location. This works because \\?\ is unique in the location line of the output. You can also use:
dism /Get-WIMIfo /WimFile:(Path.winre.wim) /Index:1
to get version information. I had a problem with this method because there is nothing unique in the version line when you consider all languages.
I will say the MVP Tool method is not perfect. If the recovery environment is broken on the system and the recovery status is Disabled, there is no path to find in the output. However, Acronis would still be able to winre.wim on a broken system.
Paul,
Very interesting. Can you expand on your last paragraph above? How or by what means would Acronis still be able to winre.wim on a broken system? The \\?\ identifier targets UUID partitions correct? Do you know of other identifiers that could be used to target partitions? Why would not the \\?\ identifier error on a system that contains two winre.wim files presumably each in different partitions?
When you run reagenc /info on a system with a working recovery environment, you get a line showing the full path to the winre.wim file. For example, on my system the output looks like this:
Windows RE location: \\?\GLOBALROOT\device\harddisk5\partition5\Recovery\WindowsRE
This is called the global path. Global paths don't use drive letters. This is the path to the correct folder containing winre.wim for the system. I used \\?\ to identify the line with the path to winre.wim because it is unique to output line and doesn't depend on the language of the system. Then I use other methods to extract the full path from that line.
I know Acronis is not using this method because they sometimes find the wrong winre.wim. I don't know how they are locting winre.wim. I can only assume they have a method of searching for the file name starting at the beginning of the disk based on the results we are seeing.
Thanks Paul.
BrunoC wrote:While I can agree that Microsoft may be sloppy in how it handles recovery partitions, I'm not yet willing to let Acronis completely off the hook when it comes to finding the right recovery partition.
When I found the wrong winre.wim file, it had a timestamp of 08/06/2010, the date my laptop was built with Windows 7. If it is possible to find multiple recovery partitions, then it should be able to 1) determine which is the right one to use, or 2) perhaps ask the user so that if one fails the other can be chosen on a redo.
Is there no way to look at a winre.wim file to determine what OS it is for?
Bruno, try this... replace the drive letter and winre file name as needed. I know it works with installer iso's where I extracted the installer.esd and needed to find the correct winre.wim for testing some time ago.
dism /Get-WimInfo /WimFile:F:\sources\winre.wim
Mustang wrote:When you run reagenc /info on a system with a working recovery environment, you get a line showing the full path to the winre.wim file. For example, on my system the output looks like this:
Windows RE location: \\?\GLOBALROOT\device\harddisk5\partition5\Recovery\WindowsRE
This is called the global path. Global paths don't use drive letters. This is the path to the correct folder containing winre.wim for the system. I used \\?\ to identify the line with the path to winre.wim because it is unique to output line and doesn't depend on the language of the system. Then I use other methods to extract the full path from that line.
I know Acronis is not using this method because they sometimes find the wrong winre.wim. I don't know how they are locting winre.wim. I can only assume they have a method of searching for the file name starting at the beginning of the disk based on the results we are seeing.
I've been looking through a lot of stuff to try to understand how to find the recovery partition and also determine its version. There was a lot of confusion because different ways to look into the system can result in different ways that partitions are identified. For example, on my main PC I could only see 4 partitions, but couldn't understand why Disk Manager said the fourth partition was partition 5 whereas in other places it was 3. Sometimes partition counts are 0 based, sometimes 1 based. But that didn't explain.Turns out there is a small partition 3 that does not show up much.
Anyway, back to the subject. It seems that when running reagentc /info, it is reading the file C:\Windows\System32\Recovery\ReAgent.xml. That file contains both the location of the winre and the version.
The location is of the form...
<WinreLocation path="\Recovery\WinRE" id="", offset="" guid'""/>
For an MBR disk, the guid is all 0s, the id will identify the disk and the offset will identify the offset of the recovery partition. For a GPT disk, the id is 0 and the guid identifies the disk. Using WMI interface, it is easy to determine which disk and which partition is identified, which apparently is what reagentc does.
Also, there is a tag identifying the OS version, in my case on the faulty system it is...
<OSBuildVersion path="18362.1.amd64fre.19h1_release.190318-1202"/>
18362 is Windows 10. Interestingly, I updated the system using the Media Creation Tool to update from Windows 7 to Windows 10 1909, but it appears the recovery may be 1903. On my PC running 1903, it shows the same version.
It would seem that if Acronis is searching the disk for the recovery partition, it would make far more sense to start at the end rather than the beginning. On the other hand, there does seem to be a right way. I will submit a bug report.
Now that Windows 7 rollback is no longer viable, I ran things again.
First test: try again to create simple media. Failed, as expected.
Second test: reagentc /disable, then reagentc /enable... just to see if it would change anything. It didn't.
Third test: Assign a drive letter to the Windows 7 recovery partition, take ownership, change the name of the winre.wim file. Success! Acronis did create a good rescue drive.
I'm thinking I could use Mini Tool Partition Wizard Free to simply eliminate that partition and regain the space. Anyone see a danger lurking?
Yes. Post a screenshot of MiniTool showing the disk layout.
Paul, picture is here. The Windows 7 recovery partition is the one labeled Recovery... partition 2. Interesting that status shows Active and System. Partition 4 is the Windows 10 recovery partition. I wonder if the status made a difference to Acronis.
Actually I'm planning to leave it alone. If Acronis comes up with a fix, I can try it out. Meanwhile, I have a good rescue drive made using the Simple method.
Good call leaving it alone. Your system is booting in Legacy/MBR mode from that partition. There isn't enough space to be gained by playing with it. The standard size of a System partition is 100 MB, so you could only gain 650 MB at best.
Thanks for all your insights, Paul.
You're welcome.