Bad experience recovering preinstalled Windows 8.1 on an HP Pavilion laptop

Background


A few weeks ago, I became the owner of the HP Pavilion p170nr laptop with preinstalled Windows 8.1. Since I am an avid Linux user - it was decided to install the main, working Ubuntu system, but also leave Windows for toys and something moody, like updating the BIOS. Greed also played a role - for 8, then, in fact, the money paid.

The first step was to free up disk space, because the system, according to the legacy of Microsoft, occupied all available space with a single C drive. Google suggested that Windows finally learned how to repartition its drives using regular tools. But, as it turned out, you can only reduce drive C by half. Then came some "non-moving files", which Windows categorically refused to move. “Non-relocatable files” were rollback points and swap files. After removing them and turning off the swap, it was possible to start the process of trimming the disk to 100GB, but after a few seconds of work, a dialog box appeared saying that “there is not enough memory”. What memory, where and for what - was not reported. The disk did not have much time to fragment, and why memory is still needed there is a mystery to me.

I had to use some kind of partition manager (I don’t remember the exact name and don’t recognize it yet), who promised that it could work with Windows 8, but, as a result, killed my system partition. Moreover, both it and the section with the image for recovery are completely, although I did not perform any manipulations with it.

Naturally, there was nothing to restore the system with a laptop. As I found out later, HP sells them separately. And I did not bother to create something like this on my own.

SystemRescueCD came to the rescue. I will not describe the ups and downs with manipulations with fdisk and testdisk. But the output was able to get a structure identical to this

image

All the files seemed to be in place. testdisk correctly showed contents of all sections, except Windows and MSR. The problem with Windows was apparently in the very large size of the partition (it just fell out with a segmentation fault), but I did not understand what MSR was. It seems to be just storage for something even without a file system.

However, the system refused to boot. It issued a numerical error (something like 0x00000025), after trying to start the recovery tool, the message changed to "the file \ windows \ system32 \ winload.efi is damaged or missing."

I had to download the Windows 8.1 PE image (I found it ready on rutracker.ru) and dive into the study of boot loaders, images and other low-level details. All of the following is the fruit of my research, so in some ways I must have been mistaken.

Terms and Details


UEFI and .efi files . UEFI, as everyone knows, is a BIOS replacement with advanced features, and .efi, in fact, are executable files for it. As a rule, they contain bootloaders, the sole purpose of which is to initialize the environment and start loading the OS. But not necessarily. For example, a memory test is implemented as an efi file.

wim images . In newer versions of Windows, files with the .wim extension are widely used. In essence, this is just an archive that is used to deploy the system. It can be divided into volumes with the extension .swm. The dism utility is used to work with these images.

Boot order


After starting, UEFI analyzes the list of boot loaders. This is something like a start menu, which is edited by special utilities, for example efibootmgr in linux. The loaders themselves are located in the “System” section. The file system of this section should be FAT32 (otherwise the UEFI simply will not see it). It seems that it supports the UDF format for booting from CDs.

Loaders are simply .efi files that are usually located in the \ EFI \ NAME \ Boot directory. NAME is simply a name, often by the name of the equipment manufacturer. In particular, I have 2 subdirectories in the \ EFI directory - HP and Microsoft, and the bootloader is configured to \ EFI \ Microsoft \ Boot \ bootmgfw.efi.

The standard Windows bootloader also has its own boot menu. It is contained in the file \ EFI \ Microsoft \ Boot \ BCD. Essentially, this is just a list of .efi files that you can run and their launch options. For example, the memory test, the system recovery environment, and the usual boot of Windows start from here. This file is edited using the bcdedit utility. By the way, it was here that I had a problem after recovering disks. One of the boot record parameters defines the working disk for it as “device partition =”. And the corresponding .efi file will be loaded from it. But after the Windows partition was recreated, its UUID changed, so the file \ Windows \ System32 \ winboot.efi was not found. But I realized this much later, after I reformatted the entire section.

