Factory recovery - Create a Custom Recovery Partition
Is the update of the Recovery partition an automatic part of the upgrade to a new version?
I was referred here by zbook because my computer doesn't have a Recovery partition. I read the first page of this thread and modified it a bit for simpler systems like my home computer. It's on a network with my other computers but it's a simple home network, two computers on Ethernet, plus a laptop I keep maintained and ready to travel, and a Mac in another room, both on WiFi.
I used the Windows disk manager to contract the main partition on my boot HD by 10 GB to allow for future builds that will likely need more than the 8 GB in the example given here, and appropriate for v1903. I gave it the drive letter R: and the name Recovery and quick-formatted it HPFS.
I have a DVD with my build, v1803, on it, and the optical drive letter is D:. If you mount the ISO file instead, use its drive letter in place of D in the following. In Windows Explorer, I brought up R:\ in one window and the DVD root folder D:\ in another. By drag-and-drop, I copied everything except D:\Sources to R:\. I generated folder R:\Sources and copied everything from D:\Sources to R:\Sources except install.wim, which is the only large file in the ISO. This saved 99% of the time of copying the ISO files.
Then I booted to Windows RE (I use a USB thumb drive created by Create a Recovery Drive) and navigated to a command prompt. Using DISKPART -> list vol to get the drive letters under RE correctly, I am now writing install.wim onto a second HD. The command is
dism /capture-image /imagefile:E:\install.wim /capturedir:C:\ /name:"Recovery" /compress:maximum
NOTE: I tried to store it directly to R:\Sources\install.wim but dism failed with the message "There is not enough space on the disk." Apparently it generates the file and then compresses it, or otherwise uses a process that requires more than 9 GB to produce a final result of much smaller size.
Pace of dism is glacial, as always. When it's done, I'll move E:\install.wim to R:\Sources.\installwim, then run the batch file provided by Kari to put the Recovery partition's setup.exe on the boot menu.
I understand that you can use Windows Disk Manager to remove the drive letter later; I haven't tried that. I plan to leave the Recovery partition alone, visible to Windows Explorer as R:\.
You can keep your recovery image current by re-running the generation of install.wmi and copying it to R:\Sources\install.wmi after each Update Tuesday, or whenever you deem appropriate.
- - - Updated - - -
dism failed in writing to an internal SATA HD with over 200 GB of space with the same error: "There is not enough space on the disk." Log at x:\windows\logs\dism\dism.log has last good entry
"Successfully registered commands for the provider: Compatibility Manager."
This is followed by thousands of lines exactly like this:
Then there are a few lines that scrolled off the buffer before I could catch them, and then thousands of this line:
Eventually this turns into a few hundred lines of
" [0x80070070] ReadWriteDataInternal142): There is not enough space on the disk."
This ends with
" [0x80070070] ReadWriteDataInternal135): There is not enough space on the disk."
" [0x80070070] WriteDataCallback409): There is not enough space on the disk."
" [0x80070070] AddCaptureNoteToImage383): There is not enough space on the disk."
"2019-06-02 21:01:34, Error DISM DISM WIM Provider: PID=888 <pathname of huge text file in my user data> (HRESULT=0x80070070) - CWimManager::WimProviderMsgLogCallback"
It declares a few more errors. Then it has a similar error sequence that names another huge text file in my user data and another series of errors naming different modules, then exits with a walkback.
This may be because I have about 800 GB of user data on my system disk, all in C:\Data\*. It's a mystery to me why DISM would be looking at user files at all, though.
When i try to boot from the Recovery, i get this error message "windows could not display the images available for installation".
Update: After getting the same error while writing install.mis on another large HD and finding that 200 GB wasn't enough either, I drilled down into dism documentation and found that this usage of dism copies the entire HD contents, which in my case is over 1 TB. This is impractical for another partition on the same HD (I have reserved 10 GB). It's intended for a new installation of the OS only, with logons and customization, but not huge quantities of user files. I used the installation ISO's install.mis instead.
No. See this post.
That means that there are no valid Windows images in your WIM file. This usually indicates that the WIM file has not been captured correctly, for instance it has been captured from wrong partition.
What is install.mis?
DISM dies not capture whole disk, it captures a partition, method shown in this tutorial capturing the C: partition. This includes all files and folders present on C: at the moment of the capture.
If for instance Users folder contains a lot of personal files in various user profile folders, it is better to first move all data to another partition or external drive, and restore that data after you have used the custom recovery partition to restore Windows.
Generally speaking, it is a good idea to clean the C: partition by deleting unnecessary files and folders, emptying Recycle Bin, and so on, before capturing it.
The more user data on C: drive when it is captured, the larger the WIM image file.
Kari - the install.wim file captured by dism in the usage given in the example could not capture my C: drive when given 200 MB of space. The files are from my personal usage and include many things, and were culled of unnecessary and older unused or obseleted files before I ran dism. But there is just so much you can do with 800 GB of user data.
I see that user data storage on the order of 1 TB is not something you see as necessary, but, if it weren't, there wouldn't be so many HD's out there of sizes 2 TB and up. Mid-range laptops have been coming with 500 GB HDs for at least five years now. I'm sorry if my post offended you in some way, that certainly was farthest from my mind. But using dism to generate an image to fully restore a C: drive or partition for a computer in long-time use as a power workstation may not be an appropriate use; I use a rolling backup to an external RAID box for full backup.
- - - Updated - - -
BTW, my five-year-old laptop, which came with Windows 7 and has all the system partitions needed by Windows 10, recently upgraded to v1903 from v1809 without a hitch, other than taking all day. It's even added two updates since then. Never a glitch with that one. My main machine, however, started life as Vista installed over XP 64-bit and never had the Windows 7/8/10 invisible system partitions other than the EFI partition, is stuck at v1803, and after damage to the system in many failed feature updates, it won't even take a v1803 to v1803 "update," which we had hoped would put it in shape to update to v1809 or v1903. And, verifier reliably totally bricks C: at the next shutdown or reboot, requiring a full restore from backup. After almost three weeks of working with it, I've decided to cut my losses and run with v1803 until such time as I can do a full installation of v1903 including repartitioning to get a clean OS again. I should have done this years ago. This is no one's fault or shortcoming other than mine. No one should expect an OS to allow radiator-cap-job upgrades across three versions over five years and more. This is by far the longest I have ever gone without a full OS reinstall, which is to the credit of the Windows 7/8/10 team.
Can click your 1st and 2nd image to enlarge but not your 3rd. This makes it somewhat difficult to read that image.
No, your use of the OS does not affect the captured image.
From what I understand about this issue, and the error message your getting, you might just have a corrupt captured install.wim file, I stand corrected if not. This does happen, but for what reason I'm not sure, it's just one of those things sent to try us. I've run through the process in Kari's tut and it does exactly as it's supposed to.
Last edited by techquest; 09 Jun 2019 at 06:28.