Windows 10 Anniversary + Boot Camp = no longer mounting Mac partition

Apple HFS+ drivers themselves work fine after updating to the 1607 (anniversary update). They just have problems mounting the drives. You have to devise some method for mounting them manually. I can suggest two options;

Option#1, by using ext2fsd software;

-Install 6.0 drivers just like before anniversary update, reboot the windows. Nothing will show up...

-Download ext2fsd even though you probably have nothing to do with ext2 or linux.

-Open Ext2 Volume Manager. In "File System" tab, your macOS partition will show as "HFS". If you installed ext2fsd before succesfully installing bootcamp drivers, it will just show as "RAW". (kind of proving bootcamp drivers DO work)

-Right click, select assign drive letter (or change drive letter).

-In the pop-up menu, select the drive letter first, then select the tick "Create a permanent MountPoint via Session Manager." It -weirdly- closes the pop-up before you click "OK". (Ext2fsd is a little buggy, you should select drive letter first, then select the tickbox. If you want to change drive letter, I suggest removing the existing one first, then re-add it from scratch)

-Reboot, and the macOS partition will be there just like before anniversary update. (On one of my computers, it didn't show on first reboot, I've gone into ext2 volume manager, redid everything then rebooted, it showed on second time.)

Option#2, mounting via Dos Devices registry edit (ext2fsd does exactly this, this is the manual way without using ext2fsd);

Run regedit, navigate to:

HKEY_LOCAL_MACHINE/system/CurrentControlSet/Control/Session Manager/DOS Devices/

Right click-> new-> add string.

Enter drive letter you want by adding ":" to the end. In "data", type "\Device\HarddiskVolume#" where # will be your volume number of your partition as it would be detected in MS-DOS. I am sure someone would suggest a more elegant solution for this one, but you can simply navigate to Control Panel/Administrative Tools/Computer Management/Storage/Disk Management and count your partitions from beginning starting with 1. In my example, I have 1 partition on disk0, and my macOS partition is 2nd one in disk1. So my volume number # is 3.

In my registry it is "G:", "REG_SZ" and "\Device\HarddiskVolume3" for name, type, and data respectively. Your letter and numbers will be different, of course.

After making the registry tweak, cross fingers and reboot, macOS partition should be there. If something else is mounted instead, check volume number.

You can -probably- do trial and error on volume number, as long as you don't put a drive letter that contradicts with anything you already have (If you accidentally put your windows volume with a different drive letter, it will just mount it twice, nothing bad will happen. If you put different volume onto same drive letter you risk breaking your boot.)

Also one user in the first forum I've posted this workaround has installed ext2fsd, mounted his macOS partition, navigated to registry, noted the letter and volume number, then uninstalled ext2fsd, and re-added the registry entry with the same letter/volume number.

Hope this helps.

Andraxxus wrote:

Apple HFS+ drivers themselves work fine after updating to the 1607 (anniversary update). They just have problems mounting the drives. You have to devise some method for mounting them manually.

You can -probably- do trial and error on volume number, as long as you don't put a drive letter that contradicts with anything you already have (If you accidentally put your windows volume with a different drive letter, it will just mount it twice, nothing bad will happen. If you put different volume onto same drive letter you risk breaking your boot.)

On 1511 (_1 and _2), notice there is no Registry entry for DOS devices pointing to disks as shown below.

You can not only break, but corrupt file systems, causing data loss. Think of mounting NTFS in place of FAT or vice-a-versa. Before the Registry addition, what does Diskpart show? This is on 1511_2.

I understand all users want it to work, but to make it work properly should not require 'manual' registry edits, should it?

"On 1511 (_1 and _2), notice there is no Registry entry for DOS devices pointing to disks as shown below."

Indeed there is not. You have to understand windows' own mounting system is different than Session Manager.. With or without registry addition, diskpart on 1607 doesn't detect HFS partition as volume. Same goes for Disk Management, it says "healty partition" no mention of filesystem type or drive letter.. Though on Disk management, I can't change another drives letter to the ones I've mounted via Session Manager. It knows its allocated. To answer your question directly however, I have 14 volumes, "list volumes" in diskpart show 12, completely ignore the two HFS partitions I have.

I am fully aware AppleMNT.sys is a kind of System Bus Extender driver, doing things the proper way, and my suggestion is just a workaround. It mounts like a DOS Device (in analogy, very much like a COM or printer port), then already loaded AppleHFS driver reads it. Without HFS driver, it reports as "unformatted".

If I were to right click on my macOS partition, it properly detects filesystem, used and free space. I can read and copy from it, I am posting a screen shot as -kind of- proof. I've just copied AppleHPET.kext to windows partition and opened version.plist via notepad:

Since you have 1511 with properly mounted drivers, you can compare with this behaviour: I were to try to delete something or try to copy something to it error message says "An unexpected error is keeping you from deleting the folder...blah blah blah.... Error 0x80070057: The parameter is incorrect". What happens when you try the same?

"You can not only break, but corrupt file systems, causing data loss. Think of mounting NTFS in place of FAT or vice-a-versa."

From my personal observation (of making the mistake you mention) this is not the case. System will just mount one of the drivers first, which is almost random (not *really* random but on some order only windows knows, it doesn't change with each reboot). If it mounts the DOS device first it will assign another letter to windows partition. If it mounts the windows partition first, then DOS device is just not get mounted. Every -succesfully- mounted device is still accessed with the intended filesystem, however. I -repeatedly- had conflicting drive letters on NTFS and ext2 partitions, never had a problem. Though automatic changing of drive letters do have a clear risk of making computer unbootable, I don't know it still applies to EFI boot...

"I understand all users want it to work, but to make it work properly should not require 'manual' registry edits, should it?"

Well to make it REALLY properly, Apple needs to write a windows driver that actually works with the windows version they claim to support. Their choice was to get rid of the HFS driver altogether, and my guess is we won't be seeing a HFS driver from them like ever. OK, that is their choice, but I think its also OK to resort to less proper methods to get the functionality I want 😁.

Proper or not, my way just works. Granted its a workaround, and granted there may be unforeseen consequences. I use ext2fsd to mount my ext2 and ext4 partitions via Session Manager for 3-4 years, I use same method for mounting HFS for 2 weeks, I have yet to encounter a problem; be it disks not mounting, corrupting etc. I can't say anything more assuring than that. "Try it at your own risk" 😁

I am having the same problem and, of course, it worked fine before the Anniversary update. I have since installed the new beta for testing purposes and unfortunately the problem still isn't fixed. I am on Windows 10 Pro Insider Build 14986 which was just installed the morning. I have not uninstalled the BootCamp 6 drivers and reinstalled them yet with this build (although I did attempt this on the Anniversary update with no success). I will try to do this later on today and report back hopefully with good news.

@Andraxxus: Thank you SO much, this helped me 🙂 (after 3 months of weirdly fooling around in the furthest corners of no-where...)

For all the frustrated folks out there - here's the gist of how the MacOS-Partition became visible again on W10 1607:

- You need to install the old BootCamp 6.0 Driver-Package - 6.1 (Sierra) does not contain the HFS-drivers anymore.

- If you don't have / can't get the 6.0 - you can get it even from Sierra! You just have to enforce an external USB-Install there, instead of the internal one (via a temporary SSD-Partition). Just leave a reply.

- My MacOS-Partition became visible again just by tweaking the Windows-Registry - ext2fsd wasn't necessary.

- The relevant volume should be #2, at least on a standard-BootCamp-Installation with one single Harddrive.

Does anyone of you have any contacts into Apple? I would love to know if there's any reaction from them to Andraxxus' simple solution - or if they've completely skipped any efforts on that issue for the existance of CoreStorage & iCloud... 😉

Glad it was helpful 🙂. I was on the same bus for months too, and the "use 1511" suggestion was not even funny, W10 was almost a beta before 1607..

Another option would be to extract HFS+ drivers from 6.0 (using external drive is a good idea), then make the installation with 6.1 drivers. It wouldn't matter much today, but as new bootcamp drivers emerge to support new macOS and Mac hardware, having these HFS+ drivers at hand should be relatively future proof.

Those drivers (AppleHFS.sys and AppleMNT.sys) can be installed "manually" by registry tweaks as well.

My bug report 27739034 was closed by Apple Engineering with the following (and I quote)

"There are no plans to address this based on the following:

We have no plans to support this feature. This driver is not compatible with core storage which is the default for Macs. The driver is no longer bundled with SW downloads or supported in Win10.

We are now closing this report."

and my bug reports reads

"

BC 6.0.6136 package provides AppleHFS.sys and AppleMNT.sys. These two drivers work properly with Windows 10 build 10586 (Win10_1511_1_English_x64.iso) but they fail to work properly on Win10_1607_Engish_x64.iso.

"

And my understanding is that there are currently no plans to support a CoreStorage driver, which is also used if FileVault2 is used. BitLocker also has similar challenges.

I understand the workaround, and as long as users understand the risks and are vigilant, it should be fine. Newer Macs require a manual CS revert to expose the encapsulated JHFS+ file system.

EFI boot has the same issues as BIOS vis-a-vis drive letter changes. The Windows BCD references are problematic in either case. C: being the lowest drive letter, it has some safety, but D-Z are open for potential conflict.

I think there are two seperate events here.

#1 W10 1607 does break mounting of HFS drives, irrelevant of whether CoreStorage is supported or not.

#2 Apple had already decided to prefer encryption and relatively useless perfomance features like Fusion drive over interoperability with Windows, and was never planning to continue HFS drivers anyway... When drivers stop functioning by coincidence, they didn't bother making an update for them..

So problems -and risks- you mention regarding CoreStorage is valid, but irrelevant to version of Windows or Bootcamp people are using. It should be disabled in both proper and improvised methods of mounting HFS partition, and it will blew one day if/when an macOS update decides to enable it for good, even for 1511 or even Win8 users... Correct me if I am wrong, but not even Paragon HFS or MacDrive would work with CoreStorage + FileVault active?

#1 and #2 may be separate user events, but they are related.

I am glad that OS X still allows me to extract the JHFS+ from CS under the right conditions. When OS X stops doing that then it becomes a larger issue.

Andraxxus wrote:

When drivers stop functioning by coincidence, they didn't bother making an update for them..

Why did they stop functioning in 1607 when they work in 1511? The root cause has never been addressed. As you have shown you are manually assigning a drive letter. If I plug in additional HFS+ partitions/disks, they are assigned drive letters automatically in 1511, but not in 1607.

So problems -and risks- you mention regarding CoreStorage is valid, but irrelevant to version of Windows or Bootcamp people are using. It should be disabled in both proper and improvised methods of mounting HFS partition, and it will blew one day if/when an macOS update decides to enable it for good, even for 1511 or even Win8 users... Correct me if I am wrong, but not even Paragon HFS or MacDrive would work with CoreStorage + FileVault active?

Unless Apple licenses CS (or someone publishes a reverse-engineered driver like DVD CSS), no third-party products currently work with CS. It is surprising that third-party drivers have not shown up for this long.

Hi Eipok,

I performed the Windows-registry-tweak that @Andraxxus' had posted here on Jan 12, and it's working perfectly since then - just like I knew it from W10 1511 + El Capitan.

I didn't need any third-party-software (not even ext2fsd), and I haven't encountered any issues so far - although I can only speak for a standard-Bootcamp-setup with just one single HD (the relevant volume # for the tweak is #2 then).

The only problem is that you need to have the old bootcamp 6.0-driver-package installed on your Windows-side (from El Capitan), since Apple has skipped any HFS-support with Sierra / bootcamp 6.1.

If you don't have the 6.0-driver-package at hand (or at least it's HFS-drivers) - I've described an alternative way to get it downloaded even on Sierra, in my Jan-12-post.

Best regards

André

I used Option 2 to get my HFS Mac drives recognized again in Windows 10 Pro. Thank you for posting a workable solution. One note to those trying this: Make sure when you count your number of volumes, you exclude any partitions labeled as "Unallocated", even though they may show some megabytes of used storage. In Windows' Disk Management, these partitions may be represented with a black bar, rather than a dark blue bar for all other allocated partitions.

I was holding off to see cheers or jeers... started googling tonight and found this Apple community and a Slashdot post which in particular is disconcerting:

https://linux.slashdot.org/story/16/08/03/1614223/windows-10-anniversary-update- borks-dual-boot-partitions

The report mentioned in SlashDot is here:

http://windowsreport.com/partition-disappears-windows-10-anniversary-update/

... and it mentions a MiniTool Partition Wizard app. I'm looking at the site; looks free. I would try to download that in Windows and without committing to any modifications, driver changes, etc. does it "see" the HFS+ partition?

Hmm... If the HFS+ read-only Windows driver is not being loaded, and downloading the Boot Camp driver package does not reinstall it, I would try opening an elevated command prompt (Start menu > type cmd > press Ctrl+Shift+Enter for command prompt to Run as Admin) then enter

sfc /scannow

It should return "No integrity violations found". If it says "some corrupted files were found and repaired", reboot, do the same again, then it should say no integrity violations found.

Do you have FileVault? Try disabling that... might be this old issue, but the driver locations are noted here:

HFS+ Drive not visible on Windows 10 Bootcamp partition with support software

If that does not do it, I would try Apple Software Update, and if it's not critical, wait a few days for 1) a Microsoft update for Windows 10 build 14393 or version 1607, and/or 2) an Apple update to the Boot Camp driver package -- again. Then install the whole thing again.

* Apple literally can change the Boot Camp Win driver package weekly, if not more often, with no versioning changes, no notifications, etc. Remember... it's "unsupported"!! My AMD graphics card drivers is how I found that out...

Two Boot Camp updates repeatedly offered in Apple Software Update (ASU)

The main point being... don't "repair" BCD (boot config data) in Windows or anything else that might endanger the partition. If you approach it from the Windows viewpoint, you will most likely lose non-NTFS partitions if the GUID Partition Table (GPT) is altered. If you can boot into Mac OS, the partition is okay, it's just a Windows issue that hopefully Apple can issue a driver update for or Windows can issue a partition map fix for, since it does not seem limited to OS X (based on all the Linux partition issues people have posted)...

Like someone said in reddit "This is Microsoft's punishment for seeing other operating systems on the side" lol