0

I asked a very similar question earlier

Previous question:

I've read some guides about resizing the system partition. But they all seem to require the unallocated space to come directly after the partition I want to resize. But I have this:

enter image description here

The only difference between this and the previous question is that this time I'm NOT running Windows in a virtual machine. When I was using a virtual machine, harrymc's answer worked like a charm.

But this time it didn't. I created a bootable usb stick with GParted, booted it up, moved the partition to the end and rebooted. But when I entered Windows, there where no changes. I tried it again while not only moving the recovery partition, but also resizing the C: partition directly in GParted. Again, no changes where visible when I booted back into Windows.

I'm open to the idea to use other tools than GParted. Just need to get the job done.

9
  • You mean that you used GParted to move the 509 MB partition to the end of the disk, but it didn't move?
    – harrymc
    Commented Jul 8, 2021 at 8:25
  • @harrymc Exactly. From what I saw, I got no indication from GParted that it did not work.
    – klutt
    Commented Jul 8, 2021 at 8:27
  • Seems very strange. Try Paragon Partition Manager Community Edition, which has a bootable version (may not be required).
    – harrymc
    Commented Jul 8, 2021 at 8:31
  • 1
    It shouldn't make any difference whether you do this on a VM or real hardware. Are you sure you actually commited the changes made in GParted? Did you check the GParted logs after the attempted partition move?
    – Tonny
    Commented Jul 8, 2021 at 8:32
  • 2
    Please include current screenshots from Disk Management and GParted
    – gronostaj
    Commented Jul 8, 2021 at 8:51

1 Answer 1

3

From the extra information in your last comment I suspect your disk has both a GPT and a (backup) MBR partition table.
This is rare, but not unheard off, especially on a system that has run in UEFI with CSM enabled at some point in its life.
Normally these partition tables contain the same basic information, but somehow they got out of sync.
Windows must have used the GPT and GParted updated the MBR (or vice versa).

The crash caused Windows to verify the boot process and sync both partition tables up again.
Just to be safe have Windows do a full disk check on the C: drive. Windows may not realize by itself that might be needed.

2
  • C: check shouldn't be necessary, as that partition wasn't moved.
    – gronostaj
    Commented Jul 8, 2021 at 13:12
  • @gronostaj It wasn't moved but it's size was altered (enlarged) in a weird way with a crash in between. Better safe than sorry.
    – Tonny
    Commented Jul 8, 2021 at 13:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .