Windows 8.1 Recovery

[Roxine Denison]

WindowsRecovery Environment (WinRE) is a recovery environment that can repair common causes of unbootable operating systems. WinRE is based on Windows Preinstallation Environment (Windows PE), and can be customized with additional drivers, languages, Windows PE Optional Components, and other troubleshooting and diagnostic tools. By default, WinRE is preloaded into the Windows 10 and Windows 11 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016, and later, installations.

After any of these actions is performed, all user sessions are signed off and the Advanced startup menu is displayed. If your users select a WinRE feature from this menu, the PC restarts into WinRE and the selected feature is launched.

You can add one custom tool to the Advanced startup menu. Otherwise, these menus can't be further customized. For more info, see Add a Custom Tool to the Windows RE Advanced startup Menu.

You can customize WinRE by adding packages (Windows PE Optional Components), languages, drivers, and custom diagnostic or troubleshooting tools. The base WinRE image includes these Windows PE Optional Components:

The number of packages, languages, and drivers is limited by the amount of memory available on the PC. For performance reasons, minimize the number of languages, drivers, and tools that you add to the image.

During the specialize configuration pass, the WinRE image file is copied into the recovery tools partition, so that the device can boot to the recovery tools even if there's a problem with the Windows partition.

Add the baseline WinRE tools image (winre.wim) to a separate partition from the Windows and data partitions. This enables your users to use WinRE even if the Windows partition is encrypted with Windows BitLocker Drive Encryption. It also prevents your users from accidentally modifying or removing the WinRE tools.

Store the recovery tools in a dedicated partition, directly after the Windows partition. This way, if future updates require a larger recovery partition, Windows will be able to handle it more efficiently by adjusting the Windows and recovery partition sizes, rather than having to create a new recovery partition size while the old one remains in place.

In order to boot Windows RE directly from memory (also known as RAM disk boot), a contiguous portion of physical memory (RAM) which can hold the entire Windows RE image (winre.wim) must be available. To optimize memory use, manufacturers should ensure that their firmware reserves memory locations either at the beginning or at the end of the physical memory address space.

Unlike the normal OS update process, updates for Windows RE don't directly service the on-disk Windows RE image (winre.wim). Instead, a newer version of the Windows RE image replaces the existing one, with the following contents being injected or migrated into the new image:

The Windows RE update process makes every effort to reuse the existing Windows RE partition without any modification. However, in some rare situations where the new Windows RE image (along with the migrated/injected contents) does not fit in the existing Windows RE partition, the update process will behave as follows:

To ensure that your customizations continue to work after Windows RE has been updated, they must not depend on functionalities provided by Windows PE optional components which are not in the default Windows RE image (e.g. WinPE-NetFX). To facilitate development of Windows RE customizations, the WinPE-HTA optional component has been added to the default Windows RE image in Windows 10.

The new Windows RE image deployed as part of the rollup update contains language resources only for the system default language, even if the existing Windows RE image contains resources for multiple languages. On most PCs, the system default language is the language selected at the time of OOBE.

This is a known issue and the workaround is to either avoid setting the "Accounts: Block Microsoft accounts" to "User can't add or log with Microsoft Account" or set the MDM policy Security/RecoveryEnvironmentAuthentication to 2.

I have seen a lot of suggestions to just do an in-place upgrade from installation media, which is supposed to conjure up a recovery partition on its own, but I've also seen reports that this doesn't always work and I am just not willing to chance it.

You will inevitably have different partitions in a different order and different sizes, doesn't matter. You need to identify the largest sized one. this will probably be your main drive (e.g. C:\) that you store things on, so check you have at least a few GB free on your main drive and free some if you don't, or the next step may not work. In this example we will pick number 4, don't blindly copy this.

We've filled the empty space (it will use all available space automatically) and formatted it how it needs to be, and given it a nice name. Note when you create a new partition it will automatically select the new partition, so we skipped doing select partition ... again.

