[REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[jollycar]

#regzbot introduced: v6.12..v6.18

[1.] One line summary of the problem:
VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)

[2.] Full description of the problem:
Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.

[3] Kernel & Hardware:
   - Kernel versions tested:
     * Working: 6.12.63-1
     * Broken: 6.18.3-2, 6.19.0-rc3-1
   - Distribution: Manjaro Linux
   - Architecture: x86_64
   - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)

[4.] Filesystem and storage:
   - Root filesystem: btrfs on LUKS encryption
   - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
   - VM storage: separate btrfs subvolume
   - btrfs device stats: all zeros (no errors)

[5.] Reproduction:
- Boot kernel 6.18.3-2 or 6.19.0-rc3
- Start VirtualBox 7.2.4 r170995
- Create new Windows 10 or Windows 11 VM
- Begin OS installation
- BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
- Issue is 100% reproducible on 6.18+, never occurs on 6.12

Additional context:
- Host system remains completely stable during VM crashes
- No btrfs errors in dmesg or device stats (all zero)
- Issue persists across multiple 6.18/6.19 releases over one month
- VirtualBox 7.2.4 modules load successfully on all kernel versions

Regards,
Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[Qu Wenruo]

在 2026/1/11 20:33, jollycar 写道:
> #regzbot introduced: v6.12..v6.18
> 
> [1.] One line summary of the problem:
> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> 
> [2.] Full description of the problem:
> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> 
> [3] Kernel & Hardware:
>     - Kernel versions tested:
>       * Working: 6.12.63-1
>       * Broken: 6.18.3-2, 6.19.0-rc3-1
>     - Distribution: Manjaro Linux
>     - Architecture: x86_64
>     - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> 
> [4.] Filesystem and storage:
>     - Root filesystem: btrfs on LUKS encryption
>     - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>     - VM storage: separate btrfs subvolume

What's the storage file configuration? Like what's the cache mode setting?
I don't know VBox at all, but there may be something similar to 
libvirt's cache mode (none/unsafe/writethrough etc).

More importantly, will tweaking the cache mode change fix the broken 
kernels?
If so it may point to direct IO related behavior changes.


And what's the storage file format? QCOW2? RAW? Or whatever format 
provided by Vbox?


And one final question, have you tried qemu (or libvirt + qemu) and can 
it still be reproduced with qemu?
As I'm wondering if the direct IO related change will even affects qemu

Thanks,
Qu

>     - btrfs device stats: all zeros (no errors)
> 
> [5.] Reproduction:
> - Boot kernel 6.18.3-2 or 6.19.0-rc3
> - Start VirtualBox 7.2.4 r170995
> - Create new Windows 10 or Windows 11 VM
> - Begin OS installation
> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> 
> Additional context:
> - Host system remains completely stable during VM crashes
> - No btrfs errors in dmesg or device stats (all zero)
> - Issue persists across multiple 6.18/6.19 releases over one month
> - VirtualBox 7.2.4 modules load successfully on all kernel versions
> 
> Regards,
> Jollycar
> 

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[jollycar]

Storage configuration details:

Storage format: VDI (VirtualBox Disk Image)
Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
Controller: IntelAhci (SATA)
Default configuration: hostiocache on, mtype normal

Cache and media type testing on kernel 6.18.3:
- Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
- mtype writethrough: Gets much further, BSOD occurs on first VM reboot
- hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot

None of the configurations provide a working solution - they only delay the crash.

On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.

I have not yet tested with qemu/libvirt. Should I proceed with that test?


On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo <wqu@suse.com> wrote:

> 
> 
> 
> 
> 在 2026/1/11 20:33, jollycar 写道:
> 
> > #regzbot introduced: v6.12..v6.18
> > 
> > [1.] One line summary of the problem:
> > VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> > 
> > [2.] Full description of the problem:
> > Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> > 
> > [3] Kernel & Hardware:
> > - Kernel versions tested:
> > * Working: 6.12.63-1
> > * Broken: 6.18.3-2, 6.19.0-rc3-1
> > - Distribution: Manjaro Linux
> > - Architecture: x86_64
> > - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> > 
> > [4.] Filesystem and storage:
> > - Root filesystem: btrfs on LUKS encryption
> > - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
> > - VM storage: separate btrfs subvolume
> 
> 
> What's the storage file configuration? Like what's the cache mode setting?
> I don't know VBox at all, but there may be something similar to
> libvirt's cache mode (none/unsafe/writethrough etc).
> 
> More importantly, will tweaking the cache mode change fix the broken
> kernels?
> If so it may point to direct IO related behavior changes.
> 
> 
> And what's the storage file format? QCOW2? RAW? Or whatever format
> provided by Vbox?
> 
> 
> And one final question, have you tried qemu (or libvirt + qemu) and can
> it still be reproduced with qemu?
> As I'm wondering if the direct IO related change will even affects qemu
> 
> Thanks,
> Qu
> 
> > - btrfs device stats: all zeros (no errors)
> > 
> > [5.] Reproduction:
> > - Boot kernel 6.18.3-2 or 6.19.0-rc3
> > - Start VirtualBox 7.2.4 r170995
> > - Create new Windows 10 or Windows 11 VM
> > - Begin OS installation
> > - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> > - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> > 
> > Additional context:
> > - Host system remains completely stable during VM crashes
> > - No btrfs errors in dmesg or device stats (all zero)
> > - Issue persists across multiple 6.18/6.19 releases over one month
> > - VirtualBox 7.2.4 modules load successfully on all kernel versions
> > 
> > Regards,
> > Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[Qu Wenruo]

在 2026/1/11 21:39, jollycar 写道:
> Storage configuration details:
> 
> Storage format: VDI (VirtualBox Disk Image)
> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)

OK, this means it's not related to the direct IO changes in newer kernels.

When COW is disabled, data checksum is also disables, thus direct IO is 
still doing the true zero-copy behavior.

This ruled out the btrfs direct io change, but this means I have no clue 
what is going wrong at all now.

> Controller: IntelAhci (SATA)
> Default configuration: hostiocache on, mtype normal
> 
> Cache and media type testing on kernel 6.18.3:
> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> 
> None of the configurations provide a working solution - they only delay the crash.
> 
> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> 
> I have not yet tested with qemu/libvirt. Should I proceed with that test?

Yes please. Libvirt/qemu is a more common solution among developers.
If you can reproduce it using libvirt/qemu, more btrfs developers can 
try to reproduce it and look into it.

And if not, the cause may shift towards vbox other than btrfs.

Thanks,
Qu

> 
> 
> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo <wqu@suse.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/11 20:33, jollycar 写道:
>>
>>> #regzbot introduced: v6.12..v6.18
>>>
>>> [1.] One line summary of the problem:
>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>
>>> [2.] Full description of the problem:
>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>
>>> [3] Kernel & Hardware:
>>> - Kernel versions tested:
>>> * Working: 6.12.63-1
>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>> - Distribution: Manjaro Linux
>>> - Architecture: x86_64
>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>
>>> [4.] Filesystem and storage:
>>> - Root filesystem: btrfs on LUKS encryption
>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>> - VM storage: separate btrfs subvolume
>>
>>
>> What's the storage file configuration? Like what's the cache mode setting?
>> I don't know VBox at all, but there may be something similar to
>> libvirt's cache mode (none/unsafe/writethrough etc).
>>
>> More importantly, will tweaking the cache mode change fix the broken
>> kernels?
>> If so it may point to direct IO related behavior changes.
>>
>>
>> And what's the storage file format? QCOW2? RAW? Or whatever format
>> provided by Vbox?
>>
>>
>> And one final question, have you tried qemu (or libvirt + qemu) and can
>> it still be reproduced with qemu?
>> As I'm wondering if the direct IO related change will even affects qemu
>>
>> Thanks,
>> Qu
>>
>>> - btrfs device stats: all zeros (no errors)
>>>
>>> [5.] Reproduction:
>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>> - Start VirtualBox 7.2.4 r170995
>>> - Create new Windows 10 or Windows 11 VM
>>> - Begin OS installation
>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>
>>> Additional context:
>>> - Host system remains completely stable during VM crashes
>>> - No btrfs errors in dmesg or device stats (all zero)
>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>
>>> Regards,
>>> Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[jollycar]

Qemu/libvirt test results on kernel 6.18.3:

Setup:
- Virtualization: qemu via libvirt (virt-manager)
- Disk format: qcow2
- Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
- COW disabled on disk image (chattr +C)
- ISO: Same Windows 10 ISO used in VirtualBox tests
- Guest: Windows 10

Result:
Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.

Summary of all tests on kernel 6.18.3:
- VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
- Qemu via libvirt: No crashes, installation completes successfully

Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.


On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo <wqu@suse.com> wrote:

