Cannot load Hypervisor when using whpxvm.dll

[dcharlespyle]

Get the following error when trying to use the hypervisor via whpxvm.dll:

init_vm86:364 Failed to load WinHvPlatform.dll.

I have checked and confirmed that Windows hypervisor platform is installed and that the DLL files are present. They are the latest, on Windows 10 Pro build 19640. Didn't work on previous builds either. Any ideas?

Here is the trace: trace.txt

I currently use Hyper-V to run Linux apps concurrently with Windows. However, I get the same error regardless of whether hypervisor is running or not. Same regardless of whether or not I am running app in Windows Subsystem for Linux.

[cracyc]

You need the 32bit whpx wrapper dlls. Unzip this to the dir with whpxvm.dll. whpx.zip

[dcharlespyle]

Tried them. Didn't work. Same error. Anything I can to provide to figure this out?

[dcharlespyle]

Oh, and there is another error on some runs.

[otya128]

Windows Hypervisor Platform must be enabled.

[dcharlespyle]

Windows Hypervisor Platform is installed and enabled.

Anything else to check?

[dcharlespyle]

Hypervisor is detected.

[cracyc]

Can you try something else? Does qemu work with whpx?

[dcharlespyle]

Yes, QEMU does work with WHPX. Works perfectly.

[dcharlespyle]

Could there be another 32-bit file missing from the above whpx zip archive? There are only three files in the zip file. WinHvPlatform.dll also has another file that is supposed to be with it, called WinHvEmulation.dll. That wasn't included in the above zip file. Might a 32-bit version of that file make a difference? I don't have a 32-bit version at the moment but my 64-bit computer has a file of same name. Already tried that one but it didn't help.

[cracyc]

There is no 32bit WinHvEmulation.dll because whpx is 64bit only and winevdm doesn't use it anyway. The dlls in the zip load the WinHvPlatform.dll 64bit dll into a 32bit process. I'm not sure what else could be wrong. The 64bit dll loader seems to working otherwise you wouldn't have gotten the ERROR_HV_NOT_PRESENT (0xc0351000) hresult. Maybe try running winevdm elevated?

[dcharlespyle]

When I run winevdm elevated I get the following:

