From Newsgroup: alt.comp.os.windows-11

I have installed this update on 2 Windows 11 25H2 computers but it will not install on 1. I have read there is a problem with some computers and have tried the fixes I found but to no avail. Has anybody had this problem and overcome it?
--
<Bill>

Brought to you from Anchorage, Alaska


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-18 18:17, Bill Bradshaw wrote:

I have installed this update on 2 Windows 11 25H2 computers but it will not install on 1. I have read there is a problem with some computers and have tried the fixes I found but to no avail. Has anybody had this problem and overcome it?

Yes, I too had problems with this update on just 1 of 4 PCs. Also, on
that PC, the Start menu had blank icons again, a problem which I posted
about previously, and, when restored, so too did the last backup image,
to my great surprise. So I went back one image further, and its icons
were intact, but the update still wouldn't install, so I re-imaged
again, and did a re-install from the relevant settings menu. Nearly all
my settings and Explorer views survived, but I had to clear all the
special folders clutter out of Explorer again.
--

Fake news kills!

I may be contacted via the contact address given on my website: www.macfh.co.uk

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Java Jive wrote:

On 2026-04-18 18:17, Bill Bradshaw wrote:

I have installed this update on 2 Windows 11 25H2 computers but it
will not install on 1. I have read there is a problem with some
computers and have tried the fixes I found but to no avail. Has
anybody had this problem and overcome it?

Yes, I too had problems with this update on just 1 of 4 PCs. Also, on
that PC, the Start menu had blank icons again, a problem which I
posted about previously, and, when restored, so too did the last
backup image, to my great surprise. So I went back one image
further, and its icons were intact, but the update still wouldn't
install, so I re-imaged again, and did a re-install from the relevant settings menu. Nearly all my settings and Explorer views survived,
but I had to clear all the special folders clutter out of Explorer
again.

1 out of 3 computers for me. Nothing seems to be broke. I do have a backup image made before I tried installing this from a cumulative update. I think
I will wait and see if Microsoft fixes it because they are aware there is a problem. Thanks for the response.
--
<Bill>

Brought to you from Anchorage, Alaska


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Bill Bradshaw wrote on 4/19/2026 9:59 AM:

Java Jive wrote:

On 2026-04-18 18:17, Bill Bradshaw wrote:

I have installed this update on 2 Windows 11 25H2 computers but it
will not install on 1. I have read there is a problem with some
computers and have tried the fixes I found but to no avail. Has
anybody had this problem and overcome it?

Yes, I too had problems with this update on just 1 of 4 PCs. Also, on
that PC, the Start menu had blank icons again, a problem which I
posted about previously, and, when restored, so too did the last
backup image, to my great surprise. So I went back one image
further, and its icons were intact, but the update still wouldn't
install, so I re-imaged again, and did a re-install from the relevant
settings menu. Nearly all my settings and Explorer views survived,
but I had to clear all the special folders clutter out of Explorer
again.

1 out of 3 computers for me. Nothing seems to be broke. I do have a backup image made before I tried installing this from a cumulative update. I think I will wait and see if Microsoft fixes it because they are aware there is a problem. Thanks for the response.

You'll need go step outside the usual Google/Reddit/YouTube
search/articles box for this one.

The error code 0x8008005 should be treated as a generic failure to update
but not for one specific causes.

Multiple issues have been in play for updates since 25H2 release (and
also applicable to any devices running 24H2).

What should be done at this time for "Cumulative Update KB5083769 and
Error 0x8008005"
- In addition to security fixes, this update includes under-hood
revisions for Secure Boot 2023 certs and Windows Recovery and a
verification of the minimum acceptable version of the Windows update engine.

1. Secure Boot - check status via Powershell admin mode ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
-match 'Windows UEFI CA 2023')
If the above does not return True, then try to manually force the
Secure Boot cert deployment

Again in a Powershell admin mode, run each of the following. Do not
interrupt, once done with the second command 'Restart the device 2X' then repeat the status check for the True value.

Set-ItemProperty -Path
rCLHKLM:\SYSTEM\CurrentControlSet\Control\SecureBootrCY -Name rCLAvailableUpdatesrCY -Value 0x40

Start-ScheduledTask -TaskName rCL\Microsoft\Windows\PI\Secure-Boot-UpdaterCY


2. DiskCleanup - admin mode, all items - run, do not interrupt

3. Windows Recovery Partition size - check for Recovery partition free space(needs to be greater than 250 MB, in some cases greater than 400 for devices with pre-Dec 2025 Windows Recovery files)
To check recovery partition size/free space. Powershell admin mode.
GET-VOLUME

If secure boot shows as True, the Recover partition has sufficient free
space, and Cleanup finishes, retry installing the update.
Note: It may be necessary after the device restarts to visit Windows
Update and acknowledge another restart for KB5083769 to finish installing
and the built-in auto restarts(one or more).


Feel free to report the results.
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-21 11:50, ...w-i|#-o-#-n|# wrote:

3. Windows Recovery Partition size - check for Recovery partition free space(needs to be greater than 250 MB, in some cases greater than 400
for devices with pre-Dec 2025 Windows Recovery files)
To check recovery partition size/free space. Powershell admin mode.
-aGET-VOLUME

If secure boot shows as True, the Recover partition has sufficient free space, and Cleanup finishes, retry installing the update.
-aNote: It may be necessary after the device restarts to visit Windows Update and acknowledge another restart for KB5083769 to finish
installing and the built-in auto restarts(one or more).

It looks like this is a MAJOR problem after the 25H2 update.

On a few of my desktops I have a C: partition with 300 GB of free
space, but with something immovable at the end, so maximum shrink
space just above 40 MB. Since it is an SSD, the system does not allow me
to do a defrag run to try to allow more shrink. The recovery partition
is about 2 GB immediately following the C: partition, and it has about
200 MB free. If I *could* shrink the C: drive, I could make space, but
disk management will not allow me to extend the recovery partition to
the "left".

This seems like it must be a common problem on systems with a 500 GB SSD system disk that are upgrading from Win11 24H2 to 25H2 and need to
achieve 400 GB of free space on the recovery partition. Is there a
cookbook for how to do this?
- can it be done with the standard tools in Win11 Pro?
- can I do it with AOMEI Partiton Assistant?
- is there a tool to explore the recovery partition? It is an NTFS file
system, so it seems it should be possible to mount it as drive R: and
point File Explorer at it to clean it up

Paul and Winston, can you guide us?
Maybe it is as simple as setting a magical registry key that says
"WinRE, please expand recovery partition to 400 GB free space" and then restarting ;-)
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/22/2026 9:15 AM, Lars Poulsen wrote:

On 2026-04-21 11:50, ...w-i|#-o-#-n|# wrote:

3. Windows Recovery Partition size - check for Recovery partition free
space(needs to be greater than 250 MB, in some cases greater than 400
for devices with pre-Dec 2025 Windows Recovery files)
To check recovery partition size/free space. Powershell admin mode.
-a-aGET-VOLUME

If secure boot shows as True, the Recover partition has sufficient
free space, and Cleanup finishes, retry installing the update.
-a-aNote: It may be necessary after the device restarts to visit Windows
Update and acknowledge another restart for KB5083769 to finish
installing and the built-in auto restarts(one or more).

It looks like this is a MAJOR problem after the 25H2 update.

On a few of my desktops I have a C: partition with 300 GB of free
space, but with something immovable at the end, so maximum shrink
space just above 40 MB. Since it is an SSD, the system does not allow me
to do a defrag run to try to allow more shrink. The recovery partition
is about 2 GB immediately following the C: partition, and it has about
200 MB free. If I *could* shrink the C: drive, I could make space, but
disk management will not allow me to extend the recovery partition to
the "left".

This seems like it must be a common problem on systems with a 500 GB SSD system disk that are upgrading from Win11 24H2 to 25H2 and need to
achieve 400 GB of free space on the recovery partition. Is there a
cookbook for how to do this?
- can it be done with the standard tools in Win11 Pro?
- can I do it with AOMEI Partiton Assistant?
- is there a tool to explore the recovery partition? It is an NTFS file
-a system, so it seems it should be possible to mount it as drive R: and
-a point File Explorer at it to clean it up

