-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot load Hypervisor when using whpxvm.dll #699
Comments
You need the 32bit whpx wrapper dlls. Unzip this to the dir with whpxvm.dll. |
Tried them. Didn't work. Same error. Anything I can to provide to figure this out? |
Windows Hypervisor Platform must be enabled. |
Can you try something else? Does qemu work with whpx? |
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. |
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? |
My thought was that you've got win10 pro and whpx might behave differently than win10 home. I'm out of things to suggest. |
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. |
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):
|
Here is their whpx.h include header file code:
|
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:
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. |
Where is that directory? I can't find it anywhere. Hypervisor Platform is installed. |
ah, it's in stable version only. |
Get the following error when trying to use the hypervisor via whpxvm.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.
The text was updated successfully, but these errors were encountered: