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

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

On 2026-04-23 22:17, ...w¡ñ§±¤ñ wrote:

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

On Thu, 4/23/2026 2:52 PM, ...w¡ñ§±¤ñ 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¡ñ§±¤ñ 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?

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.

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¡ñ§±¤ñ
--- Synchronet 3.21d-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.21d-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.21d-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.21d-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.21d-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.21d-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?  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.21d-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.21d-Linux NewsLink 1.2