Cannot boot to boot camp Windows after shrinking the Mac os partition

I have a Macbook pro (Retina, 15-inch, Mid 2014, "El Capitan"), also contained a BootCamp partition - installed Windows 7 after the partition was created, and then upgraded to Win 10 later.


After I used Disk Utility (GUI) to shrink the mac partition, I can't boot into Windows anymore (Mac OS still work, posting the post using it now).


However, in Mac's Finder I can still read the files in the BootCamp partition, seems that the partition is still intact.


Tried building a "USB recovery disk" created from another Windows 10, boot from it, and used its "auto fix" feature, but it didn't work. I can still fire up the command prompt though, so I should be able to do things like bootrec, fdisk etc.


Is my Boot Camp sort of a "Hybrid MBR" thing? I tried to get more info about how my machine's partitioned, but I dare not do anything drastic as I fear that I might broke something again.


  1. What should I do to make Windows work again?
  2. Is there a way to let me back up the partition layout (instead of the partitions themselves) so that if I screwed up fixing the partitions, I can safely return to the point before things were screwed up? I'm sure that the partition info should not take a lot of spaces.


Not sure if it helps, but here is what diskutil and fdisk (in Mac OS terminal) shows (the disk0s4 partition is got as a result of shrinking the Mac partition):


xxxx$ diskutil list

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:                  Apple_HFS Macintosh HD            120.1 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:                  Apple_HFS Untitled                29.2 GB    disk0s4

   5:       Microsoft Basic Data BOOTCAMP                350.0 GB   disk0s5

xxxx$ fdisk /dev/disk0

Disk: /dev/disk0	geometry: 60821/255/63 [977105060 sectors]

Signature: 0xAA55

         Starting       Ending

 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]

------------------------------------------------------------------------

 1: EE 1023 254  63 - 1023 254  63 [         1 -  977105059] <Unknown ID>

 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      

 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      

 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused  

MacBook Pro 15", OS X 10.11

Posted on May 1, 2019 2:50 AM

Reply

Similar questions

33 replies

May 11, 2019 2:42 AM in response to im_chc

Also, I just went ahead and did the bootrec thing. At first the bootrec /rebuildbcd said something like "could not write to disk" (fixmbr and fixboot was fine though).


Then, I rebuilt the Windows Installation boot disk (I downloaded the ISO from Microsoft website instead of using my original Win 10 enterprise ISO) in Rufus, using the non-UEFI option this time ("Legacy BIOS CSM"?).


This time, the other two worked, but /fixboot reported "Access denied". I tried rebooting anyway, AAAAAND....


I saw my Win 10 desktop again! It worked! You are the man LT!

May 8, 2019 3:45 AM in response to im_chc

im_chc wrote:

The ms document said I should try automatic repair first before using bootrec.exe, so should I do so?

Also I did that once already (auto repair), without any effect, would bootrec (/fixXXX and etc) do something that auto repair don't?

Since you have done it once, it will not make a difference, but it is easier to try the Auto Repair. We moved partition headers, which does not lend itself well to Auto Repair, but it will not hurt anything.


For the three kinds of op of bootrec, the fixXXX ones only write to the protective mbr area, so if they put the wrong stuffs, we just rebuild the mbr, right?

We re-built the MBR, but did not tell Windows that we did, but /fixMBR will.

We moved the partition header, but Windows did not move the Boot sector, which /fixBoot will do.

/rebuildBCD corrects any discrepancies between the partition layouts and the information stored in the BCD.


Also, what's the difference between fix boot and fixmbr? From what m$ said they either deal with the boot sector or (mbr minus its partition table). They are pretty much the same to me.

See the previous explanation.

Anyway, if these things are more or less figured out I would proceed to try automatic repair, and then the three bootrec commands.

A 2014 Mac supports both EFI and BIOS boot. Winload.exe is BIOS, winload.efi is EFI. The default is BIOS. Unless you originally forced an EFI installation, we are proceeding with the BIOS mode default as the current installation.

May 5, 2019 9:26 AM in response to im_chc

  • Method 1 - using GParted
    • Convert disk0s4 to Free Space
    • Use GParted to extend Windows to this Free Space
    • Recreate MBR
    • Repair Windows to correct Boot
    • Test


  • Method 2 - using Winclone
    • Backup current Windows via Winclone
    • Use BCA to remove current partition which makes a single partition with all disk space in macOS
    • Use Disk Utility to create a larger FAT32 partition
    • Restore Winclone


You decide which method you want to pursue.

May 5, 2019 7:01 AM in response to im_chc

You can either use Winclone to expand the size of the Bootcamp partition, or use the GParted method. If you mix the two, you will cause more problems than resolve.


If you have a Winclone backup, using BCA, remove the current Windows installation. Use Disk Utility to create a FAT32 partition of the size you want Windows to be, and restore the Winclone backup.

May 2, 2019 2:02 AM in response to Loner T