> 
> 
> 
> 
> 在 2026/1/11 21:39, jollycar 写道:
> 
> > Storage configuration details:
> > 
> > Storage format: VDI (VirtualBox Disk Image)
> > Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
> 
> 
> OK, this means it's not related to the direct IO changes in newer kernels.
> 
> When COW is disabled, data checksum is also disables, thus direct IO is
> still doing the true zero-copy behavior.
> 
> This ruled out the btrfs direct io change, but this means I have no clue
> what is going wrong at all now.
> 
> > Controller: IntelAhci (SATA)
> > Default configuration: hostiocache on, mtype normal
> > 
> > Cache and media type testing on kernel 6.18.3:
> > - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> > - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> > - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> > 
> > None of the configurations provide a working solution - they only delay the crash.
> > 
> > On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> > 
> > I have not yet tested with qemu/libvirt. Should I proceed with that test?
> 
> 
> Yes please. Libvirt/qemu is a more common solution among developers.
> If you can reproduce it using libvirt/qemu, more btrfs developers can
> try to reproduce it and look into it.
> 
> And if not, the cause may shift towards vbox other than btrfs.
> 
> Thanks,
> Qu
> 
> > On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
> > 
> > > 在 2026/1/11 20:33, jollycar 写道:
> > > 
> > > > #regzbot introduced: v6.12..v6.18
> > > > 
> > > > [1.] One line summary of the problem:
> > > > VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> > > > 
> > > > [2.] Full description of the problem:
> > > > Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> > > > 
> > > > [3] Kernel & Hardware:
> > > > - Kernel versions tested:
> > > > * Working: 6.12.63-1
> > > > * Broken: 6.18.3-2, 6.19.0-rc3-1
> > > > - Distribution: Manjaro Linux
> > > > - Architecture: x86_64
> > > > - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> > > > 
> > > > [4.] Filesystem and storage:
> > > > - Root filesystem: btrfs on LUKS encryption
> > > > - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
> > > > - VM storage: separate btrfs subvolume
> > > 
> > > What's the storage file configuration? Like what's the cache mode setting?
> > > I don't know VBox at all, but there may be something similar to
> > > libvirt's cache mode (none/unsafe/writethrough etc).
> > > 
> > > More importantly, will tweaking the cache mode change fix the broken
> > > kernels?
> > > If so it may point to direct IO related behavior changes.
> > > 
> > > And what's the storage file format? QCOW2? RAW? Or whatever format
> > > provided by Vbox?
> > > 
> > > And one final question, have you tried qemu (or libvirt + qemu) and can
> > > it still be reproduced with qemu?
> > > As I'm wondering if the direct IO related change will even affects qemu
> > > 
> > > Thanks,
> > > Qu
> > > 
> > > > - btrfs device stats: all zeros (no errors)
> > > > 
> > > > [5.] Reproduction:
> > > > - Boot kernel 6.18.3-2 or 6.19.0-rc3
> > > > - Start VirtualBox 7.2.4 r170995
> > > > - Create new Windows 10 or Windows 11 VM
> > > > - Begin OS installation
> > > > - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> > > > - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> > > > 
> > > > Additional context:
> > > > - Host system remains completely stable during VM crashes
> > > > - No btrfs errors in dmesg or device stats (all zero)
> > > > - Issue persists across multiple 6.18/6.19 releases over one month
> > > > - VirtualBox 7.2.4 modules load successfully on all kernel versions
> > > > 
> > > > Regards,
> > > > Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[Qu Wenruo]

在 2026/1/13 02:03, jollycar 写道:
> Qemu/libvirt test results on kernel 6.18.3:
> 
> Setup:
> - Virtualization: qemu via libvirt (virt-manager)
> - Disk format: qcow2
> - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
> - COW disabled on disk image (chattr +C)
> - ISO: Same Windows 10 ISO used in VirtualBox tests
> - Guest: Windows 10
> 
> Result:
> Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
> 
> Summary of all tests on kernel 6.18.3:
> - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
> - Qemu via libvirt: No crashes, installation completes successfully
> 
> Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.

Thanks a lot, this looks like there is something wrong related to the 
VBox out-of-tree kernel module.
In that case, the btrfs community is not going to help much unfortunately.

Mind to share how is the out-of-tree kernel module installed?
The pre-compiled one from the distro? The DKMS one or something else?


And just some guesses, can VBox specify what type of CPU (and extensions 
like SSE/AVX) it uses?
If so (like qemu), mind to check if you can specify some CPU types 
without some newer extensions while still meets the minimal CPU 
requirement of Windows 10?

I'm wondering if it's some extension handling not done properly, which 
is commonly utilized by checksums.
Thus triggers the checksum mismatch errors inside Windows.

Thanks,
Qu



> 
> 
> On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo <wqu@suse.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/11 21:39, jollycar 写道:
>>
>>> Storage configuration details:
>>>
>>> Storage format: VDI (VirtualBox Disk Image)
>>> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
>>
>>
>> OK, this means it's not related to the direct IO changes in newer kernels.
>>
>> When COW is disabled, data checksum is also disables, thus direct IO is
>> still doing the true zero-copy behavior.
>>
>> This ruled out the btrfs direct io change, but this means I have no clue
>> what is going wrong at all now.
>>
>>> Controller: IntelAhci (SATA)
>>> Default configuration: hostiocache on, mtype normal
>>>
>>> Cache and media type testing on kernel 6.18.3:
>>> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
>>> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
>>> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
>>>
>>> None of the configurations provide a working solution - they only delay the crash.
>>>
>>> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
>>>
>>> I have not yet tested with qemu/libvirt. Should I proceed with that test?
>>
>>
>> Yes please. Libvirt/qemu is a more common solution among developers.
>> If you can reproduce it using libvirt/qemu, more btrfs developers can
>> try to reproduce it and look into it.
>>
>> And if not, the cause may shift towards vbox other than btrfs.
>>
>> Thanks,
>> Qu
>>
>>> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
>>>
>>>> 在 2026/1/11 20:33, jollycar 写道:
>>>>
>>>>> #regzbot introduced: v6.12..v6.18
>>>>>
>>>>> [1.] One line summary of the problem:
>>>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>>>
>>>>> [2.] Full description of the problem:
>>>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>>>
>>>>> [3] Kernel & Hardware:
>>>>> - Kernel versions tested:
>>>>> * Working: 6.12.63-1
>>>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>>>> - Distribution: Manjaro Linux
>>>>> - Architecture: x86_64
>>>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>>>
>>>>> [4.] Filesystem and storage:
>>>>> - Root filesystem: btrfs on LUKS encryption
>>>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>>>> - VM storage: separate btrfs subvolume
>>>>
>>>> What's the storage file configuration? Like what's the cache mode setting?
>>>> I don't know VBox at all, but there may be something similar to
>>>> libvirt's cache mode (none/unsafe/writethrough etc).
>>>>
>>>> More importantly, will tweaking the cache mode change fix the broken
>>>> kernels?
>>>> If so it may point to direct IO related behavior changes.
>>>>
>>>> And what's the storage file format? QCOW2? RAW? Or whatever format
>>>> provided by Vbox?
>>>>
>>>> And one final question, have you tried qemu (or libvirt + qemu) and can
>>>> it still be reproduced with qemu?
>>>> As I'm wondering if the direct IO related change will even affects qemu
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>> - btrfs device stats: all zeros (no errors)
>>>>>
>>>>> [5.] Reproduction:
>>>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>>>> - Start VirtualBox 7.2.4 r170995
>>>>> - Create new Windows 10 or Windows 11 VM
>>>>> - Begin OS installation
>>>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>>>
>>>>> Additional context:
>>>>> - Host system remains completely stable during VM crashes
>>>>> - No btrfs errors in dmesg or device stats (all zero)
>>>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>>>
>>>>> Regards,
>>>>> Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[jollycar]

Thanks for the response.

Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).

Regarding CPU type specification:

VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.

Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).

Regards,
Jollycar

On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo <wqu@suse.com> wrote:

> 
> 
> 
> 
> 在 2026/1/13 02:03, jollycar 写道:
> 
> > Qemu/libvirt test results on kernel 6.18.3:
> > 
> > Setup:
> > - Virtualization: qemu via libvirt (virt-manager)
> > - Disk format: qcow2
> > - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
> > - COW disabled on disk image (chattr +C)
> > - ISO: Same Windows 10 ISO used in VirtualBox tests
> > - Guest: Windows 10
> > 
> > Result:
> > Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
> > 
> > Summary of all tests on kernel 6.18.3:
> > - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
> > - Qemu via libvirt: No crashes, installation completes successfully
> > 
> > Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
> 
> 
> Thanks a lot, this looks like there is something wrong related to the
> VBox out-of-tree kernel module.
> In that case, the btrfs community is not going to help much unfortunately.
> 
> Mind to share how is the out-of-tree kernel module installed?
> The pre-compiled one from the distro? The DKMS one or something else?
> 
> 
> And just some guesses, can VBox specify what type of CPU (and extensions
> like SSE/AVX) it uses?
> If so (like qemu), mind to check if you can specify some CPU types
> without some newer extensions while still meets the minimal CPU
> requirement of Windows 10?
> 
> I'm wondering if it's some extension handling not done properly, which
> is commonly utilized by checksums.
> Thus triggers the checksum mismatch errors inside Windows.
> 
> Thanks,
> Qu
> 
> 
> > On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@suse.com wrote:
> > 
> > > 在 2026/1/11 21:39, jollycar 写道:
> > > 
> > > > Storage configuration details:
> > > > 
> > > > Storage format: VDI (VirtualBox Disk Image)
> > > > Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
> > > 
> > > OK, this means it's not related to the direct IO changes in newer kernels.
> > > 
> > > When COW is disabled, data checksum is also disables, thus direct IO is
> > > still doing the true zero-copy behavior.
> > > 
> > > This ruled out the btrfs direct io change, but this means I have no clue
> > > what is going wrong at all now.
> > > 
> > > > Controller: IntelAhci (SATA)
> > > > Default configuration: hostiocache on, mtype normal
> > > > 
> > > > Cache and media type testing on kernel 6.18.3:
> > > > - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> > > > - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> > > > - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> > > > 
> > > > None of the configurations provide a working solution - they only delay the crash.
> > > > 
> > > > On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> > > > 
> > > > I have not yet tested with qemu/libvirt. Should I proceed with that test?
> > > 
> > > Yes please. Libvirt/qemu is a more common solution among developers.
> > > If you can reproduce it using libvirt/qemu, more btrfs developers can
> > > try to reproduce it and look into it.
> > > 
> > > And if not, the cause may shift towards vbox other than btrfs.
> > > 
> > > Thanks,
> > > Qu
> > > 
> > > > On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
> > > > 
> > > > > 在 2026/1/11 20:33, jollycar 写道:
> > > > > 
> > > > > > #regzbot introduced: v6.12..v6.18
> > > > > > 
> > > > > > [1.] One line summary of the problem:
> > > > > > VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> > > > > > 
> > > > > > [2.] Full description of the problem:
> > > > > > Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> > > > > > 
> > > > > > [3] Kernel & Hardware:
> > > > > > - Kernel versions tested:
> > > > > > * Working: 6.12.63-1
> > > > > > * Broken: 6.18.3-2, 6.19.0-rc3-1
> > > > > > - Distribution: Manjaro Linux
> > > > > > - Architecture: x86_64
> > > > > > - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> > > > > > 
> > > > > > [4.] Filesystem and storage:
> > > > > > - Root filesystem: btrfs on LUKS encryption
> > > > > > - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
> > > > > > - VM storage: separate btrfs subvolume
> > > > > 
> > > > > What's the storage file configuration? Like what's the cache mode setting?
> > > > > I don't know VBox at all, but there may be something similar to
> > > > > libvirt's cache mode (none/unsafe/writethrough etc).
> > > > > 
> > > > > More importantly, will tweaking the cache mode change fix the broken
> > > > > kernels?
> > > > > If so it may point to direct IO related behavior changes.
> > > > > 
> > > > > And what's the storage file format? QCOW2? RAW? Or whatever format
> > > > > provided by Vbox?
> > > > > 
> > > > > And one final question, have you tried qemu (or libvirt + qemu) and can
> > > > > it still be reproduced with qemu?
> > > > > As I'm wondering if the direct IO related change will even affects qemu
> > > > > 
> > > > > Thanks,
> > > > > Qu
> > > > > 
> > > > > > - btrfs device stats: all zeros (no errors)
> > > > > > 
> > > > > > [5.] Reproduction:
> > > > > > - Boot kernel 6.18.3-2 or 6.19.0-rc3
> > > > > > - Start VirtualBox 7.2.4 r170995
> > > > > > - Create new Windows 10 or Windows 11 VM
> > > > > > - Begin OS installation
> > > > > > - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> > > > > > - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> > > > > > 
> > > > > > Additional context:
> > > > > > - Host system remains completely stable during VM crashes
> > > > > > - No btrfs errors in dmesg or device stats (all zero)
> > > > > > - Issue persists across multiple 6.18/6.19 releases over one month
> > > > > > - VirtualBox 7.2.4 modules load successfully on all kernel versions
> > > > > > 
> > > > > > Regards,
> > > > > > Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[Qu Wenruo]

