If your Windows 11 PC has been freezing randomly and requiring a hard restart, you’re not dealing with bad RAM or a failing hard drive. You might be dealing with one of the most frustrating conflicts in Windows — Oracle VirtualBox and WSL2 running at the same time.
This is exactly what happened here. Ten unexpected shutdowns over one month, two BSODs, and a DISM run that triggered another crash mid-repair. Here’s what caused it, how we diagnosed it, and the exact commands that fixed it.
The error messages that give it away:
If you open Event Viewer after a crash and see this on every single boot:
The driver detected an internal driver error on \Device\VBoxNetLwf.
That’s Event ID 12, and it’s the smoking gun. VirtualBox’s network driver is conflicting with Windows Hyper-V — the same virtualization layer that WSL2 depends on.
You’ll also likely see:
The system has rebooted without cleanly shutting down first.
That’s Event ID 41 — Kernel Power Failure — which appears after every unexpected shutdown or freeze.
Why VirtualBox and WSL2 conflict
WSL2 (Windows Subsystem for Linux 2) requires Hyper-V — Microsoft’s built-in hypervisor. VirtualBox also needs hardware virtualization to run virtual machines. When both are installed, they fight over the same low-level kernel resources, particularly in network driver and CPU power management handling.
The result: kernel instability, random freezes, and BSODs. The two specific crash codes found in this case were:
- 0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA) — a driver accessing invalid memory, consistent with a conflicting virtualization driver
- 0x0000001E (KMODE_EXCEPTION_NOT_HANDLED) — Windows Power Management failing during a CPU idle transition, triggered by residual VirtualBox/Hyper-V conflict
The VBoxNetLwf driver (VirtualBox’s NDIS Lightweight Filter network driver) was generating internal errors on every boot, slowly destabilizing the kernel until it crashed.
Step 1: Check Event Viewer to confirm the cause
Before touching anything, confirm this is the same problem. Open PowerShell as Administrator and export your crash events:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,6008,1001} | Export-Csv "$env:USERPROFILE\Desktop\shutdown_errors.csv" -NoTypeInformation
Open the CSV and look for Event ID 12 with \Device\VBoxNetLwf in the message. If it appears on every crash entry — this guide is your fix.
Also check for orphaned VirtualBox registry entries:
reg query HKLM\SYSTEM\CurrentControlSet\Services | findstr -i "vbox"
If you see VBoxNetAdp or similar entries even though VirtualBox is already uninstalled, those orphaned drivers are still loading on every boot and causing instability.
Step 2: Uninstall VirtualBox completely
Go to Settings → Apps → Installed Apps, search for VirtualBox, click Uninstall.
After uninstalling, verify no VirtualBox drivers remain:
Get-WindowsDriver -Online | Where-Object {$_.ProviderName -like "*Oracle*" -or $_.OriginalFileName -like "*vbox*"} | Select-Object ProviderName, OriginalFileName, Version
If this returns empty — the drivers are gone. If it still shows VirtualBox entries, you may need to manually remove them via Device Manager → View → Show Hidden Devices.
Step 3: Delete the orphaned registry key
Even after uninstalling VirtualBox, the registry key often remains. This is enough to keep loading the broken driver reference on every boot.
Delete it:
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\VBoxNetAdp" /f
Verify it’s gone:
reg query HKLM\SYSTEM\CurrentControlSet\Services | findstr -i "vbox"
This should return nothing. If it still shows entries, repeat the reg delete command for each one.
Step 4: Run SFC to repair corrupted system files
Ten hard resets over one month is enough to corrupt Windows system files. Run System File Checker:
sfc /scannow
This takes 5–15 minutes. If it finds corrupt files it repairs them automatically. You’ll see:
Windows Resource Protection found corrupt files and successfully repaired them.
That’s expected after multiple hard crashes — not a sign of a deeper problem. SFC handles it.
Step 5: Run DISM to restore Windows image health — after a full reboot
This is the step where things can go wrong. Do a full reboot first before running DISM. The previous session’s VirtualBox memory residue needs to be fully cleared or DISM can trigger another BSOD.
After rebooting, run:
DISM /Online /Cleanup-Image /RestoreHealth
This takes 15–30 minutes depending on your connection speed — it downloads replacement files from Windows Update. Let it run to 100% without interrupting it. You should see:
The restore operation completed successfully.
The operation completed successfully.
After this completes, do one final reboot. Monitor Event Viewer over the next few days — the Event ID 12 VBoxNetLwf errors should be completely gone.
FAQ
Can I use VirtualBox and WSL2 together without crashes? Yes, but not with the default VirtualBox setup. VirtualBox offers a Hyper-V backend specifically designed to coexist with WSL2 and Hyper-V. Download the latest VirtualBox from virtualbox.org and enable the Hyper-V backend in VirtualBox settings. This runs VirtualBox on top of Hyper-V instead of fighting it.
Will disabling Hyper-V fix the freezing without uninstalling VirtualBox? No — and don’t do this if you use WSL2. WSL2 requires Hyper-V. Disabling it will break your Linux environment. The correct fix is removing VirtualBox (or switching it to Hyper-V backend mode), not disabling Hyper-V.
My DISM crashed mid-run and now the system is worse — what do I do? Don’t panic. Reboot fully, then run sfc /scannow first to repair what it can. Then try DISM again after the reboot. If DISM keeps crashing, boot into Windows Recovery Environment (hold Shift while clicking Restart) and run DISM from there — it’s more stable than running it inside a potentially corrupted live Windows session.
Errors you can safely ignore
Two error types appeared in the logs during this investigation that look alarming but are unrelated to the freezing:
Event ID 1796 (Secure Boot errors) — caused by Secure Boot being disabled in BIOS. Cosmetic only, does not cause crashes.
Event ID 10016 (DCOM warnings) — normal Windows background noise. Appears on almost every Windows 11 installation. Not a crash cause.
Tested on: Windows 11 Home, Build 10.0.26200.8246, WSL2 with Ubuntu, VirtualBox (uninstalled). Active troubleshooting time: approximately 2–3 hours. Tools used: PowerShell, Windows Memory Diagnostic, WinDbg, SFC, DISM.