Bootcamp Legacy Windows Startup Issues

[JedNZ]

RefindPlus Version

v0.13.3.AA Release

Device Type

Apple Mac

Problem Description

I'm running MyBootMgr 0.8.2a on my cMP 4.1>5.1. OC and OC_ALT are both working fine booting to macOS 11.6.8. I can also boot natively to Mojave from the RefindPlus screen, however I can't boot to my Windows 11 SSD - instead it gives me a screen full of text and then stalls - it never gets to the Windows logo.

The Windows 11 SSD boots fine in Parallels, so I know it does run.

The text that scrolls on the screen includes multiple entries starting with efi_fusion_pairing... and APFSStart ... Mounting with apfs_efi_osx-...

I can see there is an extra x64_ExFatDxeLegacy.efi file now in the BOOT > drivers folder - do I need to remove that maybe?

I had no issues booting the Windows 11 SSD (which is in SATA bay 1) on my previous version of MyBootMgr v0.7.9b, so I'm guessing something in the RefindPlus EFI>BOOT folder has changed such that it's causing interference with Windows booting.

I have compared the config.conf files of both versions with FileMerge but can't identify from the changes what might be causing the issue.

I appreciate any help to problem solve this.

Problem Point

While starting a loader or tool

Affected Items

WinOS Loader

Debug Log

config.conf files located

Additional Context

22p01k4057.log

opencore-2022-08-01-104211.txt

DebugLog_ConfigFactory.log

[startergo]

Can you boot Windows from Open Core?

[dakanji]

Thanks for reporting this issue. Please add a debug log as required by the issue template. You can drag and drop the file on the text field to upload it.

[JedNZ]

I've never run my legacy Windows setup via OpenCore. I don't have OC even set up to list Windows in my picklist.

I'll do a sudo nvram -c to see if something in NVRAM is interfering with my Windows boot.

[github-actions[bot]]

This item has been flagged for closure due to missing required information.

[JedNZ]