This is two attributes combined, 0x8000000000000000 "specifies that the partition won't receive a drive letter by default when the disk is moved to another computer, or when the disk is seen for the first time by a computer." Meanwhile 0x0000000000000001 "specifies that the partition is required by the computer to function properly." (source on attributes)

This will turn off and on again the recovery. If you didn't already have it enabled then the first command will tell you, but it's worth checking. REAgentC will automatically detect our new Recovery partition when we /enable it and will install the recovery partition in there, instead of on your C:\ drive. Let's double check its in the right place:

We're looking to make sure that in the long bit of text near the top, we see harddisk1 (or whatever disk number you picked earlier, usually 0 for most people), and then partition5 (the number of our new partition)

I have tried to access PowerShell from the Command Prompt in Windows Recovery Environment with no success. I am able to run VBScripts there without a problem, and I am now wondering if there is some way to run my PowerShell commands from there as well.

You can do this, but you'll need a Windows 8 install and the Windows 8 ADK with Windows PE (it's a rather large download). I'm fairly certain you can use this Win RE image on a Windows 7 install once you get it going, but I'm not 100% sure.

There's a few other ways you may be able to accomplish this, including building a Windows PE image with the recovery environment tools installed, but this is probably the easiest method, and will result in PowerShell being available whenever your machine enters the recovery environment vs. having to boot to it using removable media.

I used Everything to find mine. It happened to be hiding in C:\Recovery\67c45205-df4a-11e1-8fd9-9103ad6af7ef. This may be true for you as well. To take a look you'll have to disable Hide Protected System Files. This setting is lurking in Explorer under View, Options, Change Folder and Search Options, View tab.

You'll have to mess with the permissions to even see the permissions on this folder. Messing with permissions always make a little nervous, but forge ahead if you dare. I simply added my username to the security permissions with full control.

I elected to copy the .wim so I could work with it, but I suppose you could work with it directly as well. If you chose to work with it directly, modify command appropriately. I copied mine to C:\winre\.

Now push Up twice to recall the first command, and replace WMI with NetFX4. Repeat this until you have installed all the required components along with the required language. Remember to do this in order.

Now that all the packages are in place, we need to commit our changes and finish our WinRE.wim. From there we can build a .iso, test it in Hyper-V, and copy the WinRE.wim to our recovery file so we have access to PowerShell the next time the system crashes.

As a follow-up to the CrowdStrike Falcon agent issue impacting Windows clients and servers, Microsoft has released an updated recovery tool with two repair options to help IT admins expedite the repair process. The signed Microsoft Recovery Tool can be found in the Microsoft Download Center: =2280386. In this post, we include detailed recovery steps for Windows client, servers, and OS's hosted on Hyper-V. The two repair options are as follows:

Recover from WinPE (recommended option)

This option quickly and directly recovers systems and does not require local admin privileges. However, you may need to manually enter the BitLocker recovery key (if BitLocker is used on the device) and then repair impacted systems. If you use a third-party disk encryption solution, please refer to vendor guidance to determine options to recover the drive so that the remediation script can be run from WinPE.

Recover from safe mode

This option may enable recovery on BitLocker-enabled devices without requiring the entry of BitLocker recovery keys. For this option, you must have access to an account with local administrator rights on the device. Use this approach for devices using TPM-only protectors, devices that are not encrypted, or situations where the BitLocker recovery key is unknown. However, if utilizing TPM+PIN BitLocker protectors, the user will either need to enter the PIN if known, or the BitLocker recovery key must be used. If BitLocker is not enabled, then the user will only need to sign in with an account with local administrator rights. If third-party disk encryption solutions are utilized, please work with those vendors to determine options to recover the drive so the remediation script can be run.

Additional considerations

Although the USB option is preferred, some devices may not support USB connections. In such cases, we provide detailed steps below for using the Preboot Execution Environment (PXE) option. If the device cannot connect to a PXE network and USB is not an option, reimaging the device might be a solution.

3a8082e126