在 2026/1/14 05:38, jollycar 写道:
> Thanks for the response.
> 
> Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).
> 
> Regarding CPU type specification:
> 
> VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.
> 
> Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).

Thanks for the extra info, I guess the last thing we can verify is, try 
to run the same VBox setup, using disk images from an EXT4/XFS.

And if that still failed, we're sure it's fs independent but more likely 
VBox dependent.

Thanks,
Qu

> 
> Regards,
> Jollycar
> 
> On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo <wqu@suse.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/13 02:03, jollycar 写道:
>>
>>> Qemu/libvirt test results on kernel 6.18.3:
>>>
>>> Setup:
>>> - Virtualization: qemu via libvirt (virt-manager)
>>> - Disk format: qcow2
>>> - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
>>> - COW disabled on disk image (chattr +C)
>>> - ISO: Same Windows 10 ISO used in VirtualBox tests
>>> - Guest: Windows 10
>>>
>>> Result:
>>> Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
>>>
>>> Summary of all tests on kernel 6.18.3:
>>> - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
>>> - Qemu via libvirt: No crashes, installation completes successfully
>>>
>>> Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
>>
>>
>> Thanks a lot, this looks like there is something wrong related to the
>> VBox out-of-tree kernel module.
>> In that case, the btrfs community is not going to help much unfortunately.
>>
>> Mind to share how is the out-of-tree kernel module installed?
>> The pre-compiled one from the distro? The DKMS one or something else?
>>
>>
>> And just some guesses, can VBox specify what type of CPU (and extensions
>> like SSE/AVX) it uses?
>> If so (like qemu), mind to check if you can specify some CPU types
>> without some newer extensions while still meets the minimal CPU
>> requirement of Windows 10?
>>
>> I'm wondering if it's some extension handling not done properly, which
>> is commonly utilized by checksums.
>> Thus triggers the checksum mismatch errors inside Windows.
>>
>> Thanks,
>> Qu
>>
>>
>>> On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@suse.com wrote:
>>>
>>>> 在 2026/1/11 21:39, jollycar 写道:
>>>>
>>>>> Storage configuration details:
>>>>>
>>>>> Storage format: VDI (VirtualBox Disk Image)
>>>>> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
>>>>
>>>> OK, this means it's not related to the direct IO changes in newer kernels.
>>>>
>>>> When COW is disabled, data checksum is also disables, thus direct IO is
>>>> still doing the true zero-copy behavior.
>>>>
>>>> This ruled out the btrfs direct io change, but this means I have no clue
>>>> what is going wrong at all now.
>>>>
>>>>> Controller: IntelAhci (SATA)
>>>>> Default configuration: hostiocache on, mtype normal
>>>>>
>>>>> Cache and media type testing on kernel 6.18.3:
>>>>> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
>>>>> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
>>>>> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
>>>>>
>>>>> None of the configurations provide a working solution - they only delay the crash.
>>>>>
>>>>> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
>>>>>
>>>>> I have not yet tested with qemu/libvirt. Should I proceed with that test?
>>>>
>>>> Yes please. Libvirt/qemu is a more common solution among developers.
>>>> If you can reproduce it using libvirt/qemu, more btrfs developers can
>>>> try to reproduce it and look into it.
>>>>
>>>> And if not, the cause may shift towards vbox other than btrfs.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
>>>>>
>>>>>> 在 2026/1/11 20:33, jollycar 写道:
>>>>>>
>>>>>>> #regzbot introduced: v6.12..v6.18
>>>>>>>
>>>>>>> [1.] One line summary of the problem:
>>>>>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>>>>>
>>>>>>> [2.] Full description of the problem:
>>>>>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>>>>>
>>>>>>> [3] Kernel & Hardware:
>>>>>>> - Kernel versions tested:
>>>>>>> * Working: 6.12.63-1
>>>>>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>>>>>> - Distribution: Manjaro Linux
>>>>>>> - Architecture: x86_64
>>>>>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>>>>>
>>>>>>> [4.] Filesystem and storage:
>>>>>>> - Root filesystem: btrfs on LUKS encryption
>>>>>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>>>>>> - VM storage: separate btrfs subvolume
>>>>>>
>>>>>> What's the storage file configuration? Like what's the cache mode setting?
>>>>>> I don't know VBox at all, but there may be something similar to
>>>>>> libvirt's cache mode (none/unsafe/writethrough etc).
>>>>>>
>>>>>> More importantly, will tweaking the cache mode change fix the broken
>>>>>> kernels?
>>>>>> If so it may point to direct IO related behavior changes.
>>>>>>
>>>>>> And what's the storage file format? QCOW2? RAW? Or whatever format
>>>>>> provided by Vbox?
>>>>>>
>>>>>> And one final question, have you tried qemu (or libvirt + qemu) and can
>>>>>> it still be reproduced with qemu?
>>>>>> As I'm wondering if the direct IO related change will even affects qemu
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>> - btrfs device stats: all zeros (no errors)
>>>>>>>
>>>>>>> [5.] Reproduction:
>>>>>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>>>>>> - Start VirtualBox 7.2.4 r170995
>>>>>>> - Create new Windows 10 or Windows 11 VM
>>>>>>> - Begin OS installation
>>>>>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>>>>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>>>>>
>>>>>>> Additional context:
>>>>>>> - Host system remains completely stable during VM crashes
>>>>>>> - No btrfs errors in dmesg or device stats (all zero)
>>>>>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>>>>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jollycar
> 

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[jollycar]