Log files added: the first one above is in the root folder of my EFI boot partition; the second one is inside the EFI/EFI folder; and the third was inside my MyBootMgr folder. Hoping this is what you wanted (couldn't find any other log files).

[dakanji]

Thanks. Please run the Debug file again and attach a log from an attempt to load Windows (The problem item). You can attach such to replies instead of the original post from now on.

[JedNZ]

I'm a little stuck. How do I run the Debug file again? Do you mean, just restart and try and run Windows again? And do I grab log from the EFI/EFI folder, or the DebugLog_ConfigFactory.log?

[dakanji]

Yes, just restart and try to run Windows and grab the RefindPlus log file produced in the EFI folder later.

You might need to force shutdown and reboot into something that works such as OpenCore. In this case, you will have a log file for that second one as well and need to take the first log file produced for the Windows attempt (not the second one).

Obviously need to have the debug file active and not the release file; as that does not create log files.

[JedNZ]

I selected my Windows drive in the RefindPlus menu, and got the same text scrolling issue and hang. I had to do a long press on the power button to shut down.

But something I've noticed: On the next reboot, from the RefindPlus screen I booted into my BigSur drive via OC. When I mounted the EFI partition the only log files were dated/timed from last evening. It wasn't until I rebooted again that the most recent log files showed up. I've noticed this behaviour since I upgraded to MyBootMgr 0.8.2a - fairly certain the log files always showed up immediately after a reboot with previous versions.

So attached below are two sets of the log files - the first lot are dated last evening, and the second lot are from attempts today.

Last evening: 22p01y2316.log opencore-2022-08-01-222424.txt

And the most recent files (I had to boot a second time via OC in order for the log files to show up in the EFI and EFI/EFI folders): 22p02f2632.log opencore-2022-08-02-052703.txt

[dakanji]

Noted. Will have a look later. You can ry removing the ExFatDxeLegacy driver to see whether it affects the appearance of the log files (Regarding your earlier queries, the driver is not related to the boot issue).

[JedNZ]

Removing the ExFatDxeLegacy driver fixed the issue with the logs not showing up straight away. Attached are the latest logs after trying to boot into my Windows SSD again, without success, again.

22p02i3942.log opencore-2022-08-02-084019.txt

[dakanji]

The attached log seems to be from a boot into OpenCore and not the failed Windows attempt. Same applies to those in your earlier post.

[JedNZ]

Booting into Windows failed very early. I could see the RefindPlus Windows logo, and immediately the text was drawn on the screen. It did not get to the Windows logo. Not sure what I have to do to get you the Windows log.

[dakanji]

Not sure what I have to do to get you the Windows log.

Been asking for the log file created by RefindPlus when you tried to boot into Windows (and it failed) in order to understand what is happening. A log of a boot into a working item does not include information about what might be happening when it fails.

Seems you are just taking the last (working) log file but I need the log created before that (when it failed).

Explained here: https://github.com/dakanji/RefindPlus/issues/119#issuecomment-1201751069

[JedNZ]

The log files above are the only ones generated I can find on my EFI partition. I think that because Windows boot fails before it can do anything, no logs are generated.

I'll have to revert back to MyBootMgr 0.7.9b in the meantime as I have a job that needs to be completed in Windows.

If it's any consolation, I haven't be able to boot to Windows with any of the MyBootMgr v0.8x versions so maybe they changed something that's broken my setup.

[dakanji]

RefindPlus logs are generated by RefindPlus and not by an OS. The logging starts immediately RefindPlus starts before you decide what you want to boot. That is, logging is not related to success or failure of the loader and a big part of the logging is precisely to record success or failure.

Furthermore, it is not possible to run a RefindPlus debug build file without it generating a log file.

[JedNZ]

I booted natively into Windows 11 and updated the OS and did some other maintenance (unknown if this had any real affect on what happened next). I then updated to MyBootMgr 0.8.3 and successfully booted into my Windows 11 SSD.

I'll compare the DebugLog_ConfigFactory files (v0.8.2a vs v0.8.3) to try and see any differences that might explain the issues I had, and will report back.

[JedNZ]

I can't see much difference in the ConfigFactory build logs below, certainly not anything that might prevent Windows from booting up.

082a DebugLog_ConfigFactory.log 083 DebugLog_ConfigFactory.log

[dakanji]

RefindPlus runs some checks on volumes to determine whether they are bootable APFS volumes. This test should fail without issue on any non-APFS volumes but it appears Bootcamp volumes created by Mac OS running APFS (or maybe just recent APFS Mac OS) has some APFS "bootcode" (for lack of a better term) embedded. This appears to have been the reason for the issues when trying to boot instances of Bootcamp Windows.

The issue is effectively the same faced by @ehDub here: https://github.com/dakanji/RefindPlus/issues/114. Not sure what the outcome for him was but he seemed to be on a right track of fixing the disk bootcode.

The APFS check was extended in recent versions of RefindPlus which appears to be why this issue only affected the last few instances of RefindPlus. Windows instances created without using Bootcamp, such as by following this linked process, were not affected.

MyBootMgr v083 comes with a build of RefindPlus where extra filtering is done before running the check since the check itself seemed to be what causes the problem to break out. Almost a form of Don't Ask, Don't Tell.

I would call it a bug in Bootcamp but I am sure Apple will say it is a feature and so, it has to be seen as a RefindPlus bug. I will just tag this as a Known-Issue and the fix will make its way into the codebase here for release in due course.

[github-actions[bot]]

This item is being closed as a known issue.

[ehDub]

Unfortunately I broke the Windows 10 BCD repairing the GPT header of install I was having trouble with before I could test any fixes. Then I got the plague and am only now revisiting it. I had installed it to configure GPU UEFIs for Opencore and its work was done there so it was no great loss. I thought I'd simply reinstall on an SSD but found I can no longer boot the Windows ISO DVD I used for that install, numerous attempts with different methods all failed with ACPI BIOS error or no display with Win 7. Thanks for the WM tutorial link Dayo, I shall certainly try it.