Find Reset Recovery Image Location in Windows 10  

NavyLCDR said:

The layout of a disk suggested by Microsoft is just that - only a suggestion - and it is the layout you would get with a default clean install of Windows 10."

That is actually incorrect NavyLCDR because what will happen when NOT using the layout that MS "Recommends" is that Windows 10 (and other Windows OS'es before it) will state...

"

...I can appreciate why the misperception about what MS "recommends" would cause confusion, because in reality, for optimal functionality, it's really a "requirement" to use the "recommended" partitioning schema.

Windows 10 (and others) will only provision the following partitions by default (when doing a standard installation)

A - System

B - MSR

C - Windows

Here's what Windows expects regardless of EFI/MBR etc...

• OS #1 Partition (This can be WinRE, but not PE. If you want PE, GRUB, or another BOOTLOADER that supports full Windows Functionality as part of your system, it MUST be on a partition at the END of the drive, but PE is easy as the last partition because it's generally ignored by Windows [GRUB, EasyBCD, and other utilities are NOT IGNORED, and can take over ALL BOOT FUNCTIONS desired] provided the partitions are in the correct order. The PE I put into the deployment can be manually BOOTED if desired, and shows as WinPE in the UEFI Boot Manager; though results can vary with different hardware).
• ESP (This covers, "MSR" , "EFI" , "System" etc.)
• OS #2 Partition "Windows!"

In the event people choose NOT to use the above sequence they'll lose the ability to use BitLocker, Dynamic Drives (software RAID){Reliably anyway}, and a WHOLE LOT of general OS reliability and security features.

I agree, this is very confusing, but the only part I'm confused about is why I was able to follow the same sequence thousands of times with consistent results before Windows 10, and yes, I've performed clean install more than once, revisited MS "suggestions" if you can call them that many times, and this is definitely something with Windows 10 that requires manual intervention that I've never done before, but that some of the people here on the forum like yourself I think, but I'm not sure because we're all expressing the issue at varying levels of detail, have worked on manually correcting where Windows 10 is seeing its WinRE partition.

There's more info about the architecture Windows (8-10) Requires here windows 8 - Partitions on GPT disk are not in the recommended order? - Super User

Almost forgot to mention;

Because Windows now has two boot points that are independent of one another ( The first partition " WinRE " and the bootable "EFI" partition" ) a UEFI BIOS (NOT a factor with MBR/Legacy) will detect 2 Windows Boot Managers, but prioritize the BOOT Manager for the OS itself while the other one on the first partition "WinRE" takes a backseat after Windows is installed. Both however are bootable via BIOS boot menu.

In other words, the EFI (BCD) is somehow supposed to bridge the OS Partitions to make them aware of the 1st WinRE partition so as to prevent Windows from using its own independent and embedded WinRE while also telling Windows where the Image Partition is that is (technically, excluding the PE partition I use in my deployments) the last partition ( "Image" ) that comes after all of the Windows OS Partitions (i.e. EFI/MSR, System, C Windows).

In the interim, both the WinRE (1st Partition) and Image (5th Partition) are locked as part of Windows' Security features. "ReagentC" , "BCDEdit" , "DISM" , and various other commands seem to be those that play the dominant role in correcting the problem, but the question becomes "How are those commands to be utilized in correcting the issue?" Diskpart and drive letter assignments unfortunately may play a role, but it seems there are some details missing that would be beneficial for everyone to know.

I hope this info makes things a little less cloudy for both of us. :)

NavyLCDR said:

What happens if you click the OK button in the above screenshot?

- Fair point NavyLCDR, most people will try it, and about a week later, they'll be running CHKDSK.

Most folks who plow through that very prompt are lucky to see their file systems survive for more than a month; however that's assuming they don't get a million errors during the install (over 60% of those kinds of forced installs fail) followed by people getting so seriously annoyed and frustrated they just give up and let Windows set its own partitioning defaults that only comprise three partitions - EFI/MSR , System , and Windows.

In the latter scenario people wind up getting a fresh install, and stuck with the performance lag and limitations of having to deal with the embedded into Windows implementation of WinRE instead of the more streamlined variation that having an actual WinRE partition provides (even includes Windows Updates as "suggested" by MS to be more seamless for Windows 10). :)

In many cases, after the first run of the OS, Windows will not boot consistently, and that's a very common problem with such unstable installations. It's even worse when people put multi-boot utilities as a 1st partition instead of a last partition because "Windows has a big ego, and has to be first" hurting everyone else's feelings. Oye.

In other words, even if the install does go through, the results typically aren't pretty. That's been an issue since Windows 2000, but the general concept of a usable and more refined WinRE was more often deployed once Windows XP (32-bit) SP2 and Windows XP 64-bit became the popular OS'es in 2005. Before then, WinRE wasn't very complex, and more of a Command Prompt set of tools than anything. WinRE became its strongest with the advent of Vista, and has been around ever since as a defacto repair tool that is ideally located on the first partition of any drive running Windows.

There's a ton of great stuff that can be done with a properly implemented WinRE Partition as the first partition. More than just a fresh install in an emergency, an updated fresh install without having to enter the software key or reauthenticate, additional tools and GUI options can be added, and much much more. WinRE is actually extremely powerful when its deployed well and can essentially make most Windows Installs self-sustaining; including spooling a lot of big data to a separate "Image" partition. No idea why MS doesn't have it set as a default because WinRE does proactively prevent a lot of problems as long as there's a partition for it from the very beginning and the OS portion of Windows is actually aware that it's present.

Ninjagirl74 said:

Hello -

So - after running reagentc /info - my recovery image location is also blank - (I have not had to use system reset, thankfully) - and above you mentioned "If there is currently not a reset recovery image registered, then you will see this below to the right of Recovery image location." - may I ask 'why' there is not an image registered? And it's located in the hidden C:\Recovery folder? Thanks -

Lisa

Hello Lisa, :)

It'll only show a location for Recovery image location if you created a custom reset image. Otherwise, Windows will use the default image in the C:\Recovery folder that's only listed for Windows RE location.

Brink & NavyLCDR ; First I want to thank you both because on some forums it's a challenge to find people with an open mind when it comes to troubleshooting. In fact that was the first characteristic of the users here that caught my attention.

I'm going to do some follow up on this thread because I'm also working with MS directly on this, and we found "something" , but we're not entirely sure exactly what yet. You both have offered valuable insight into what people's perceptions of the deployment process is versus what we are all supposed to be doing to get the best results. I admit, my own perceptions have also been askew due to my past experiences with other Windows OS'es, so this is a great conversation that will likely benefit a lot of people, and one that I'll add to as I get more information.

Ninjagirl74 & Brink ; You both coined the problem when you said; ...

Brink said:

Hello Lisa, :)

It'll only show a location for Recovery image location if you created a custom reset image. Otherwise, Windows will use the default image in the C:\Recovery folder that's only listed for Windows RE location.

...because that's exactly the problem, WinRE isn't registered to Windows.

Here are two key things I found out from MS;

1 - Even though the directions to get the partitioning structure necessary AND deploy WinRE (it's the latter that's actually the core of the problem because there are apparently complications to both to have WinRE correctly registered to the Windows 10 OS) to get the best results posted here [ Sample: Configure UEFI/GPT-Based Hard Drive Partitions by Using Windows PE and DiskPart ] by MS saying they're compatible with Windows 10 within the publication, but the directions as they relate to insuring WinRE becomes properly recognized by Windows 10 are NOT compatible because they actually pertain to Windows 8.1 and other less recent versions.

2 - It appears that using WinICD (Windows Image Configuration & Deployment) manager within an already existing Windows 10 installation is necessary to obtaining the best results, and it has to be within a pre-existing Windows 10 installation to get the proper image compatibility.

It's worth noting as clearly stated by NavyLCDR ;

NavyLCDR said:

The default Windows 10 installation will not have a recovery image. That is how they keep the recovery partition down to the 500 mb size. The default Windows 10 recovery uses files in the Windows folder to do a "reset".

A recovery image must be added by the manufacturer or the user of it is desired to have one.

...that the default fluctuating size of the recovery partition is often what's responsible for corrupting file systems. This same kind of architectural flaw is not just an issue with Windows in general, but also OS'es like Mac & Linux because they all (by default, unless the end user manually adjusts the parameters during install) use "caching/paging" and/or "imaging" partitions for recovery and processing purposes. In short "fixed sizes" prevent the need for fixes. [ Don't know if that last phrase should be considered coined, a bad pun, or both ]

It's been my experience that in deploying any OS it is necessary to go through the steps of manually configuring partitions related to caching/paging and/or imaging to large sizes (always more than thought needed, but within the tolerance of the OS i.e. in most versions of Linux, having a page partition larger than 32,768MB ( 32GB ) is unwise because if it's larger than that, it's often too much for the OS to address, and the same can be said of the Windows "Virtual Memory" Page File that should be of fixed size on a separate drive other than that hosting the OS; while for imaging it's best to use at least 25% to 33% of the drive space on the OS host drive because native utilities will compress the information for use on its imaging partition {also allows for complete forensic backups of the entire OS install and user data using 3rd party utilities such as Paragon because everything's on one drive {especially useful for Hardware RAID Mirrors} and hard drives should never be taxed by being filled to the brim anyways on the partition hosting the primary data such as the Windows OS by being left at least 15% empty to maximize the efficiency of file system maintenance such as weekly defragmentation and monthly file system maintenance such as scandisk that prevent 99% of file system breakdowns). Outside of the above examples, just in case it even needs to be said, in Windows the two partitions nobody should go outside the default size for are of course the EFI/MSR and System partitions because the sizes for those are part of the Windows OS' fundamental design that allow it to function properly with all features, such as BitLocker, enabled (worth noting the Advanced 4k Drives when used with Windows require the EFI size to be 260MB instead of the standard 100MB).

IMPORTANT NOTE - Since I made brief mention of Hardware RAID, the most useful thing to know about RAID is that the larger Stripe sizes like 128k and above rarely have a truly significant performance impact because even the fastest hard disks out there cannot spool data faster than the controller. Hard disk controllers in general have always had extraordinarily superior data throughput power when compared to hard disk drives themselves even if the drives are SSD. 64k Striping is good enough for almost any array and the best part is that if a forensic data backup is required, it will work perfectly without any special customization of the backup or restore process required regardless of whether people use Acronis, Macrium, or Paragon. My own favorite is Paragon, and I recommend nothing else except Paragon Server backup that can be deployed to a server environment making excellent use of the Microsoft ShadowCopy feature or just be run off of a boot disk for a traditional forensic backup just like in the days of Norton Ghost. Simple is good. :)

Suffice to say, I'm confident there's going to be a provisioning tutorial of sorts that results from all of this, and everyone's input has also been highly valuable to the process of figuring out the "in's" & "outs" of how to deal with WinRE for Windows 10.

I sincerely thank all of you, and there's more info to come for us all.

Hello Typhoon, and welcome to Ten Forums. :)

This is normal when you haven't created a custom recovery image.

If you like, you can verify if the default recovery image works by performing a "Refresh Windows" using the method in the tutorial below, and see if you get a prompt for installation media at step 6. If you don't, then the default recovery image is good.

Just be sure to cancel the refresh at step 8.

Refresh Windows 10 Installation Upgrade Tutorials