A few more questions:


  1. If I am to back up the bootcamp partition, can I use WinClone?
  2. To GParted, expanding the bootcamp partition to take up the free space of disk0s4 is like expanding an ordinary GPT partition, right? From the perspective of Windows, nothing has changed, since the MBR info before and after the expansion stays the same (by using GPT fdisk I saw that it contains a protective MBR instead of a Hybrid so I think all of the MBR info is toast) .... What I'm trying to say is, I might consider to leave the free space alone and just make Windows bootable again, if the GParted expansion thing is risky or something... so if I leave the space alone, I just need to use the USB Installer, right?
  3. Is a (pure) GPT-based Windows 10 more performant than a Hybrid-MBR? I'm not sure if it is Hybrid or not before I screwed the disk up. I think now it is already a GPT partition. Would the USB installer hybridize the partition again?


If the de-hybridize thing makes things complicated to you, then forget it (I think it might need reinstalling Windows anyway... even if it doesn't, if it makes the config more prone to errors/config mistakes or incompatible with Apple stuffs, then I will just give it up) ... Sorry for having so many questions!

May 5, 2019 4:56 AM in response to Loner T

Hi LT, sorry for being MIA for so long. Here's the update:

  1. bootcamp backed up
  2. used diskutil and GParted to expand the bootcamp partition (I allocated a further like 50GB of space)
  3. used the win 10 installer to do "startup repair"


During the time it was smooth and uneventful.


But unlike what I expected, after all of those, I wasn't able to boot windows up ("Missing Operating System")


My installer USB is created in Rufus with the UEFI option selected, does it matter?

Or, in gdisk I spotted the "SIP not deactivated" thing, I think I have missed that out, but would like to know I should redo it at this stage.

May 5, 2019 8:23 AM in response to Loner T

I didn't use Winclone to alter disk0's partition, but I used "disk utility (GUI)" (shrinking Mac Partition) and GParted (expand bootcamp) to do so.


So in other words I only used one tool on the bootcamp one.


Do I really need to use BCA to remove Windows and restore the backup? I do have a backup, but am wondering what is out of order? Seems to me that disk0 is already in GPT format already, before I used GParted (unless I got the meaning of the output below wrong):


(Quoted from the text of the question:)
xxxx$ diskutil list

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.3 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:                  Apple_HFS Macintosh HD            120.1 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:                  Apple_HFS Untitled                29.2 GB    disk0s4

   5:       Microsoft Basic Data BOOTCAMP                350.0 GB   disk0s5

Also, I can see the bootcamp drive in Finder, I picked a few text files for a look, seems fine to me.

I'm a bit panicking tbh.


May 5, 2019 11:27 PM in response to Loner T

I have been following method 1.

Since I think I've done (1) and (2), is it "Recreate MBR" that I missed, causing (4) to fail?


Also, the partition sizes of gdisk and diskutil list seem to be out-of-sync (e.g. 619.9 vs 650 for "Recovery HD"), I'm worrying that I made something wrong previously.


Again, thanks for your patience!

May 7, 2019 7:43 AM in response to im_chc

After 12 & 13, it said failed to write to disk

I've rebooted to Mac's recovery partition and did csrutil disable, and redo it from step one to the last. I reboot straight into Windows and it said an error occurred, like winload.exe and code 0x0000225, and "a required file is missing or contains errors".


I searched for the error and seems that it means the .efi file is missing.

Should I use the windows installation USB to perform the startup repair?

May 7, 2019 3:21 PM in response to im_chc

Disk0 or rdisk0 work. Either should be fine. The 'r' version is the raw disk.



 ls -l /dev/*disk*

brw-r-----  1 root  operator    1,   0 May  6 21:50 /dev/disk0

brw-r-----  1 root  operator    1,   1 May  6 21:50 /dev/disk0s1

brw-r-----  1 root  operator    1,   5 May  6 21:50 /dev/disk0s2

brw-r-----  1 root  operator    1,   6 May  6 21:50 /dev/disk0s3

brw-r-----  1 root  operator    1,   3 May  6 21:50 /dev/disk0s4

brw-r-----  1 root  operator    1,   2 May  6 21:50 /dev/disk0s5

brw-r-----  1 root  operator    1,   4 May  6 21:50 /dev/disk0s6

crw-r-----  1 root  operator    1,   0 May  6 21:50 /dev/rdisk0

crw-r-----  1 root  operator    1,   1 May  6 21:50 /dev/rdisk0s1

crw-r-----  1 root  operator    1,   5 May  6 21:50 /dev/rdisk0s2

crw-r-----  1 root  operator    1,   6 May  6 21:50 /dev/rdisk0s3

crw-r-----  1 root  operator    1,   3 May  6 21:50 /dev/rdisk0s4

crw-r-----  1 root  operator    1,   2 May  6 21:50 /dev/rdisk0s5

crw-r-----  1 root  operator    1,   4 May  6 21:50 /dev/rdisk0s6

May 7, 2019 7:22 PM in response to Loner T

The ms document said I should try automatic repair first before using bootrec.exe, so should I do so?


Also I did that once already (auto repair), without any effect, would bootrec (/fixXXX and etc) do something that auto repair don't?


For the three kinds of op of bootrec, the fixXXX ones only write to the protective mbr area, so if they put the wrong stuffs, we just rebuild the mbr, right?


Also, what's the difference between fix boot and fixmbr? From what m$ said they either deal with the boot sector or (mbr minus its partition table). They are pretty much the same to me.


Anyway, if these things are more or less figured out I would proceed to try automatic repair, and then the three bootrec commands.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Cannot boot to boot camp Windows after shrinking the Mac os partition

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.