Tested VirtualBox setup on ext4:

- Created new ext4 partition on different physical disk
- Cloned VM instance to ext4 location
- Copied Windows 10 ISO to ext4 partition
- Started fresh Windows 10 installation

Result: BSOD still occurs during installation on kernel 6.18.5.

Regards,
Jollycar



On Tuesday, January 13th, 2026 at 11:03 PM, Qu Wenruo <wqu@suse.com> wrote:

> 
> 
> 
> 
> 在 2026/1/14 05:38, jollycar 写道:
> 
> > Thanks for the response.
> > 
> > Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).
> > 
> > Regarding CPU type specification:
> > 
> > VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.
> > 
> > Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).
> 
> 
> Thanks for the extra info, I guess the last thing we can verify is, try
> to run the same VBox setup, using disk images from an EXT4/XFS.
> 
> And if that still failed, we're sure it's fs independent but more likely
> VBox dependent.
> 
> Thanks,
> Qu
> 
> > Regards,
> > Jollycar
> > 
> > On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo wqu@suse.com wrote:
> > 
> > > 在 2026/1/13 02:03, jollycar 写道:
> > > 
> > > > Qemu/libvirt test results on kernel 6.18.3:
> > > > 
> > > > Setup:
> > > > - Virtualization: qemu via libvirt (virt-manager)
> > > > - Disk format: qcow2
> > > > - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
> > > > - COW disabled on disk image (chattr +C)
> > > > - ISO: Same Windows 10 ISO used in VirtualBox tests
> > > > - Guest: Windows 10
> > > > 
> > > > Result:
> > > > Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
> > > > 
> > > > Summary of all tests on kernel 6.18.3:
> > > > - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
> > > > - Qemu via libvirt: No crashes, installation completes successfully
> > > > 
> > > > Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
> > > 
> > > Thanks a lot, this looks like there is something wrong related to the
> > > VBox out-of-tree kernel module.
> > > In that case, the btrfs community is not going to help much unfortunately.
> > > 
> > > Mind to share how is the out-of-tree kernel module installed?
> > > The pre-compiled one from the distro? The DKMS one or something else?
> > > 
> > > And just some guesses, can VBox specify what type of CPU (and extensions
> > > like SSE/AVX) it uses?
> > > If so (like qemu), mind to check if you can specify some CPU types
> > > without some newer extensions while still meets the minimal CPU
> > > requirement of Windows 10?
> > > 
> > > I'm wondering if it's some extension handling not done properly, which
> > > is commonly utilized by checksums.
> > > Thus triggers the checksum mismatch errors inside Windows.
> > > 
> > > Thanks,
> > > Qu
> > > 
> > > > On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@suse.com wrote:
> > > > 
> > > > > 在 2026/1/11 21:39, jollycar 写道:
> > > > > 
> > > > > > Storage configuration details:
> > > > > > 
> > > > > > Storage format: VDI (VirtualBox Disk Image)
> > > > > > Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
> > > > > 
> > > > > OK, this means it's not related to the direct IO changes in newer kernels.
> > > > > 
> > > > > When COW is disabled, data checksum is also disables, thus direct IO is
> > > > > still doing the true zero-copy behavior.
> > > > > 
> > > > > This ruled out the btrfs direct io change, but this means I have no clue
> > > > > what is going wrong at all now.
> > > > > 
> > > > > > Controller: IntelAhci (SATA)
> > > > > > Default configuration: hostiocache on, mtype normal
> > > > > > 
> > > > > > Cache and media type testing on kernel 6.18.3:
> > > > > > - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> > > > > > - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> > > > > > - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> > > > > > 
> > > > > > None of the configurations provide a working solution - they only delay the crash.
> > > > > > 
> > > > > > On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> > > > > > 
> > > > > > I have not yet tested with qemu/libvirt. Should I proceed with that test?
> > > > > 
> > > > > Yes please. Libvirt/qemu is a more common solution among developers.
> > > > > If you can reproduce it using libvirt/qemu, more btrfs developers can
> > > > > try to reproduce it and look into it.
> > > > > 
> > > > > And if not, the cause may shift towards vbox other than btrfs.
> > > > > 
> > > > > Thanks,
> > > > > Qu
> > > > > 
> > > > > > On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
> > > > > > 
> > > > > > > 在 2026/1/11 20:33, jollycar 写道:
> > > > > > > 
> > > > > > > > #regzbot introduced: v6.12..v6.18
> > > > > > > > 
> > > > > > > > [1.] One line summary of the problem:
> > > > > > > > VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> > > > > > > > 
> > > > > > > > [2.] Full description of the problem:
> > > > > > > > Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> > > > > > > > 
> > > > > > > > [3] Kernel & Hardware:
> > > > > > > > - Kernel versions tested:
> > > > > > > > * Working: 6.12.63-1
> > > > > > > > * Broken: 6.18.3-2, 6.19.0-rc3-1
> > > > > > > > - Distribution: Manjaro Linux
> > > > > > > > - Architecture: x86_64
> > > > > > > > - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> > > > > > > > 
> > > > > > > > [4.] Filesystem and storage:
> > > > > > > > - Root filesystem: btrfs on LUKS encryption
> > > > > > > > - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
> > > > > > > > - VM storage: separate btrfs subvolume
> > > > > > > 
> > > > > > > What's the storage file configuration? Like what's the cache mode setting?
> > > > > > > I don't know VBox at all, but there may be something similar to
> > > > > > > libvirt's cache mode (none/unsafe/writethrough etc).
> > > > > > > 
> > > > > > > More importantly, will tweaking the cache mode change fix the broken
> > > > > > > kernels?
> > > > > > > If so it may point to direct IO related behavior changes.
> > > > > > > 
> > > > > > > And what's the storage file format? QCOW2? RAW? Or whatever format
> > > > > > > provided by Vbox?
> > > > > > > 
> > > > > > > And one final question, have you tried qemu (or libvirt + qemu) and can
> > > > > > > it still be reproduced with qemu?
> > > > > > > As I'm wondering if the direct IO related change will even affects qemu
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Qu
> > > > > > > 
> > > > > > > > - btrfs device stats: all zeros (no errors)
> > > > > > > > 
> > > > > > > > [5.] Reproduction:
> > > > > > > > - Boot kernel 6.18.3-2 or 6.19.0-rc3
> > > > > > > > - Start VirtualBox 7.2.4 r170995
> > > > > > > > - Create new Windows 10 or Windows 11 VM
> > > > > > > > - Begin OS installation
> > > > > > > > - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> > > > > > > > - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> > > > > > > > 
> > > > > > > > Additional context:
> > > > > > > > - Host system remains completely stable during VM crashes
> > > > > > > > - No btrfs errors in dmesg or device stats (all zero)
> > > > > > > > - Issue persists across multiple 6.18/6.19 releases over one month
> > > > > > > > - VirtualBox 7.2.4 modules load successfully on all kernel versions
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Jollycar

Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

[Qu Wenruo]

在 2026/1/16 07:42, jollycar 写道:
> Tested VirtualBox setup on ext4:
> 
> - Created new ext4 partition on different physical disk
> - Cloned VM instance to ext4 location
> - Copied Windows 10 ISO to ext4 partition
> - Started fresh Windows 10 installation
> 
> Result: BSOD still occurs during installation on kernel 6.18.5.

So it's definitely something wrong with the VBox module now.

It's out of our understanding, so not much help can be provided.
You may want to report the error to upstream vbox:
https://github.com/VirtualBox/virtualbox/issues

(And that's why most developers are using libvirt/qemu, where KVM has 
upstream support)

Thanks,
Qu

> 
> Regards,
> Jollycar
> 
> 
> 
> On Tuesday, January 13th, 2026 at 11:03 PM, Qu Wenruo <wqu@suse.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/14 05:38, jollycar 写道:
>>
>>> Thanks for the response.
>>>
>>> Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).
>>>
>>> Regarding CPU type specification:
>>>
>>> VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.
>>>
>>> Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).
>>
>>
>> Thanks for the extra info, I guess the last thing we can verify is, try
>> to run the same VBox setup, using disk images from an EXT4/XFS.
>>
>> And if that still failed, we're sure it's fs independent but more likely
>> VBox dependent.
>>
>> Thanks,
>> Qu
>>
>>> Regards,
>>> Jollycar
>>>
>>> On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo wqu@suse.com wrote:
>>>
>>>> 在 2026/1/13 02:03, jollycar 写道:
>>>>
>>>>> Qemu/libvirt test results on kernel 6.18.3:
>>>>>
>>>>> Setup:
>>>>> - Virtualization: qemu via libvirt (virt-manager)
>>>>> - Disk format: qcow2
>>>>> - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
>>>>> - COW disabled on disk image (chattr +C)
>>>>> - ISO: Same Windows 10 ISO used in VirtualBox tests
>>>>> - Guest: Windows 10
>>>>>
>>>>> Result:
>>>>> Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
>>>>>
>>>>> Summary of all tests on kernel 6.18.3:
>>>>> - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
>>>>> - Qemu via libvirt: No crashes, installation completes successfully
>>>>>
>>>>> Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
>>>>
>>>> Thanks a lot, this looks like there is something wrong related to the
>>>> VBox out-of-tree kernel module.
>>>> In that case, the btrfs community is not going to help much unfortunately.
>>>>
>>>> Mind to share how is the out-of-tree kernel module installed?
>>>> The pre-compiled one from the distro? The DKMS one or something else?
>>>>
>>>> And just some guesses, can VBox specify what type of CPU (and extensions
>>>> like SSE/AVX) it uses?
>>>> If so (like qemu), mind to check if you can specify some CPU types
>>>> without some newer extensions while still meets the minimal CPU
>>>> requirement of Windows 10?
>>>>
>>>> I'm wondering if it's some extension handling not done properly, which
>>>> is commonly utilized by checksums.
>>>> Thus triggers the checksum mismatch errors inside Windows.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>> On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@suse.com wrote:
>>>>>
>>>>>> 在 2026/1/11 21:39, jollycar 写道:
>>>>>>
>>>>>>> Storage configuration details:
>>>>>>>
>>>>>>> Storage format: VDI (VirtualBox Disk Image)
>>>>>>> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
>>>>>>
>>>>>> OK, this means it's not related to the direct IO changes in newer kernels.
>>>>>>
>>>>>> When COW is disabled, data checksum is also disables, thus direct IO is
>>>>>> still doing the true zero-copy behavior.
>>>>>>
>>>>>> This ruled out the btrfs direct io change, but this means I have no clue
>>>>>> what is going wrong at all now.
>>>>>>
>>>>>>> Controller: IntelAhci (SATA)
>>>>>>> Default configuration: hostiocache on, mtype normal
>>>>>>>
>>>>>>> Cache and media type testing on kernel 6.18.3:
>>>>>>> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
>>>>>>> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
>>>>>>> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
>>>>>>>
>>>>>>> None of the configurations provide a working solution - they only delay the crash.
>>>>>>>
>>>>>>> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
>>>>>>>
>>>>>>> I have not yet tested with qemu/libvirt. Should I proceed with that test?
>>>>>>
>>>>>> Yes please. Libvirt/qemu is a more common solution among developers.
>>>>>> If you can reproduce it using libvirt/qemu, more btrfs developers can
>>>>>> try to reproduce it and look into it.
>>>>>>
>>>>>> And if not, the cause may shift towards vbox other than btrfs.
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@suse.com wrote:
>>>>>>>
>>>>>>>> 在 2026/1/11 20:33, jollycar 写道:
>>>>>>>>
>>>>>>>>> #regzbot introduced: v6.12..v6.18
>>>>>>>>>
>>>>>>>>> [1.] One line summary of the problem:
>>>>>>>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>>>>>>>
>>>>>>>>> [2.] Full description of the problem:
>>>>>>>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>>>>>>>
>>>>>>>>> [3] Kernel & Hardware:
>>>>>>>>> - Kernel versions tested:
>>>>>>>>> * Working: 6.12.63-1
>>>>>>>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>>>>>>>> - Distribution: Manjaro Linux
>>>>>>>>> - Architecture: x86_64
>>>>>>>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>>>>>>>
>>>>>>>>> [4.] Filesystem and storage:
>>>>>>>>> - Root filesystem: btrfs on LUKS encryption
>>>>>>>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>>>>>>>> - VM storage: separate btrfs subvolume
>>>>>>>>
>>>>>>>> What's the storage file configuration? Like what's the cache mode setting?
>>>>>>>> I don't know VBox at all, but there may be something similar to
>>>>>>>> libvirt's cache mode (none/unsafe/writethrough etc).
>>>>>>>>
>>>>>>>> More importantly, will tweaking the cache mode change fix the broken
>>>>>>>> kernels?
>>>>>>>> If so it may point to direct IO related behavior changes.
>>>>>>>>
>>>>>>>> And what's the storage file format? QCOW2? RAW? Or whatever format
>>>>>>>> provided by Vbox?
>>>>>>>>
>>>>>>>> And one final question, have you tried qemu (or libvirt + qemu) and can
>>>>>>>> it still be reproduced with qemu?
>>>>>>>> As I'm wondering if the direct IO related change will even affects qemu
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Qu
>>>>>>>>
>>>>>>>>> - btrfs device stats: all zeros (no errors)
>>>>>>>>>
>>>>>>>>> [5.] Reproduction:
>>>>>>>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>>>>>>>> - Start VirtualBox 7.2.4 r170995
>>>>>>>>> - Create new Windows 10 or Windows 11 VM
>>>>>>>>> - Begin OS installation
>>>>>>>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>>>>>>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>>>>>>>
>>>>>>>>> Additional context:
>>>>>>>>> - Host system remains completely stable during VM crashes
>>>>>>>>> - No btrfs errors in dmesg or device stats (all zero)
>>>>>>>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>>>>>>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jollycar