The dual-boot bug which causes Windows to go unresponsive
Posted by Howard Richardson (comments: 0)
My newest PC build has been plagued by a problem which I've not encountered before I upgraded my chipset. The machine is a dual boot, Windows 10 and OpenSuSE 15.2. Recently the Windows 10 installation will freeze immediately on logging in. Menus and search bar won't respond, apps start at 1% of normal speed - basically everything grinds to a halt. If you open This Computer view on Explorer you see a never-ending progress bar, as if it's scanning for new drives or waiting for a DVD to spin up. Occasionally you get weird errors like "Unknown Hard Error", but Googling these never brings you any answers apart from copy-pasted advice to reinstall Windows or update drivers.
Through a lot of trial and error I've got to the bottom of it, and curiously it has nothing directly to do with Windows. It seems to be a problem with GRUB2 and identifying drives. When you boot through GRUB2 (EFI, secure boot enabled) you get the problem. When you choose the Windows bootloader directly from BIOS boot screen the issue goes away.
The tricky thing is that the problem seems intermittent. The system will run for weeks being fine using GRUB and then suddenly this problem will start. What's happened here, I believe, is that OpenSuSE has done an update that requires reinstalling GRUB or rebuilding the initial RAM disk, and it gets something wrong which then causes the problem with the drives in Windows.
The fix for the GRUB2-caused Windows 10 freeze
I've determined that if the Windows drive is properly mounted at the time GRUB does its install then everything works fine. However if the drive is inaccessible, perhaps due to being in a hibernated state or having filesystem errors, then the detection goes awry. Windows 10 will still show in the boot menu but when you choose it you encounter the problems I mentioned.
The fix for this when it occurs is this:
- Cleanly unmount the Windows 10 drive from Windows. This will mean booting and then shutting down fully (not hibernating) from the login screen. This might also need you to run CHKDSK on the drive by booting into Windows successfully using the BIOS boot drive menu (F8 after power-on on my machine).
- Mount the cleanly unmounted Windows drive inside Linux.
- Run the YaST Bootloader install again. You can leave everything set at the defaults. It just needs to run through once so that the install-time detection of Windows works correctly.
- Your system should be good until the next time this occurs. You can probably avoid this in the future by making sure the Windows drives are cleanly mounted whenever you apply a kernel or GRUB update.
Let me know if this fix works for you too!