Windows10Pro, build 19045.3803. All up to date except January patches due to my not understanding stuff related to likely troble with KB5034441. I do not have BitLocker. According to reagentc recovery is enabled Code: Windows Recovery Environment (Windows RE) and system reset configuration Information: Windows RE status: Enabled Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE Boot Configuration Data (BCD) identifier: c28d645b-00f5-11eb-90b1-3c970ec27b1b Recovery image location: Recovery image index: 0 Custom image location: Custom image index: 0 REAGENTC.EXE: Operation Successful. Which is partition1? Windows 10 has recovery folder. Windows 7 does not. Contents via dir /a ... Code: Volume in drive C is Windows10_OS Volume Serial Number is 9818-CC1F / Directory of c:\recovery 09/21/2023 09:37 PM <DIR> . 09/21/2023 09:37 PM <DIR> .. 03/20/2022 09:30 PM <DIR> OEM 09/27/2020 02:37 PM 1,113 ReAgentOld.xml 09/21/2016 09:22 PM <DIR> WindowsRE 1 File(s) 1,113 bytes Directory of c:\recovery\OEM 03/20/2022 09:30 PM <DIR> . 03/20/2022 09:30 PM <DIR> .. 03/20/2022 09:30 PM 2,363 AfterImageApply_BDB0C1E8-6951-46C4-AB7F-C07B29F462FD.cmd 03/20/2022 09:30 PM 204 ResetConfig.xml 2 File(s) 2,567 bytes Directory of c:\recovery\WindowsRE 09/21/2016 09:22 PM <DIR> . 09/21/2016 09:22 PM <DIR> .. 07/16/2016 06:42 AM 3,170,304 boot.sdi 09/21/2016 09:22 PM 1,049 ReAgent.xml 09/22/2016 12:58 AM 388,240,707 Winre.wim 3 File(s) 391,412,060 bytes Total Files Listed: 6 File(s) 391,415,740 bytes 8 Dir(s) 25,573,113,856 bytes free Perhaps this might explain something? A piece of BCDenum: Code: Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume1 description Windows Boot Manager locale en-US inherit {globalsettings} default {default} resumeobject {c28d6458-00f5-11eb-90b1-3c970ec27b1b} displayorder {current} {default} toolsdisplayorder {memdiag} timeout 300 Windows Boot Loader ------------------- identifier {current} device partition=C: path \WINDOWS\system32\winload.exe description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {c28d645b-00f5-11eb-90b1-3c970ec27b1b} displaymessageoverride Recovery recoveryenabled Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \WINDOWS resumeobject {c28d6458-00f5-11eb-90b1-3c970ec27b1b} nx OptIn bootmenupolicy Standard Windows Boot Loader ------------------- identifier {default} device partition=E: path \Windows\system32\winload.exe description Windows 7 locale en-US inherit {bootloadersettings} recoverysequence {8367deb0-27d9-11e3-9df5-9c4e36ce69b0} recoveryenabled Yes osdevice partition=E: systemroot \Windows resumeobject {05b6ac8d-2354-11e3-88f6-3c970ec27b1b} nx OptIn I don't know how or where else to snoop. Might it be be inside the SYSTEM partition? I doubt it really. I'd like to find out in the event that KB will fail and require to change size which I cannot do if I don't know where it is.
You appear to have a Legacy/MBR configuration. In most MBR cases, the recovery environment is located in the MSR (MicroSloth System Reserved) partition, if it exists... that appears to be the SYSTEM_DRV partition shown above. If it doesn't exist (old builds), the recovery area resides on the OS partition (which has plenty of free space). Since SYSTEM_DRV has 700+mB free, the size of it won't be an issue for KB5034441's upcoming changes. When this KB gets applied to UEFI/GPT Recovery partitions, the most common reason for failure is due to the Recovery partition not having at least 250mB of free space. I think you're OK to "let 'er rip"... worst case would be that the KB fails but it shouldn't leave your System in a precarious state.
In the lower pane of the DiskMgt display, you show only 1-disk on that System... Disk0. MicroSloth labels its partitions 1-<n> starting from the left... SYSTEM_DRV is partition #1, which is also the same location that reagentc identifies as the location of the Recovery Partition.
That all depends on where the KB comes in. I'm guessing you've stopped receiving any updates from your Windows 7 System unless you're under Extended Service Update (ESU... and I don't see that KB offered in any of the Windows 7 variants) which means the update will be performed by Windows 10. That update will look at the info reagentc provides (it knows the required registered area for the Recovery environment) to determine where the Recovery stuff is. From above we see it pointing to harddisk0/partition1... that's where the Windows 10 Recovery Environment is.
I suspect it's the "Disk Management bug". The partitions looked like this a few years ago... https://www.wilderssecurity.com/thr...-windows-linux-dual-boot.401190/#post-2742035 Bug... http://www.goodells.net/dellrestore/vista/vista-diskmgmt-bug.shtml
it could have advantage to change settings in "view" and for the scale of partitions, if the used display is a micro device like about.
Hmm. Do you mean the three partitions 6-8 on top of the screenie from Disk management? Windows doesn't understand them. They are Linux Mint partitions. Currently unused but not wiped. Other partitions came from Lenovo (ThinkPad) and MS installation of Windows 7 Pro when I bought it. I installed Windows 10 and I guess MS did what they needed to do.
Yep, if the original System was Legacy/MBR (the W07 System from Lenovo), an ongoing Win10 install will use the MSR partition for its Recovery needs... it doesn't generate a new Recovery partition. Hope the KB install goes well...
Many thanks for your answers. I'm not ignoring your suggestion to do that KB. I was going to do January patches, but just had a notice that February patches are pending download, and the list includes that recovery thingie. So I need to delay a bit to see if there are issues with Feb. jobs. I have 2 additional questions: 1. Why do you think there is this large \Recovery folder in Windows? See the text I posted in the 1st post. Is it ever used? 2. Is there a way to see contents of the SYSTEM_DRV without using Linux, just through Windows as admin?
If you install the FREE version of Minitools Partition Wizard, it will allow you to use an "explore" function on that partition and give you an explorer-like summary of its contents. Also, in "Recovery/WindowsRE" there should be a WinRE.wim... what is the date of that file? Edit: Never mind, you OP shows the WinRE there to be vintage 2016 which means it was put there during the Win10 build but has probably been managed since in the SYSTEM_DRV partition created by the original Win7 build..
List of January and February patches included KB5034441. It had download error with a tiny "Retry" link. So I did retry and it went Checking for updates. Then I saw "installing 0%". It got dropped from the list while other updates were installing. Hmm. At the end, after restart and login, update history showed it was installed. Reliability reports shows both the failed download and successful installation. I don't know if MS installed what I had or downloaded newer version today. Thanks for the MiniTool Partition Wizard. I could finally snoop a bit through the SYSTEM_DRV before and after the update. You were right about recovery being on that partition. Only two files got changed winre.wim and bootmgr. Contents of that partition: Nothing changed in C:\Recovery. What it might be used for me knows not.