Paul and Winston, can you guide us?
Maybe it is as simple as setting a magical registry key that says
"WinRE, please expand recovery partition to 400 GB free space" and then restarting ;-)

200 MB free on the Recovery is a concern.


Did you perform the recommended Powershell command suggestion for free
space on the disk.
GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.


Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #
Powershell admin command. Copy the below command, paste or type into Powershell, run the command, then copy and paste the results in the same reply.

reagentc /info
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Wed, 4/22/2026 12:15 PM, Lars Poulsen wrote:

On 2026-04-21 11:50, ...w-i|#-o-#-n|# wrote:

3. Windows Recovery Partition size - check for Recovery partition free space(needs to be greater than 250 MB, in some cases greater than 400 for devices with pre-Dec 2025 Windows Recovery files)
To check recovery partition size/free space. Powershell admin mode.
-a-aGET-VOLUME

If secure boot shows as True, the Recover partition has sufficient free space, and Cleanup finishes, retry installing the update.
-a-aNote: It may be necessary after the device restarts to visit Windows Update and acknowledge another restart for KB5083769 to finish installing and the built-in auto restarts(one or more).

It looks like this is a MAJOR problem after the 25H2 update.

On a few of my desktops I have a C: partition with 300 GB of free
space, but with something immovable at the end, so maximum shrink
space just above 40 MB. Since it is an SSD, the system does not allow me to do a defrag run to try to allow more shrink. The recovery partition is about 2 GB immediately following the C: partition, and it has about 200 MB free. If I *could* shrink the C: drive, I could make space, but
disk management will not allow me to extend the recovery partition to the "left".

This seems like it must be a common problem on systems with a 500 GB SSD system disk that are upgrading from Win11 24H2 to 25H2 and need to achieve 400 GB of free space on the recovery partition. Is there a cookbook for how to do this?
- can it be done with the standard tools in Win11 Pro?
- can I do it with AOMEI Partiton Assistant?
- is there a tool to explore the recovery partition? It is an NTFS file
-a system, so it seems it should be possible to mount it as drive R: and
-a point File Explorer at it to clean it up

Paul and Winston, can you guide us?
Maybe it is as simple as setting a magical registry key that says
"WinRE, please expand recovery partition to 400 GB free space" and then restarting ;-)

Using diskpart.exe , once the partition is selected, you can do

assign letter=R

and then in another administrator terminal, you can do

cmd.exe # switch to command prompt, so dir /ah will work
R:
dir /ah # Take note of all the hidden materials
cd nameofpartition # Repeat for the next level, as you check for Winre.wim file
dir /ah
...
C: # Later, change directory away from R: so it isn't busy

Then, in the first administrator terminal, you can do a

remove letter=R
exit

to unmount the Recovery Partition and end the diskpart.exe session.

Any "good" partition manager, can shrink a partition below
the half way point where the "blocker" is. Some structures
are harder to move with the defrag API, than others. With Microsoft,
the definition of a well designed NTFS, is for the blocker to be
in the center. For the Raxco defragmenter, it will move it
as the partition shrinks (shrink it down, it tends to re-center the
blocker for you). Raxco is out of business now, so there's nothing to
buy any more. That's just an example.

I just use Linux gparted for this, as it deals with a lot
of things. The only thing is *cannot* handle is Microsoft Reserved,
and that's because it has no file system. But then, some other
(Windows-side tools) can move Microsoft Reserved.

Paragon Partition Manager 14 Free, the only function it had, was
Move/Resize (which is most of what you need for general work), but
it's a bit of a fussy thing, and some jobs it should be able
to do, it backs out and whines.

I haven't tested AOMEI Partition Assistant, so cannot comment
on how well it works. Generally for partition managers, you want
partitions which are CHKDSK clean, for best results. For
the most part, Windows attempts to do that itself. But if
you did find something failing, that would be my first guess
as to why the operations did not go well.

If you're using a tool like that for the first time,
I recommend a full backup of the disk, so if "something happens"
you are ready. It takes a few sessions, before you get some idea
how good these tools are. You cannot rely on Google any more,
for discovering the issues, as lots of stuff Google will
simply not return topical content.

When Windows shrinks a partition, that isn't "exactly" defragmenting.
The Defrag API is being used to implement "Move below X" so that
all objects have an address of less than X. Only the "things" way out
on the disk, end up moved. The things which are below X are likely reasonably-pressed against the origin, with the usual "small-gaps"
Windows likes between objects. As the operator, the closer you get
to "really pinching" the partition, the harder that Defrag API
is going to be working, and the more SSD wear that will result.
But it isn't really defrag, because the objective is "Move below X"
and whatever it takes to do that. At some point, you *have*
to fragment things, to squeeze things in without any gaps. And running
the Defrag API in defragment mode, it's not going to be (preferentially) chopping large objects into a ton of small bits, as the software knows
it's going to have to undo all of that a week later.

Just about any move/resize, has to be better than the Windows one.
It still does the things Windows would do ("Move below X"),
it's just that a third party tool is more willing to move a blocker.
Note that, not all software devs are created equal, and when
someone doesn't do these things, it's because they don't know
the recipe. Microsoft refuses to do some of these things,
because "the NTFS department would not approve our work". I'm
reasonably sure, that if unchained, the staff at MSFT could
run rings around these other guys.

https://www.aomeitech.com/pa-tips/windows-resize-partition-0725.html

And I do make safety backups, it's not just talk. I was commenting
the other day, that the big scratch drive had nine safety backups
on it (they're labeled "ERASEME" as acknowledgement that they
are only relevant for about three days, until the danger is past).

