Resizing volume with DiskPart unsuccessful, while there's enough free space

Question

I have a physical disk with two partitions, an old OS partition (with MBR) of 296GB and a RECOVERY partition of 2048MB (a default DELL recovery partition), both are not in use. I have successfully resized the OS partition from 296GB to 174GB with the following command:

DISKPART> shrink

which shrinks to the maximum shrinkable space. However, the partition only uses 56GB and I want to create a partition of at least under 128GB (to be able to create a VHD of it). When I shrink again, I receive the following error:

DISKPART> shrink desired=50000

Virtual Disk Service error:
The specified shrink size is too big and will cause the volume to be
smaller than the minimum volume size.

According to this post I should defrag, which I did using several tools (open source UltraDefrag seemed to do the best job). It seems that all files are on top of the disk, but how can I check that for sure? And if not, how can I manually defrag/move files, to claim the largest possible consecutive free disk space?

Or: what should I do to shrink the volume to its current used size plus a bit?

(Note: I tried to create a new VHD with the CREATE VDISK command pointing to the oversized VHD for the source-parameter, but here too, the 128GB/137GiB limit prevents success, it seems. Mounting the VHD and shrinking it had exactly the same effect as doing it on the original physical disk, which is why I now try to first limit the physical partition size.)

Solution

It doesn't really matter whether its an OS disk or a data disk. In both cases, the middle of the disk is occupied by $MFTMirr which copies vital bits of the MFT Table. This file is unmovable, even though Microsoft made it available for moving since Windows XP.

So far I have found only one tool that can reliably move these files: PerfectDisk. It has a free, fully-functional, thirty-days version. It can only move these Metadata and MFT files when in offline mode: Select Boot Time on its main tab and either reboot or, if possible, defrag in offline mode. After this, the command SHRINK worked as expected.