Installing a Linux distribution fails with error 0x80370114 and no other explanation

Two further causes that produce the same code once the obvious ones are ruled out.

Exploit protection settings. Some security configurations disable a control flow protection for the virtual machine compute service, and that stops the machine starting. It is a per-program setting and it is easy to check and re-enable in the exploit protection panel under program settings.

Another hypervisor holding the hardware. Some third-party virtualisation software takes exclusive control of the virtualisation extensions, which prevents the platform from starting its own machine. Older versions of the popular desktop virtualisation products did this; recent ones generally coexist. If you have one installed, updating it or shutting it down is worth testing.

Corporate machines add a third possibility: security policy that disables the features entirely, in which case no local change will help and it needs to go through whoever manages the device.

That code means the virtual machine could not be started, and in practice it almost always means a required Windows feature or a hardware virtualisation setting is off.

The subsystem in its current version runs a real lightweight virtual machine, so it needs the platform underneath it. The checklist, in the order worth trying:

1. Enable the required Windows features. Both the subsystem feature and the virtual machine platform feature must be on. Turning one on without the other produces exactly this symptom.
2. Reboot. These features genuinely require it and the failure looks identical before and after enabling them until you do.
3. Check virtualisation is enabled in firmware. On many machines this is off by default. The setting is in the system firmware, usually under CPU or advanced settings, and is named after the processor vendor's virtualisation technology.
4. Check the task manager's performance tab. It reports whether virtualisation is enabled, which tells you whether step 3 is needed without rebooting into firmware to look.

A practical note on the enabling step: doing it through the graphical features dialogue and doing it from an elevated command line are equivalent, and the command line version is easier to verify and to repeat on another machine.

Whatever route you take, enable both features in one go and reboot once. Enabling one, rebooting, testing, then enabling the other is how people end up convinced that the first change did nothing.

After the reboot, verify before installing anything: the version command should report the subsystem version rather than an error. If it does not, the distribution install will fail again and the code will tell you no more than it did the first time.

Worth noting that the error codes in this area are not very informative by design — they surface from a lower layer and mean "the machine did not start" rather than why.

The more useful diagnostic is the Windows event log, under the virtualisation-related sources. It frequently contains a specific reason where the command line gave you a number, and it is where I go first now rather than working through the checklist blind.