WSL fails to start with 0x80370114, and VirtualBox says it cannot operate in VMX mode — are these the same problem? Won't start

Yes, same problem, seen from two sides. The hardware virtualisation extensions can be claimed by exactly one hypervisor at a time, and something already has them.

That something is almost certainly Hyper-V, which WSL requires. Once the Hyper-V hypervisor is running, it owns the extensions and everything else has to go through it rather than touching the hardware directly. VirtualBox's classic engine wants the hardware itself, cannot have it, and reports that it cannot enter VMX root mode.

Your Task Manager check is consistent with this rather than contradicting it: it says the firmware setting is on, not that it is available to the caller.

So the two errors are one condition. What is confusing is that yours is failing in both directions, which suggests the hypervisor is in a half-configured state — enabled enough to take the extensions, not enough to actually create a VM.

For question 3 — you can have both, and it is better than it used to be.

Modern VirtualBox can run on top of the Hyper-V hypervisor rather than fighting it. It is slower than native, sometimes noticeably, but it works and it means you stop toggling settings and rebooting between tasks. Make sure you are on a current version; the versions where this was broken are exactly the ones people had installed when they wrote the advice to disable Hyper-V.

The other option, if you need VirtualBox at full speed, is to accept the trade and turn the hypervisor off when you need it:

bcdedit /set hypervisorlaunchtype off

WSL then stops working until you set it back to auto. Each change needs a restart, which is the real cost.

Most people are better served by keeping the hypervisor on and using WSL for the Linux workload it is good at, keeping VirtualBox for the cases that genuinely need a full VM.

The thing to check for question 2, because it catches almost everybody: the hypervisor launch setting can be off even when every feature box is ticked.

From an administrator prompt:

bcdedit /enum {current}

Look for hypervisorlaunchtype. If it says Off, Windows is not starting the hypervisor at boot, and WSL cannot create its VM no matter what else is enabled. Something set it — a game anti-cheat installer, a performance tweak guide, or a previous attempt to make VirtualBox work.

bcdedit /set hypervisorlaunchtype auto

Then a full restart, not a fast-startup shutdown. This single setting is behind a large share of 0x80370114 reports where everything else looks correct.

Also worth checking in Windows Features that Virtual Machine Platform is ticked. It is a separate item from Hyper-V and WSL needs it specifically.

One more candidate for "something else has the extensions", since it is invisible and increasingly common: Memory Integrity, under Core Isolation in Windows Security.

It uses virtualisation-based security, which means the hypervisor is running whether you asked for it or not. On a machine where somebody disabled Hyper-V to make VirtualBox work and it still failed, this is usually why.

Worth knowing before disabling it: it is a genuine security feature and turning it off to speed up a VM is a real trade, not a free win. Check whether VirtualBox on top of the hypervisor is fast enough first.