I've had a few occasions, where I've been just plain lucky.
I'd made a backup of Win7 C: (for no particular reason), then ten minutes later, I was curious what was inside System Volume Information,
the things I did, "utterly destroyed C: ", there was nothing
recoverable. And that (random) backup saved my ass. Those two
events were not joined in any way -- at the time my estimate
was "well, nothing dangerous going on here, let's do this",
but I was wrong. The old rule was "you can do anything you want,
as long as your activity is read-only". As it turns out, this
is not true. There are cases, where reading a thing you've been
kept away from, can trash a thing. That's why they keep you away
from it :-) A safer option might have been a "remount ro" so that
physically no changes could be made to the item. Whereas I was
running "rw" and "just reading things, not writing them". Boom.
Destroyed. Plenty of people didn't believe me, either. Try not
to fiddle with shadows.

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining Size
----------- ------------ -------------- --------- ------------ ----------------- ------------- ----
Recovery NTFS Fixed Healthy OK
199.92 MB 1.17 GB
SYSTEM FAT32 Fixed Healthy OK
31.3 MB 96 MB
C Windows NTFS Fixed Healthy OK
309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0 ] [ Windows C: ][ ]
[ Basic ][ ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][ 100 MB ][Healthy (Boot,][Healthy ]
[ Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into
Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB

PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration Information:

-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
-a-a-a Recovery image location:
-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a Custom image location:
-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ]
[-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
| Disk 0 | | Windows C: | |
| Basic | | 475.65 GB NTFS | 1.17 GB |
| 476.92 GB | 100 MB | Healthy (Boot, | Healthy |
| Online |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the right of Recovery.

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Wed, 22 Apr 2026 14:11:14 -0700, Lars Poulsen
<lars@beagle-ears.com> wrote:


I hope Google translates well from Italian to English, but I'll give
you a tip that you might be able to solve much faster.

First, AOMEI Partition Assist can shrink and manipulate partitions. I
used it on one of my PCs to solve the same problem.

But honestly, on my main PC, I did everything differently.

Get Macrium Reflect X, make a system image of everything on the SSD
elsewhere (external drive), and run Macrium recovery on a USB stick.

Delete all partitions using the Windows 11 ISO, if you can.

Launch Macrium from the USB stick, tell it you want to restore a
single partition at a time. You'll select it from top to bottom, but
also tell it to expand it so it's larger.

SOLVED.

And you also have an excellent program to install to make backup
copies of Win11 for safety, now it is also obvious I think, but it is
truly excellent, it has saved me many times and allows this creative
use of backup & restore by changing the size of the individual
partitions, keeping all the GUIDs and the information present intact.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 4/23/2026 3:46 AM, Evil Boomer Santa Claus wrote:

On Wed, 22 Apr 2026 14:11:14 -0700, Lars Poulsen
<lars@beagle-ears.com> wrote:

I hope Google translates well from Italian to English, but I'll give
you a tip that you might be able to solve much faster.

First, AOMEI Partition Assist can shrink and manipulate partitions. I
used it on one of my PCs to solve the same problem.

But honestly, on my main PC, I did everything differently.

Get Macrium Reflect X, make a system image of everything on the SSD
elsewhere (external drive), and run Macrium recovery on a USB stick.

Delete all partitions using the Windows 11 ISO, if you can.

Launch Macrium from the USB stick, tell it you want to restore a
single partition at a time. You'll select it from top to bottom, but
also tell it to expand it so it's larger.

SOLVED.

And you also have an excellent program to install to make backup
copies of Win11 for safety, now it is also obvious I think, but it is
truly excellent, it has saved me many times and allows this creative
use of backup & restore by changing the size of the individual
partitions, keeping all the GUIDs and the information present intact.

That's a Macrium drag and drop restore, which in a pinch can be
used as a partition manager (this is because Macrium allows you
to click on a proposed partition you are restoring, and change the
restored partition size). A downside of a drag and drop restore,
is you may have to do a "Boot Repair" using the Rescue CD, and even
if you do that, additional commands may need to be issued to finish
the repair of booting (if you have more than one Windows C: partition
on the storage device).

Macrium does not necessarily keep all GUID. It disambiguates when you
do a "full" restore (not a drag and drop). The purpose of doing that,
is so that an original disk, and a new disk (with a restore just done on it), can be plugged into the same computer, and disk 1 does not try to modify something on disk 2, due to the GUID. The disk 1 and disk 2 have
different GUID assigned to their partitions.

When you drag and drop the partitions, Macrium does not do the
same amount of work at the end, to ensure everything works,
and you can "play it by ear" when you get to that point. If
it doesn't boot after a drag and drop restore, you can use
the Rescue CD to get (a minimum of) one C: partition to boot.
That's what the Boot Repair on the Rescue CD is for. Additional
commands may be needed, if for example partition E: is not
picked up as a candidate for booting.

bcdboot E:\Windows /s S: # Adding a second Windows partition to boot,
# where the S: mapping was created to EFS via
# diskpart.exe assign letter=S command.

bcdboot E:\Windows # If C: is already booting, the OS knows where
# EFS is located, and the details do not need to
# be spelled out, most of the time. Spelling out
# the S: part like previously, is when there are 2 disks
# in the computer and you want to avoid accidents.

And this command only works from a running C: , where you want to
remove all references to E: that remain in the BCD file.
After you do this one, you could add-back E: via bcdboot E:\Windows

bcdboot /bcdclean full # Leaves C: in a booting state, removes any corrupt
# information from the E: second OS.

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/22/2026 2:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB

PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration Information:

-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a Windows RE location: \\? \GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542- acabeae3b1dc
-a-a-a Recovery image location:
-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a Custom image location:
-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ]
[-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

Yes. It validates the location, disk and partition number(of the disk, windows, recovery paritition) and their respective size and free space.

Now, run this command in an admin Powershell window.
Copy and paste the full line.

DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim
/index:1

The output will provide the latest version(Service Pack build and
install date) of the current recovery partition.
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into
Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
-a-a-a Recovery image location:
-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a Custom image location:
-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ]
[-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
| Disk 0 | | Windows C: | |
| Basic | | 475.65 GB NTFS | 1.17 GB |
| 476.92 GB | 100 MB | Healthy (Boot, | Healthy |
| Online |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the right of Recovery.

Paul

?
Looks like the Recovery partition is on the right(and where it should be)... ...and sometime in the past(b/c I suspect the original oobe Recovery
partition was 1 GB) and one or more times Windows Update(when the
recovery had 250 or more free space) shrunk C and enlarged the recovery
to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily indicate
that the Recovery partition was moved from any other location, nor being re-sized by 3rd party application.
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 4/23/2026 2:52 PM, ...w-i|#-o-#-n|# wrote:

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a-a GET-VOLUME
If so, posting information on that results would be a starting point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know
your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into
Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration >>> Information:

-a-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a-a Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
-a-a-a-a Recovery image location:
-a-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a-a Custom image location:
-a-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ] >>> [-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
|-a Disk 0-a-a |-a-a-a-a-a-a-a-a-a-a-a |-a Windows C:-a-a-a |-a-a-a-a-a-a-a-a-a |
|-a Basic-a-a-a |-a-a-a-a-a-a-a-a-a-a-a | 475.65 GB NTFS |-a 1.17 GB |
| 476.92 GB |-a 100 MB-a-a-a | Healthy (Boot, | Healthy-a |
|-a Online-a-a |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the right of Recovery.

-a-a-a Paul

?
Looks like the Recovery partition is on the right(and where it should be)... ...and sometime in the past(b/c I suspect the original oobe Recovery partition was 1 GB) and one or more times Windows Update(when the recovery had 250 or more free space) shrunk C and enlarged the recovery to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily indicate that the Recovery partition was moved from any other location, nor being re-sized by 3rd party application.

I was describing how you would go about fixing the situation.

Currently the OP reports that there is a "blocker" that the
Windows usage of the Defrag API, cannot move.

Third party tools can move it. Some of them will require a
reboot, into some media that comes with the tool, to do the
operation.

I use Linux gparted for this, and have done this a number of
times now, as I experimented with various sizes of Recovery Partitions.

I've already indicated, that in one failure case, I found *two*
WinRE.wim files in the Recovery Partition. But I've only recorded
that situation one time, in all the work I've done on Recovery Partitions.
That would be 2*750MB plus a couple hundred more of slack space,
so maybe 2GB for the Recovery Partition would cover all the
failure scenarios possible.

By doing it this way (Partition Manager), I don't have to lean on PBR resets as often.

A quick test with AOMEI, and a fresh install of Win10, finds no
blocker half way out on the disk. It was a Win10 21H2 (as part
of another experiment). I checked with JKDEFRAG and there was
nothing at the half-way point. As a result, there was no opportunity
to test AOMEI on "blockers". I did manage to move the Recovery
Partition OK and resize it. That part worked.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/23/2026 1:25 PM, Paul wrote:

On Thu, 4/23/2026 2:52 PM, ...w-i|#-o-#-n|# wrote:

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a-a GET-VOLUME
If so, posting information on that results would be a starting point. >>>>> Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know >>>>> your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into >>>>> Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration >>>> Information:

-a-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a-a Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
-a-a-a-a Recovery image location:
-a-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a-a Custom image location:
-a-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ] >>>> [-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
|-a Disk 0-a-a |-a-a-a-a-a-a-a-a-a-a-a |-a Windows C:-a-a-a |-a-a-a-a-a-a-a-a-a |
|-a Basic-a-a-a |-a-a-a-a-a-a-a-a-a-a-a | 475.65 GB NTFS |-a 1.17 GB |
| 476.92 GB |-a 100 MB-a-a-a | Healthy (Boot, | Healthy-a |
|-a Online-a-a |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the right of Recovery.

-a-a-a Paul

?
Looks like the Recovery partition is on the right(and where it should be)... >> ...and sometime in the past(b/c I suspect the original oobe Recovery partition was 1 GB) and one or more times Windows Update(when the recovery had 250 or more free space) shrunk C and enlarged the recovery to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily indicate that the Recovery partition was moved from any other location, nor being re-sized by 3rd party application.

I was describing how you would go about fixing the situation.

Currently the OP reports that there is a "blocker" that the
Windows usage of the Defrag API, cannot move.

Expected. Most likely protected files.
Also, most wouldn't or need to defrag an SSD.

Third party tools can move it. Some of them will require a
reboot, into some media that comes with the tool, to do the
operation.

Afaics, moving via defrag or 3rd party tool is not the necessary or
desired path.

I use Linux gparted for this, and have done this a number of
times now, as I experimented with various sizes of Recovery Partitions.

I've already indicated, that in one failure case, I found *two*
WinRE.wim files in the Recovery Partition. But I've only recorded
that situation one time, in all the work I've done on Recovery Partitions. That would be 2*750MB plus a couple hundred more of slack space,
so maybe 2GB for the Recovery Partition would cover all the
failure scenarios possible.

Yes, I recall that condition, it does not appear to be representative of
Lar's issue.

By doing it this way (Partition Manager), I don't have to lean on PBR resets as often.

A quick test with AOMEI, and a fresh install of Win10, finds no
blocker half way out on the disk. It was a Win10 21H2 (as part
of another experiment). I checked with JKDEFRAG and there was
nothing at the half-way point. As a result, there was no opportunity
to test AOMEI on "blockers". I did manage to move the Recovery
Partition OK and resize it. That part worked.

Good,but afaics, nothing needs to be 'moved' - the partitions(System,
MSR, Windows, Recovery), partition 1, 2, 3, 4. are in the correct order.

Powershell Get-Volume verifed the partitions size and free space.
Reagentc /info verifed the Recovery partition as disk 0, partition 4
Get-Volume or Disk Management does not show MSR partition #2(its not
formatted or labeled) but it is certainly present since Window is left adjacent(thus partition #3) to partition #4(Recovery).
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/23/2026 1:25 PM, Paul wrote:

On Thu, 4/23/2026 2:52 PM, ...w-i|#-o-#-n|# wrote:

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a-a GET-VOLUME
If so, posting information on that results would be a starting point. >>>>> Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know >>>>> your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into >>>>> Powershell, run the command, then copy and paste the results in the
same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------ ----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK -a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration >>>> Information:

-a-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a-a Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0-b542-acabeae3b1dc
-a-a-a-a Recovery image location:
-a-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a-a Custom image location:
-a-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ] >>>> [-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
|-a Disk 0-a-a |-a-a-a-a-a-a-a-a-a-a-a |-a Windows C:-a-a-a |-a-a-a-a-a-a-a-a-a |
|-a Basic-a-a-a |-a-a-a-a-a-a-a-a-a-a-a | 475.65 GB NTFS |-a 1.17 GB |
| 476.92 GB |-a 100 MB-a-a-a | Healthy (Boot, | Healthy-a |
|-a Online-a-a |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the right of Recovery.

-a-a-a Paul

?
Looks like the Recovery partition is on the right(and where it should be)... >> ...and sometime in the past(b/c I suspect the original oobe Recovery partition was 1 GB) and one or more times Windows Update(when the recovery had 250 or more free space) shrunk C and enlarged the recovery to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily indicate that the Recovery partition was moved from any other location, nor being re-sized by 3rd party application.

I was describing how you would go about fixing the situation.

Currently the OP reports that there is a "blocker" that the
Windows usage of the Defrag API, cannot move.

Third party tools can move it. Some of them will require a
reboot, into some media that comes with the tool, to do the
operation.

I use Linux gparted for this, and have done this a number of
times now, as I experimented with various sizes of Recovery Partitions.

I've already indicated, that in one failure case, I found *two*
WinRE.wim files in the Recovery Partition. But I've only recorded
that situation one time, in all the work I've done on Recovery Partitions. That would be 2*750MB plus a couple hundred more of slack space,
so maybe 2GB for the Recovery Partition would cover all the
failure scenarios possible.

By doing it this way (Partition Manager), I don't have to lean on PBR resets as often.

A quick test with AOMEI, and a fresh install of Win10, finds no
blocker half way out on the disk. It was a Win10 21H2 (as part
of another experiment). I checked with JKDEFRAG and there was
nothing at the half-way point. As a result, there was no opportunity
to test AOMEI on "blockers". I did manage to move the Recovery
Partition OK and resize it. That part worked.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

Paul

Sorry for two replies to the same post, meant to include this(in the
other reply)

Same advice, given to mickey earlier in 'Why is my 4th partition almost
full. Do I care' on April 13, 2026 10:36 -700.

Disable all Restore Points
Open Windows Update and toggle off Advanced/Recieve updates for other Microsoft products.
Run DiskCleanup in admin mode, select all options, OK to run(wait for it
to finish, do not interrupt), when done.
Shutdown and Power on the device and boot back into Windows 25H2

Use reagentc /info and /disable then Diskpart in admin powershell or command.com windowpen Powershell or Command.com in an admin mode and
enter each line at the prompt, press return after each entry, repeat
until done with all lines.

The only difference in the diskpart for Lars is the shrink size(850 MB
to resize to 2 GB Recovery partition). Mickey's shrink size to yield a 2
GB Recovery was 904 MB

reagentc /info
reagentc /disable

diskpart
list disk
sel disk 0
list part
sel part 3
shrink desired=850 minimum=850
sel part 4
delete partition override
create partition primary
format quick fs=ntfs label=rCYWindows RErCY
set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes=0x8000000000000001
list vol
exit
reagentc /enable
reagentc /info

----------

Run Get-Volume to show the new size and free space.
Then enable System Restore, update Windows with the latest April
update(not the Preview<g>), check the Recovery Service Pack Build # and
latest date.
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-23 22:17, ...w-i|#-o-#-n|# wrote:

On 4/23/2026 1:25 PM, Paul wrote:

On Thu, 4/23/2026 2:52 PM, ...w-i|#-o-#-n|# wrote:

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for
free space on the disk.
-a-a-a-a GET-VOLUME
If so, posting information on that results would be a starting point. >>>>>> Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know >>>>>> your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into >>>>>> Powershell, run the command, then copy and paste the results in the >>>>>> same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus
OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------
----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:

-a-a-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a-a-a Windows RE location: \\?
\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a-a-a Boot Configuration Data (BCD) identifier: d05140b8-47c2-11f0- >>>>> b542-acabeae3b1dc
-a-a-a-a-a Recovery image location:
-a-a-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a-a-a Custom image location:
-a-a-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ] >>>>> [-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the
left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
|-a Disk 0-a-a |-a-a-a-a-a-a-a-a-a-a-a |-a Windows C:-a-a-a |-a-a-a-a-a-a-a-a-a |
|-a Basic-a-a-a |-a-a-a-a-a-a-a-a-a-a-a | 475.65 GB NTFS |-a 1.17 GB | >>>> | 476.92 GB |-a 100 MB-a-a-a | Healthy (Boot, | Healthy-a |
|-a Online-a-a |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the
right of Recovery.

-a-a-a-a Paul

?
Looks like the Recovery partition is on the right(and where it should
be)...
...and sometime in the past(b/c I suspect the original oobe Recovery
partition was 1 GB) and one or more times Windows Update(when the
recovery had 250 or more free space) shrunk C and enlarged the
recovery to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily
indicate that the Recovery partition was moved from any other
location, nor being re-sized by 3rd party application.

I was describing how you would go about fixing the situation.

Currently the OP reports that there is a "blocker" that the
Windows usage of the Defrag API, cannot move.

Expected. Most likely protected files.
Also, most wouldn't or need to defrag an SSD.

Third party tools can move it. Some of them will require a
reboot, into some media that comes with the tool, to do the
operation.

Afaics, moving via defrag or 3rd party tool is not the necessary or
desired path.

I use Linux gparted for this, and have done this a number of
times now, as I experimented with various sizes of Recovery Partitions.

I've already indicated, that in one failure case, I found *two*
WinRE.wim files in the Recovery Partition. But I've only recorded
that situation one time, in all the work I've done on Recovery
Partitions.
That would be 2*750MB plus a couple hundred more of slack space,
so maybe 2GB for the Recovery Partition would cover all the
failure scenarios possible.

Yes, I recall that condition, it does not appear to be representative of Lar's issue.

By doing it this way (Partition Manager), I don't have to lean on PBR
resets as often.

A quick test with AOMEI, and a fresh install of Win10, finds no
blocker half way out on the disk. It was a Win10 21H2 (as part
of another experiment). I checked with JKDEFRAG and there was
nothing at the half-way point. As a result, there was no opportunity
to test AOMEI on "blockers". I did manage to move the Recovery
Partition OK and resize it. That part worked.

Good,but afaics, nothing needs to be 'moved' - the partitions(System,
MSR, Windows, Recovery), partition 1, 2, 3, 4. are in the correct order.

Powershell Get-Volume verifed the partitions size and free space.
Reagentc /info verifed the Recovery partition as disk 0, partition 4 Get-Volume or Disk Management does not show MSR partition #2(its not formatted or labeled) but it is certainly present since Window is left adjacent(thus partition #3) to partition #4(Recovery).

I am still stuck without a simple way to create the needed 400 MB of
free space in the recovery partition. As I understand it, the path Paul
has suggested is to create a bootable USB stick with a 3rd-party
partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads
here, this is becoming a problem waiting to happen for many Windows-11
users. Every Windows-11 machine I have looked at recently has less than
250 MB of free space in their recovery partition.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 4/24/2026 12:12 PM, Lars Poulsen wrote:

On 2026-04-23 22:17, ...w-i|#-o-#-n|# wrote:

On 4/23/2026 1:25 PM, Paul wrote:

On Thu, 4/23/2026 2:52 PM, ...w-i|#-o-#-n|# wrote:

On 4/22/2026 2:49 PM, Paul wrote:

On Wed, 4/22/2026 5:11 PM, Lars Poulsen wrote:

On 2026-04-22 09:42, ...w-i|#-o-#-n|# wrote:

200 MB free on the Recovery is a concern.

Did you perform the recommended Powershell command suggestion for >>>>>>> free space on the disk.
-a-a-a-a GET-VOLUME
If so, posting information on that results would be a starting
point.
Run the command, copy and paste the results in a reply.

Additionally, for the recovery partition it would be helpful to know >>>>>>> your disk # and recovery partition #

Powershell admin command. Copy the below command, paste or type into >>>>>>> Powershell, run the command, then copy and paste the results in the >>>>>>> same reply.

reagentc /info

Okay, Here goes:

PS C:\Windows\System32> get-volume

DriveLetter FriendlyName FileSystemType DriveType HealthStatus
OperationalStatus SizeRemaining-a-a-a-a-a Size
----------- ------------ -------------- --------- ------------
----------------- --------------a-a-a-a-a ----
-a-a-a-a-a-a-a-a-a-a-a-a-a Recovery-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy
OK -a-a-a-a-a-a-a-a-a-a-a-a 199.92 MB-a-a 1.17 GB
-a-a-a-a-a-a-a-a-a-a-a-a-a SYSTEM-a-a-a-a-a-a FAT32-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy
OK -a-a-a-a-a-a-a-a-a-a-a-a-a-a 31.3 MB-a-a-a-a 96 MB
C-a-a-a-a-a-a-a-a-a-a Windows-a-a-a-a-a NTFS-a-a-a-a-a-a-a-a-a-a Fixed-a-a-a-a Healthy-a-a-a-a-a OK
-a-a-a-a-a-a-a-a-a-a-a 309.88 GB 475.65 GB


PS C:\Windows\System32> reagentc /info
Windows Recovery Environment (Windows RE) and system reset
configuration
Information:

-a-a-a-a-a Windows RE status:-a-a-a-a-a-a-a-a Enabled
-a-a-a-a-a Windows RE location: \\?
\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
-a-a-a-a-a Boot Configuration Data (BCD) identifier:
d05140b8-47c2-11f0- b542-acabeae3b1dc
-a-a-a-a-a Recovery image location:
-a-a-a-a-a Recovery image index:-a-a-a-a-a 0
-a-a-a-a-a Custom image location:
-a-a-a-a-a Custom image index:-a-a-a-a-a-a-a 0
-a-a-a-a-a Windows RE Version:-a-a-a-a-a-a-a 10.0.26100.8235

REAGENTC.EXE: Operation Successful.

PS C:\Windows\System32>

Disk management shows from left to right:

[Disk 0-a-a ]-a-a-a-a-a-a-a-a-a-a-a-a [-a Windows C:-a ][-a-a-a-a-a-a-a ]
[-a Basic-a ][-a-a-a-a-a-a-a-a-a-a ][475.65 GB NTFS][1.17 GB ]
[476.92 GB][-a 100 MB-a-a ][Healthy (Boot,][Healthy ]
[-a Online ][Healthy EFI][ PageF,Crash,B][Recovery]

Does this convey any new information?

That's perfectly normal looking, with the 100MB FAT32 ESP on the
left as the first partition.

+-----------+ - - - - - - - - - - - - - - - - - - - -+
|-a Disk 0-a-a |-a-a-a-a-a-a-a-a-a-a-a |-a Windows C:-a-a-a |-a-a-a-a-a-a-a-a-a |
|-a Basic-a-a-a |-a-a-a-a-a-a-a-a-a-a-a | 475.65 GB NTFS |-a 1.17 GB | >>>>> | 476.92 GB |-a 100 MB-a-a-a | Healthy (Boot, | Healthy-a |
|-a Online-a-a |Healthy EFI | PageF,Crash,Ba | Recovery |
+-----------+ - - - - - - - - - - - - - - - - - - - -+

That's a third party shrink of C:
A third party move of Recovery, to the left.
A third party resize of Recovery, using the freed-up space to the
right of Recovery.

-a-a-a-a Paul

?
Looks like the Recovery partition is on the right(and where it
should be)...
...and sometime in the past(b/c I suspect the original oobe Recovery
partition was 1 GB) and one or more times Windows Update(when the
recovery had 250 or more free space) shrunk C and enlarged the
recovery to its current 1.17 GB.

Based on the information Lars provided, it does not necessarily
indicate that the Recovery partition was moved from any other
location, nor being re-sized by 3rd party application.

I was describing how you would go about fixing the situation.

Currently the OP reports that there is a "blocker" that the
Windows usage of the Defrag API, cannot move.

Expected. Most likely protected files.
Also, most wouldn't or need to defrag an SSD.

Third party tools can move it. Some of them will require a
reboot, into some media that comes with the tool, to do the
operation.

Afaics, moving via defrag or 3rd party tool is not the necessary or
desired path.

I use Linux gparted for this, and have done this a number of
times now, as I experimented with various sizes of Recovery Partitions.

I've already indicated, that in one failure case, I found *two*
WinRE.wim files in the Recovery Partition. But I've only recorded
that situation one time, in all the work I've done on Recovery
Partitions.
That would be 2*750MB plus a couple hundred more of slack space,
so maybe 2GB for the Recovery Partition would cover all the
failure scenarios possible.

Yes, I recall that condition, it does not appear to be representative
of Lar's issue.

By doing it this way (Partition Manager), I don't have to lean on PBR
resets as often.

A quick test with AOMEI, and a fresh install of Win10, finds no
blocker half way out on the disk. It was a Win10 21H2 (as part
of another experiment). I checked with JKDEFRAG and there was
nothing at the half-way point. As a result, there was no opportunity
to test AOMEI on "blockers". I did manage to move the Recovery
Partition OK and resize it. That part worked.

Good,but afaics, nothing needs to be 'moved' - the partitions(System,
MSR, Windows, Recovery), partition 1, 2, 3, 4. are in the correct order.

Powershell Get-Volume verifed the partitions size and free space.
Reagentc /info verifed the Recovery partition as disk 0, partition 4
Get-Volume or Disk Management does not show MSR partition #2(its not
formatted or labeled) but it is certainly present since Window is left
adjacent(thus partition #3) to partition #4(Recovery).

I am still stuck without a simple way to create the needed 400 MB of
free space in the recovery partition. As I understand it, the path Paul
has suggested is to create a bootable USB stick with a 3rd-party partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads
here, this is becoming a problem waiting to happen for many Windows-11 users. Every Windows-11 machine I have looked at recently has less than
250 MB of free space in their recovery partition.

I wouldn't do it that way.

In my earlier reply, I asked for more details on the current recovery partition version and build. Here's the request again.

Open a Powershell or command.com admin prompt window.
Cut and paste the following line into that window.

DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim
/index:1

Report the results(or cut and paste them) in a reply.
We're specifically looking for the ServicePack Build number, and the
last created and modified date.

Once verified, you can use the diskpart method to resize Windows and the Recovery Partition without the need for 3rd party or bootable usb or any
other method.
--
...w-i|#-o-#-n|#
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 4/24/2026 3:12 PM, Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of free space in the recovery partition. As I understand it, the path Paul has suggested is to create a bootable USB stick with a 3rd-party partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads here, this is becoming a problem waiting to happen for many Windows-11 users. Every Windows-11 machine I have looked at recently has less than 250 MB of free space in their recovery partition.

When I tested, there was no structure at all at 50%, so I failed
to reproduce the situation. I know there are definitely blockers
at 50%, because I've had them before and the Shrink Volume would
not go below 50%. When I tried the AOMEI, it had no problem shrinking
C: a lot more than I needed (and it could do that "online" as
there were no blockers). I could also move the Recovery Partition
to the left then, followed by resizing it as desired. The only problem
with AOMEI, is having a numeric display for precise movement of
the sizes I want. In some cases, the GUI is a tiny bit lacking.
Some dialogs have dimensions, and some are just graphical.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

I tried a bunch more archived VHDs I have on the NAS, and none of them have blockers
either. (I use JKDefrag just for the "block view" so I can see where items are located on disk. I am not making any changes at all with JKDefrag. I use it
for surveillance.) CoPilot suggested a list of items that can function as blockers, so I'm going to try that next (after I come back).

https://www.diskpart.com/articles/shrink-volume-beyond-half-its-size-4348.html

pagefile.sys \
hiberfil.sys \____ For sufficiently large C: to begin with, these will
$MFT / be below the middle
$Extend\$UsnJrnl <=== Possible, more research needed
System Restore / Shadow Copies <=== Possible, more research needed
Bad clusters <=== Highly highly unlikely.

You can see in the "style department", AOMEI will be using a reboot
and running from a WinPE, while it does the resize in that case.

I can't easily test those. About the only one easy to run, is
artificially making a Restore Point is easy to do.

*******

I don't know about cumbersome. AOMEI just has to hijack something
to use as a WinPE. It could build its own WinPE. It could use
the WinRE.wim in the Recovery partition (Macrium Rescue CD builder
does that, in the more modern versions of Macrium). It should not
take long to reboot and do the job. Paragon Partition Manager 14 Free
also has a lightweight reboot mechanism (about as lightweight as some
earlier tools that did things like that, the OS item it used came
with the package). Loading WinPE usually takes a bit longer than the
old ways of doing it, but the WinPE is a lot more sophisticated in
terms of subsystems and runtime capability.

This shouldn't take long.

1) Download the free version from the link on the diskpart page.
AOMEI uses the diskpart web domain for advertising articles.
This is what I got while testing yesterday (downloaded from some AOMEI page).

Name: PAssist_Std_20260424.22679053.exe
Size: 86,896,568 bytes (82 MiB)
SHA256: 0C244FF57E35174E9FA017DF06CA54B7EDF5927D164E2ABD22AD44B8D7BBDE2C

2) Install the program. Resize C: with Move/Resize.
The program will prompt for a reboot. Since you are only
making C: slightly smaller, not a lot of movement of files on C:
will be required. It should only take "moments" for this operation
to complete. You're not swinging from the rafters here, and squeezing
all the air space out of C: . Basically, you're just moving the blocker(s)
out of the way.

3) After that process reboots, enter AOMEI again, move Recovery Partition to
the left as your first operation. When it completes, use Move/Resize again
to make the partition as wide as you see fit.

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 4/24/2026 5:06 PM, Paul wrote:

On Fri, 4/24/2026 3:12 PM, Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of free space in the recovery partition. As I understand it, the path Paul has suggested is to create a bootable USB stick with a 3rd-party partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads here, this is becoming a problem waiting to happen for many Windows-11 users. Every Windows-11 machine I have looked at recently has less than 250 MB of free space in their recovery partition.

When I tested, there was no structure at all at 50%, so I failed
to reproduce the situation. I know there are definitely blockers
at 50%, because I've had them before and the Shrink Volume would
not go below 50%. When I tried the AOMEI, it had no problem shrinking
C: a lot more than I needed (and it could do that "online" as
there were no blockers). I could also move the Recovery Partition
to the left then, followed by resizing it as desired. The only problem
with AOMEI, is having a numeric display for precise movement of
the sizes I want. In some cases, the GUI is a tiny bit lacking.
Some dialogs have dimensions, and some are just graphical.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

I tried a bunch more archived VHDs I have on the NAS, and none of them have blockers
either. (I use JKDefrag just for the "block view" so I can see where items are
located on disk. I am not making any changes at all with JKDefrag. I use it for surveillance.) CoPilot suggested a list of items that can function as blockers, so I'm going to try that next (after I come back).

https://www.diskpart.com/articles/shrink-volume-beyond-half-its-size-4348.html

pagefile.sys \
hiberfil.sys \____ For sufficiently large C: to begin with, these will
$MFT / be below the middle
$Extend\$UsnJrnl <=== Possible, more research needed
System Restore / Shadow Copies <=== Possible, more research needed
Bad clusters <=== Highly highly unlikely.

You can see in the "style department", AOMEI will be using a reboot
and running from a WinPE, while it does the resize in that case.

This is just some addendum, so you understand a bit about the blocker,
and what my attempts to look at it are like...

Looking through my notes, when you attempt a Shrink in Disk Management,
it created an event in Event Viewer. I looked through my notes file, for
the word "shrink", and to my surprise saw this text. This could be a shadow copy
for example.

Diagnostic details:
- The last unmovable file appears to be: \System Volume Information\{ab59bee2-c38a-11e2-89db-0003ff781424}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
- The last cluster of the file is: 0x813fff
- Shrink potential target (LCN address): 0x1b883f
- The NTFS file flags are: ---AD
- Shrink phase: <analysis>

So then I had to go look and see if I could reproduce this on something
that has a blocker.

*******

Looking on the other machine, JKFrag (block-viewing mode, not modifying the disk)
tells me there is a blocker half way, on Win10 F: partition.
Notice that the red line is rather long. This particular partition has
been "round the block" and on more than one disk drive, so it's history
is "rich, and forgotten". This is the Win10 on my NAS-like disk set.

[Picture] Win10-F-Test-Machine-blocker.gif

https://postimg.cc/RWJL7wDb

The length of that red line, implies there is also
something bigger up there which could be a blocker.
For JKDefrag, that's not a "blocker", it is merely something that
JKDefrag cannot move at the moment, as JKDefrag doesn't shrink anything.
But the red color is "indicative of trouble".

When I indicate I would like to shrink F: , this is what Disk Management tells me.

-------------------------------------------------------------------------------------------------
eventvwr.msc
Windows Logs
Application
Defrag Event 259

A volume shrink analysis was initiated on volume WIN10 (F:).
This event log entry details information about the last unmovable file
that could limit the maximum number of reclaimable bytes.

Diagnostic details:
- The last unmovable file appears to be: \$MftMirr::$DATA
- The last cluster of the file is: 0x2452d95
- Shrink potential target (LCN address): 0x111237f
- The NTFS file flags are: -S--D
- Shrink phase: <analysis>

To find more details about this file please use the
"fsutil volume querycluster \\?\Volume{c65576d3-4316-4f15-b869-2cd2b3919d60} 0x2452d95" command.
-------------------------------------------------------------------------------------------------

If I use nfi.exe (microsoft utility, available via archive.org now...) to analyze F: then
an awk script, the max sector is

max value is 0X0012296CAF # Divide this sector number by 8 to match Event 259 cluster notation
# and that gives 0x2452d95 cluster number.

Listed by decreasing address (of about 300,000 files), these are at the top of the list.

max value is 0X0012296CAF,
0X0012296CAF,Master File Table Mirror ($MftMirr) <=== the blocker
0X000B1BC9BF,\PROGRA~3\MICROS~1\Search\Data\APPLIC~1\Windows\Windows.edb <=== the next "item" is rather far away
0X000B1B89BF,\PROGRA~3\MICROS~1\Search\Data\APPLIC~1\Windows\Windows.edb so the length of the red line is
0X000B03C127,\PROGRA~3\MICROS~1\Search\Data\APPLIC~1\Windows\Windows.edb coming from some "mystery source"

File 1
Master File Table Mirror ($MftMirr)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 304704680-304704687 (0x12296ca8-0x12296caf) <=== 8 sectors long, or one cluster
That can't be my long red line.

nfi.exe does not appear to list whatever that red line is.

This is how you filter the output of nfi.exe . This is using the GNUWIN32 version of gawk.exe (which is version 3 of GAWK).

********* topfile.awk ************
BEGIN {
#
# topfile.awk processes the output of nfi.exe
# Output format suited to ingestion by spreadsheet, then Data:Sort
#
#**************************
#File 0
#Master File Table ($Mft)
# $STANDARD_INFORMATION (resident)
# $ATTRIBUTE_LIST (nonresident)
# logical sectors 50425824-50426335 (0x3016fe0-0x30171df)
# $FILE_NAME (resident)
# $DATA (nonresident)
# logical sectors 6291456-7340543 (0x600000-0x7001ff)
# logical sectors 93369304-93479895 (0x590b3d8-0x59263d7)
# logical sectors 99118840-99942135 (0x5e86ef8-0x5f4fef7)
# $BITMAP (nonresident)
# logical sectors 64892072-64892319 (0x3de2ca8-0x3de2d9f) #**************************
#
# This strips the punctuation by doing some ORed terms.
# A repeat factor seems to help the OR work. This separator
# is crafted to help with the "logical sectors" line.

FS="[(]*|[)]*|-"
max = 0
filename = ""
filenameisnext = 0

# gawk.exe --non-decimal-data -f topfile.awk nfi-f-out.txt
#
#########################################################
}

filenameisnext == 1 {
filenameisnext = 0
# Need to process arcane line format of nfi, has extra carriage return
#gsub(/[[:punct:]]/, "")
gsub(/\r/,"")
filename = $0
}

/^File / { filenameisnext = 1 }

/logical sectors/ {
cur = 0 + $4
printf("\"0X%010X\",\"%s\"\n", cur, filename)
if (cur > max) max = cur
# exit
}

END {
printf("max value is 0X%010X\n", max)
}
********* topfile.awk ************

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of
free space in the recovery partition.

Have you considered just deleting the recovery partition, expand the C:
drive and living without? Prepare a bootable USB in case of needing to perform maintenance on your Windows install ...

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Sat, 4/25/2026 9:30 AM, Paul wrote:

On Fri, 4/24/2026 5:06 PM, Paul wrote:

On Fri, 4/24/2026 3:12 PM, Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of free space in the recovery partition. As I understand it, the path Paul has suggested is to create a bootable USB stick with a 3rd-party partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads here, this is becoming a problem waiting to happen for many Windows-11 users. Every Windows-11 machine I have looked at recently has less than 250 MB of free space in their recovery partition.

When I tested, there was no structure at all at 50%, so I failed
to reproduce the situation. I know there are definitely blockers
at 50%, because I've had them before and the Shrink Volume would
not go below 50%. When I tried the AOMEI, it had no problem shrinking
C: a lot more than I needed (and it could do that "online" as
there were no blockers). I could also move the Recovery Partition
to the left then, followed by resizing it as desired. The only problem
with AOMEI, is having a numeric display for precise movement of
the sizes I want. In some cases, the GUI is a tiny bit lacking.
Some dialogs have dimensions, and some are just graphical.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

I tried a bunch more archived VHDs I have on the NAS, and none of them have blockers
either. (I use JKDefrag just for the "block view" so I can see where items are
located on disk. I am not making any changes at all with JKDefrag. I use it >> for surveillance.) CoPilot suggested a list of items that can function as >> blockers, so I'm going to try that next (after I come back).

https://www.diskpart.com/articles/shrink-volume-beyond-half-its-size-4348.html

pagefile.sys \
hiberfil.sys \____ For sufficiently large C: to begin with, these will
$MFT / be below the middle
$Extend\$UsnJrnl <=== Possible, more research needed >> System Restore / Shadow Copies <=== Possible, more research needed >> Bad clusters <=== Highly highly unlikely.

You can see in the "style department", AOMEI will be using a reboot
and running from a WinPE, while it does the resize in that case.

An update on using Partition Managers.

1) A second attempt to use AOMEI, resulted in a refusal of it
to do a Move/Resize. A "free" product with a nervous disposition.

2) Paragon Partition Manager 14 Free, continues to function (for as long
as I've had it, it will do a Move/Resize). It reboots, and it took
half an hour to shrink a 500GB partition to 250GB (when the files are
in the lower 80GB of the partition). It puts text on the screen after
a reboot, and the text, I didn't know where (what subsystem) prefers
it that way.

3) I installed Minitool Partition Wizard 13.6 or so.

https://www.partitionwizard.com/offline-download.html

Name: pw-free-offline--Minitool-Partition-Wizard-contains-PUP.exe
Size: 77384904 bytes (73 MiB)
SHA256: 8FEC38F06199D468D6F361C8742283C21DECDBB35227B914A36C2BE76E683F13

It would download some AV where the name begins with an "A" if given
a chance, which is why the testing was done with the Ethernet cable unplugged.

The test disk had two Windows partitions. While booted into Partition 2,
I had it shrink Partition 4 and it did that while Windows 10 continued to run.
It moved the MFTMIRR out of the way (put it much lower on the partition).

The interesting case, was when I was booted on Partition 2 and I asked it to
shrink Partition 2. It wants to reboot. The same kind of text Paragon puts up,
the Minitool tried to put up. In particular, it tried to "lock some memory" on
my 4930K and this was failing to work. The text mentioned
/filesystem/ntfsresize , so it is using a Linux utility (likely the same one
that Linux GParted uses). That means the reboot environment it is using, is
some pared-down Linux setup.

This means, for Lars, the Minitool stands a chance of failing during the
reboot session, after which it returns to Windows again.

That means, so far, Paragon Partition Manager 14 (PM14) appears to be the winner on this round. But if Paragon is also using ntfsresize, you might
as well just boot a Linux LiveDVD/ISO (via Rufus.ie if necessary) and just
do it there with GParted, which would also use ntfsresize and friends.

https://www.majorgeeks.com/files/details/paragon_partition_manager_express_free_edition.html

Whereas this is the one I have on disk. This is an installshield, the Majorgeeks
one is an MSI file.

Name: pm14free_x64_eng.exe <=== the one I'm still using
Size: 53091632 bytes (50 MiB)
SHA256: 7F48097AC70AE6B27FCC5C40A10BBE7E42516DC7D73D0C48ABFFE1D50B2145CF

Name: pm_2014_free.msi <=== the Majorgeeks one
Size: 43603456 bytes (41 MiB)
SHA256: 37B11D8DD6BF53F62BF8197F824A11B3E51835D8A92F0CF10D8058BFB969128A

Paul


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-27 11:39, Paul wrote:

On Sat, 4/25/2026 9:30 AM, Paul wrote:

On Fri, 4/24/2026 5:06 PM, Paul wrote:

On Fri, 4/24/2026 3:12 PM, Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of free space in the recovery partition. As I understand it, the path Paul has suggested is to create a bootable USB stick with a 3rd-party partitioning tool, and use that to move the partition boundary.
That sounds a bit cumbersome and scary. And based on recent threads here, this is becoming a problem waiting to happen for many Windows-11 users. Every Windows-11 machine I have looked at recently has less than 250 MB of free space in their recovery partition.

When I tested, there was no structure at all at 50%, so I failed
to reproduce the situation. I know there are definitely blockers
at 50%, because I've had them before and the Shrink Volume would
not go below 50%. When I tried the AOMEI, it had no problem shrinking
C: a lot more than I needed (and it could do that "online" as
there were no blockers). I could also move the Recovery Partition
to the left then, followed by resizing it as desired. The only problem
with AOMEI, is having a numeric display for precise movement of
the sizes I want. In some cases, the GUI is a tiny bit lacking.
Some dialogs have dimensions, and some are just graphical.

[Picture] aomei-first-test.gif (could only test Recovery Partition move/resize)

https://postimg.cc/bZ4xPYgj

I tried a bunch more archived VHDs I have on the NAS, and none of them have blockers
either. (I use JKDefrag just for the "block view" so I can see where items are
located on disk. I am not making any changes at all with JKDefrag. I use it >>> for surveillance.) CoPilot suggested a list of items that can function as >>> blockers, so I'm going to try that next (after I come back).

https://www.diskpart.com/articles/shrink-volume-beyond-half-its-size-4348.html

pagefile.sys \
hiberfil.sys \____ For sufficiently large C: to begin with, these will
$MFT / be below the middle
$Extend\$UsnJrnl <=== Possible, more research needed
System Restore / Shadow Copies <=== Possible, more research needed
Bad clusters <=== Highly highly unlikely.

You can see in the "style department", AOMEI will be using a reboot
and running from a WinPE, while it does the resize in that case.

An update on using Partition Managers.

1) A second attempt to use AOMEI, resulted in a refusal of it
to do a Move/Resize. A "free" product with a nervous disposition.

2) Paragon Partition Manager 14 Free, continues to function (for as long
as I've had it, it will do a Move/Resize). It reboots, and it took
half an hour to shrink a 500GB partition to 250GB (when the files are
in the lower 80GB of the partition). It puts text on the screen after
a reboot, and the text, I didn't know where (what subsystem) prefers
it that way.

3) I installed Minitool Partition Wizard 13.6 or so.

https://www.partitionwizard.com/offline-download.html

Name: pw-free-offline--Minitool-Partition-Wizard-contains-PUP.exe
Size: 77384904 bytes (73 MiB)
SHA256: 8FEC38F06199D468D6F361C8742283C21DECDBB35227B914A36C2BE76E683F13

It would download some AV where the name begins with an "A" if given
a chance, which is why the testing was done with the Ethernet cable unplugged.

The test disk had two Windows partitions. While booted into Partition 2,
I had it shrink Partition 4 and it did that while Windows 10 continued to run.
It moved the MFTMIRR out of the way (put it much lower on the partition).

The interesting case, was when I was booted on Partition 2 and I asked it to
shrink Partition 2. It wants to reboot. The same kind of text Paragon puts up,
the Minitool tried to put up. In particular, it tried to "lock some memory" on
my 4930K and this was failing to work. The text mentioned
/filesystem/ntfsresize , so it is using a Linux utility (likely the same one
that Linux GParted uses). That means the reboot environment it is using, is
some pared-down Linux setup.

This means, for Lars, the Minitool stands a chance of failing during the
reboot session, after which it returns to Windows again.

That means, so far, Paragon Partition Manager 14 (PM14) appears to be the winner on this round. But if Paragon is also using ntfsresize, you might
as well just boot a Linux LiveDVD/ISO (via Rufus.ie if necessary) and just
do it there with GParted, which would also use ntfsresize and friends.

https://www.majorgeeks.com/files/details/paragon_partition_manager_express_free_edition.html

Whereas this is the one I have on disk. This is an installshield, the Majorgeeks
one is an MSI file.

Name: pm14free_x64_eng.exe <=== the one I'm still using
Size: 53091632 bytes (50 MiB)
SHA256: 7F48097AC70AE6B27FCC5C40A10BBE7E42516DC7D73D0C48ABFFE1D50B2145CF

Name: pm_2014_free.msi <=== the Majorgeeks one
Size: 43603456 bytes (41 MiB)
SHA256: 37B11D8DD6BF53F62BF8197F824A11B3E51835D8A92F0CF10D8058BFB969128A

Paul

I need to confess that I gave up on getting Windows-11 to work at this
time, because my most urgent priority was to get Fedora Linux F43
running again, so I reinstalled Fedora in "take the whole machine" mode.
I suspect that it was a cascading series of problems, beginning
(conjecture) that during the almost 4 months I had not booted into
Windows, the laptop finally became eligible for the 25H2 upgrade, and
that installing the feature upgrade also tried to upgrade the recovery partition, which failed because it ran out of space. And (still
conjecture) it also tried to fix the secure boot key in the EFI
partition, and breaking that too, because that (small EFI partition
served double duty as Linux /boot/efi. Because Linux was installed after Windows, it had been set to boot into Grub, from where I was booting
Windows by selecting "Windows Boot Manager" from the Grub boot menu.
And the Windows update script was not set up to handle this kind of system.

So for now, the little ASUS laptop, purchased for $150 at an
after-Christmas sale in 2022, is a pure Linux machine. Bringing it up
after this re-install has its own issues, but they do not belong in this newsgroup.

Thank you for the detailed responses. I have learned a lot about how the system administration issues in Windows and Linux are both similar, but
also different.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2026-04-25 06:36, Andy Burns wrote:

Lars Poulsen wrote:

I am still stuck without a simple way to create the needed 400 MB of
free space in the recovery partition.

Have you considered just deleting the recovery partition, expand the C: drive and living without?-a Prepare a bootable USB in case of needing to perform maintenance on your Windows install ...

As described in my response to Paul, I decided to just live without ... Windows on that machine for now.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Mon, 4/27/2026 7:20 PM, Lars Poulsen wrote:

I need to confess that I gave up on getting Windows-11 to work at this time, because my most urgent priority was to get Fedora Linux F43 running again, so I reinstalled Fedora in "take the whole machine" mode.
I suspect that it was a cascading series of problems, beginning (conjecture) that during the almost 4 months I had not booted into Windows, the laptop finally became eligible for the 25H2 upgrade, and that installing the feature upgrade also tried to upgrade the recovery partition, which failed because it ran out of space. And (still conjecture) it also tried to fix the secure boot key in the EFI partition, and breaking that too, because that (small EFI partition served double duty as Linux /boot/efi. Because Linux was installed after Windows, it had been set to boot into Grub, from where I was booting Windows by selecting "Windows Boot Manager" from the Grub boot menu.
And the Windows update script was not set up to handle this kind of system.

So for now, the little ASUS laptop, purchased for $150 at an after-Christmas sale in 2022, is a pure Linux machine. Bringing it up after this re-install has its own issues, but they do not belong in this newsgroup.

Thank you for the detailed responses. I have learned a lot about how the system administration issues in Windows and Linux are both similar, but also different.

I still don't know how to Boot Repair Fedora, so don't
break the boot on that. The Yannbuntu Boot Repair disc
doesn't seem to work with Fedora. You'd think GRUB2 is
GRUB2, but for some reason that does not seem to be the case.

After my experience with Paragon PM14 (being for such software,
relatively well-behaved), I thought testing the others would not
reveal such much crap-ware behavior. Boy, was I wrong.

When I tried to run Raxco PerfectDisk (bankrupt and out of business)
in trial mode, and I ticked the box "Prepare for shrink", the
tool responded "this is only available in the Pro version",
and as you can imagine, I set a new record for utility removed
in least amount of time :-) The idea of Prepare for shrink, is
they would move MFTMIRR out of the way.

It would seem, it's going to require a dis-mount of a partition
at a minimum, to do some of these things. A reboot neatly solves
the problem. And the rather cheesy interface on the reboot, means
you're hoping any problems it encounters, it prints a message
on the screen. When it told me it was "ntfsresize", this is my
shocked face :-)

*******

As for Linux installs, I *always* install them in Custom mode.
As that's when I discover some of them don't have partition
preparation capabilities in their Custom section. On one
distro, it does not even inform you what kind of partitioning
it would like. Which is beyond funny. I don't mind using my
available tools here, to prep a disk suited to their liking,
but if you don't tell me what you want, I'm not Kreskin. In
some cases, not even the forum for the product, has a detailed
discussion on that part. I guess "that's too simple for us"
is their attitude.

This is definitely the Year of the Linux Desktop.

Paul


--- Synchronet 3.21f-Linux NewsLink 1.2