But I know that the hypervisor is present because QEMU works and runs the hypervisor, and Hyper-V also is working (which wouldn't, if there were no hypervisor available). It is like hypervisor isn't being initialized by winevdm. Winevdm also isn't the only app with a similar issue, though. On further testing, Intel's Processor ID app and Microsoft's Coreinfo also won't even show VT-x capability in the processor if Hyper-V hypervisor is running. I turn hypervisor off and VT-x shows up again in the Processor ID program and Coreinfo (as I know it exists in the processor and also is present in the UEFI BIOS). Somehow, QEMU gets past all that and runs concurrently with Hyper-V, using whpx acceleration without issues.

[dcharlespyle]

Tried another 16-bit application, and still got this when winevdm is elevated: Bummed that elevation doesn't change anything.

[cracyc]

My thought was that you've got win10 pro and whpx might behave differently than win10 home. I'm out of things to suggest.

[dcharlespyle]

That wouldn't surprise me if there were a difference in behavior. It probably also doesn't help that I am using a Preview version of Win 10 Pro. I'm out of ideas for things to try, too, at the moment. I am thinking of combing through some of QEMU's code, though, to see if something from their codebase might help the situation. Somehow, they managed to get past the obstacle. I'm wondering whether there is some security model change at the root of it somewhere.

[dcharlespyle]

QEMU has a whpx-stub with a Microsoft copyright, as follows (but it doesn't seem to do a whole lot (or, maybe it does a lot more than I think)); have to find the time to do some more digging for possibilities):

/*
 * QEMU Windows Hypervisor Platform accelerator (WHPX) stub
 *
 * Copyright Microsoft Corp. 2017
 *
 * This work is licensed under the terms of the GNU GPL, version 2 or later.
 * See the COPYING file in the top-level directory.
 *
 */

#include "qemu/osdep.h"
#include "cpu.h"
#include "sysemu/whpx.h"

int whpx_init_vcpu(CPUState *cpu)
{
    return -1;
}

int whpx_vcpu_exec(CPUState *cpu)
{
    return -1;
}

void whpx_destroy_vcpu(CPUState *cpu)
{
}

void whpx_vcpu_kick(CPUState *cpu)
{
}

void whpx_cpu_synchronize_state(CPUState *cpu)
{
}

void whpx_cpu_synchronize_post_reset(CPUState *cpu)
{
}

void whpx_cpu_synchronize_post_init(CPUState *cpu)
{
}

void whpx_cpu_synchronize_pre_loadvm(CPUState *cpu)
{
}

[dcharlespyle]

Here is their whpx.h include header file code:

/*
 * QEMU Windows Hypervisor Platform accelerator (WHPX) support
 *
 * Copyright Microsoft, Corp. 2017
 *
 * Authors:
 *
 * This work is licensed under the terms of the GNU GPL, version 2 or later.
 * See the COPYING file in the top-level directory.
 *
 */

#ifndef QEMU_WHPX_H
#define QEMU_WHPX_H


int whpx_init_vcpu(CPUState *cpu);
int whpx_vcpu_exec(CPUState *cpu);
void whpx_destroy_vcpu(CPUState *cpu);
void whpx_vcpu_kick(CPUState *cpu);


void whpx_cpu_synchronize_state(CPUState *cpu);
void whpx_cpu_synchronize_post_reset(CPUState *cpu);
void whpx_cpu_synchronize_post_init(CPUState *cpu);
void whpx_cpu_synchronize_pre_loadvm(CPUState *cpu);

#ifdef CONFIG_WHPX

int whpx_enabled(void);

#else /* CONFIG_WHPX */

#define whpx_enabled() (0)

#endif /* CONFIG_WHPX */

/* state subset only touched by the VCPU itself during runtime */
#define WHPX_SET_RUNTIME_STATE   1
/* state subset modified during VCPU reset */
#define WHPX_SET_RESET_STATE     2
/* full state set, modified during initialization or on vmload */
#define WHPX_SET_FULL_STATE      3

#endif /* QEMU_WHPX_H */

[dcharlespyle]

Don't recall if something like this can result in the current situation on my machine (been a long while since I programmed anything for Windows and carbon monoxide poisoning took a lot of said knowledge away from me, so please bear with me).

Lines 24-35 of the current whpxvm.c file:

HRESULT(WINAPI*pWHvCreateVirtualProcessor)(
    _In_ WHV_PARTITION_HANDLE Partition,
    _In_ UINT32 VpIndex,
    _In_ UINT32 Flags
    );
HRESULT(WINAPI *pWHvGetVirtualProcessorRegisters)(
    _In_ WHV_PARTITION_HANDLE Partition,
    _In_ UINT32 VpIndex,
    _In_reads_(RegisterCount) const WHV_REGISTER_NAME* RegisterNames,
    _In_ UINT32 RegisterCount,
    _Out_writes_(RegisterCount) WHV_REGISTER_VALUE* RegisterValues
    );

Line 24 seems to omit a space between asterisk (dereference operator, pointer) and WINAPI, unlike all the other ones in the file. Shouldn't there be a space there between WINAPI and the dereference operator? Could that affect some systems differently than others? If no virtual processor is created, then would not that also result in one not being available on some systems? Inconsistently formatted line without space preceding dereference operator, no virtual processor, no processor registers, no processor registers to set? Maybe there are differences in how the codebases of Windows 10 Home and Windows 10 Pro, or even Windows 10 Pro Insider Preview builds, handle such formatted API calls? I may be all wet to think that but it is something my eye caught while looking through the code. May be a whole lot of rambling about nothing on my part but thought I might bring it up.

[regs01]

You need the 32bit whpx wrapper dlls. Unzip this to the dir with whpxvm.dll. whpx.zip

Where is that directory? I can't find it anywhere. Hypervisor Platform is installed.

[regs01]

ah, it's in stable version only.