You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: [REGRESSION] Windows Guest BSOD during installation on Linux Host (Kernel 6.18+) #487
Guest OS: Windows 10 22H2.6809 / Windows 11 25H2.7623
Description
Windows 10/11 installation fails with BSOD (varying errors) consistently within 1-3 minutes on Linux kernels 6.18 and newer. The exact same VM configuration and ISO work successfully on Linux Kernel 6.12 LTS.
Troubleshooting Performed
Filesystem Independence: The issue was originally suspected to be Btrfs-related. It was reproduced on a fresh Ext4 partition on a separate physical disk. The crash persists regardless of the underlying host filesystem.
KVM Comparison: Using QEMU/KVM via libvirt on the same Host Machine running the "broken" Kernel (6.18.3), the Windows installation completes successfully.
VBox Configuration: Tested changing hostiocache (on/off) and mtype (normal/writethrough). These changes only delayed the crash but did not prevent it.
Hardware: Reproduced on two different CPUs (Ryzen 5900X and 9950X3D).
Relevant References
This issue was triaged on the Linux Kernel Mailing List (Btrfs). Kernel developers concluded the issue lies within the VBox module handling of newer kernels.
Logs
Please see the attached VBox.log captured after a crash on Kernel 6.18.
It would likely be helpful to have VBox.log of the success scenario as well (same exact host, booted from older kernel; guest install succeeds).
The most comparable logs would come from a deliberate pair of consecutive runs with identical steps, except rebooting the host to the other kernel. No need to finish the guest install, just get it clearly past the point of failure, then tell VBox GUI to shut down the guest (that will leave a clear signal of intentionality in the log).
It is a linux host (manjaro), as far as I understand, HyperV is for windows hosts.
the problem with consecutive runs is, that the problem BSOD occurs at different points in the installation every time. sometimes in the first few screens of windows installer, sometimes after a fully installed OS and then a BSOD appears after installing software like office. So I dont know what you ask of me exactly
Hi, yes, I was mistaken about HyperV. Your log shows that the guest is communicating to VBox using HyperV-style paravirtualization, which is OK (i.e. it is an ad hoc 'standard' shared between various virtualization environments these days).
What I asked is for a VBox.log of a successful boot, under the success conditions. Your report shows 'Working Kernel: 6.12.63-1 (LTS)' -- so, boot the guest while the host is running that kernel; capture the log. Then reboot the host onto one of the newer problem kernels, boot the same guest, capture that log.
Please capture two side-by-side logs (not just a 'success' log to go with the existing 'fail' log). Parts of the guest may have changed since then, e.g. package updates but also just normal filesystem churn. The closer together the two logs are, the more useful.
In fact, being most precise, follow these steps. You will capture first a 'failure' and then a 'success' log:
boot host under a problem kernel (6.18.x / 6.19.x)
boot guest in VirtualBox, proceeding with the guest install until it crashes
save that log
reboot host under not-problem kernel (6.12.x)
boot guest, proceed with install until clearly past the install step where it failed in step 2
tell VirtualBox to shut down the guest, e.g. by closing the guest console window and choosing 'power off'
save that log
The 'success' log will have a clear signal of 'user intentionally shut this down' while the 'failure' log will branch off into the land of shadow...
I experience the exact same problems on Arch Linux and Kernel 6.19.9. During the installation of a new VM (or by running an already installed VM), the VM simply crashes after some time with a BSOD that seems to always show a different error.
I can also confirm, that everything used to be fine before I switched from Manjaro (6.12 LTS) to Arch (6.18 and 6.19 show the same issue). KVM based VMs via libvirt also work perfectly fine for me.
I certainly cannot speak for everyone but I no more see this issue on Arch Linux / Kernel 7.0.3 with virtualbox 7.2.8 r173730 on my AMD Ryzen 7800X3D with a Windows 11 Guest.
Activity
filbo commentedon Jan 18, 2026
It would likely be helpful to have VBox.log of the success scenario as well (same exact host, booted from older kernel; guest install succeeds).
The most comparable logs would come from a deliberate pair of consecutive runs with identical steps, except rebooting the host to the other kernel. No need to finish the guest install, just get it clearly past the point of failure, then tell VBox GUI to shut down the guest (that will leave a clear signal of intentionality in the log).
filbo commentedon Jan 18, 2026
Also, I might be misreading the log, but it looks like it says you're running inside HyperV. Is this:
(1) I'm just misreading it
(2) host is Windows, with explicit HyperV guest running Manjaro, VBox in Manjaro, 2nd-level Windows guest
(3) host is Windows with WSL2, Manjaro installed in WSL, VBox in Manjaro, 2nd-level Windows guest
Nested virtualization is intended to work, but it is a significantly different operating environment and we need to know for sure.
jollycar commentedon Feb 14, 2026
It is a linux host (manjaro), as far as I understand, HyperV is for windows hosts.
the problem with consecutive runs is, that the problem BSOD occurs at different points in the installation every time. sometimes in the first few screens of windows installer, sometimes after a fully installed OS and then a BSOD appears after installing software like office. So I dont know what you ask of me exactly
filbo commentedon Feb 17, 2026
Hi, yes, I was mistaken about HyperV. Your log shows that the guest is communicating to VBox using HyperV-style paravirtualization, which is OK (i.e. it is an ad hoc 'standard' shared between various virtualization environments these days).
What I asked is for a VBox.log of a successful boot, under the success conditions. Your report shows 'Working Kernel: 6.12.63-1 (LTS)' -- so, boot the guest while the host is running that kernel; capture the log. Then reboot the host onto one of the newer problem kernels, boot the same guest, capture that log.
Please capture two side-by-side logs (not just a 'success' log to go with the existing 'fail' log). Parts of the guest may have changed since then, e.g. package updates but also just normal filesystem churn. The closer together the two logs are, the more useful.
In fact, being most precise, follow these steps. You will capture first a 'failure' and then a 'success' log:
The 'success' log will have a clear signal of 'user intentionally shut this down' while the 'failure' log will branch off into the land of shadow...
systemofapwne commentedon Mar 24, 2026
I experience the exact same problems on Arch Linux and Kernel 6.19.9. During the installation of a new VM (or by running an already installed VM), the VM simply crashes after some time with a BSOD that seems to always show a different error.
See my attached logs for more
vbox.log.zip
I can also confirm, that everything used to be fine before I switched from Manjaro (6.12 LTS) to Arch (6.18 and 6.19 show the same issue). KVM based VMs via libvirt also work perfectly fine for me.
systemofapwne commentedon May 2, 2026
I certainly cannot speak for everyone but I no more see this issue on Arch Linux / Kernel 7.0.3 with virtualbox 7.2.8 r173730 on my AMD Ryzen 7800X3D with a Windows 11 Guest.
tomrummet commentedon Jun 19, 2026
I'm experiencing the same issue, but on a Windows 10 VM that a few days ran fine.
I'm running EndeavourOS, uname gives the following.