Download procedure in case of failure


In the event of a Windows boot failure, the bootloader entry in the BCD has a recoverysequence parameter that indicates which “item” to run in this case. This entry describes the preparation of a RAM disk from the \ Recovery \ WindowsRE \ winre.wim image from the “Recovery Tools” section and the launch of the corresponding Windows boot loader.

From the recovery environment, in turn, you can deploy the recovery image, which is stored on the corresponding section in the install.wim file (about 17GB). In addition to it, this section stores .wim files with drivers, manufacturer utilities, as well as scripts for installing all of this. My install.wim was split into many .swm files, about 350GB in size.

In the same section, I found the winUCRD.wim file, which in size and structure is very similar to winre.wim, but differs from it in size by a couple of hundred kilobytes and containing a few extra files. Perhaps some kind of blank for winre, which is being finalized during the installation process.

Recovery work


Everything looks quite simple - in the event of a system failure, a recovery tool is launched that tries to correct the situation, and if this is not possible, the factory state of the system is fully restored. Only, apparently, due to the complete recreation of several disks, only a black screen appeared when I started recovery.

There were a few google options left


  • Boot from a partition with a recovery image. Some articles recommend marking this section as active, after which the installation of the system will start from it. Naturally, it didn’t work out. With GPT partitioning, there is no active partition, and the file system on it is NTFS. Theoretically, the method is probably working. But not always and not at all.
  • Just unzip the install.wim image to the WIndows disk, and then the installation will go on its own. Already a more plausible option. install.wim really was there, and it turned out to unpack it, however, the installation did not start, but the system tried to boot, but fell at the stage of loading directx drivers. Apparently, it was necessary to reinstall the drivers for the laptop. But here a problem arose in the form of several dozens of .cmd and .vbs scripts designed to deploy the system and to tie them into some meaningful sequence, I did not succeed. Attempts to simply unpack after install.wim various .wim files on the same drive, of course, did not lead to anything.
  • Burn the image to disk or flash drive and boot from it. I think this is a working option. The only problem is that the image takes about 20GB and finding such a medium can be a problem.


On this I decided to finish my research. A working laptop was needed by Monday, installing and configuring Ubuntu and everything needed took about 5 hours.

PS Gathering material for this article, I came across an interesting post explaining why the recovery tool may not start. For it, in BCD, you need to specify the parameters of the RAM disk and the disk on which the installed WIndows is located (which was mine), which could also break down.

PPS Yes, indeed, the point was that the device / osdevice parameter of the BCD recording with loading recovery tools did not indicate a record with RAM disk parameters, but it was not clear where. You can restore using the following commands ()

bcdedit /create {ramdiskoptions} /d "Ramdisk options"
bcdedit /set {ramdiskoptions} ramdisksdidevice partition=Drive
bcdedit /set {ramdiskoptions} ramdisksdipath \Recovery\WindowsRE\boot.sdi

Here: Drive - the disk on which the recovery image is stored. This is not a UUID, but simply 'c:'
  • Drive - the disk on which the recovery image is stored. This is not a UUID, but just a string with the drive letter 'c:' (without quotes)
  • {ramdiskoptions} - this is indicated in this way (predefined name), but you can substitute here the GUID of the entry


Now we’ll edit the parameters of the recovery environment startup record (you can recreate it):
bcdedit /create /d "Boot from WIM" /application OSLOADER
bcdedit /set {GUID} device ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions}
bcdedit /set {GUID} path \windows\system32\winload.efi
bcdedit /set {GUID} osdevice ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions}
bcdedit /set {GUID} systemroot \windows


Here:
  • GUID - id of the recovery environment startup record, if necessary, you can create
  • [c:] - the current drive letter on which winre.wim is located. The disk can be hidden, in this case the path is indicated through its id - {UUID} \ Recovery \ WindowsRE \ winre.wim

Also popular now: