intel / haxm

Intel® Hardware Accelerated Execution Manager (Intel® HAXM)
BSD 3-Clause "New" or "Revised" License
3.22k stars 877 forks source link

"Failed to create HAX VM" #107

Open kltssinaga opened 6 years ago

kltssinaga commented 6 years ago

intelhaxm_failed

Hi guys, i am beginner in using Haxm. I am using android studio, when i try to launch emulator, its look like intelHaxm is not working properly. But when i check intelhaxm status in cmd prompt, it is "running". just fyi, i already checked my computer VT status and its already enabled.

if anybody have any answer, please share and it will be very helpfull.

wcwang commented 6 years ago

Thanks for your issue report. Could you try to download the latest release of HAXM v7.3.0? And run the below command to uninstall the existing version.

silent_install.bat -u

After that, install HAXM again as below,

silent_install.bat

Before above operations, could you help to check which version is used in your Android Studio? Tools > SDK Manager > Appearance & Behavior > System Settings > Android SDK > SDK Tools: HAXM installer version.

kltssinaga commented 6 years ago

Thank you for your consideration, Actually from beginning, i am using the latest version of HAXM v7.3.0. I already try your suggestion, but it shows a same result. As attached below :

intelhaxm_failed2

Fyi, i am using Windows 7, i5 2.9GHz, System File 64, RAM 8Gb.

If there another suggestion, it will be very helpfull. Thank you.

raphaelning commented 6 years ago

Thanks. There are two problems here, not sure which one is fatal:

a) RegGetValueW failed - apparently the emulator tries to read something from the Windows Registry. This is the first time we've seen an error like this, so I'm not sure what it's about. Unfortunately emulator doesn't print the error message correctly. I'll look into emulator code to see if this failure could lead to any HAXM error.

b) The backslash character \ is replaced by the yen sign. I've never used a Japanese version of Windows, so maybe you could help clarify this: is it merely a display issue, i.e. even if you type \, the Japanese font would render it on the screen using the yen sign? Or is it still possible to type \ and see it as-is on the screen?

BTW, could you append -verbose to your emulator command:

emulator -avd Nexus -verbose

kltssinaga commented 6 years ago

first thank you for your answer, about "b)" issue, in japanese version of windows, when we type " \ ", japanese font will render it automaticly become "¥"sign. As far as now there is no problem whenever i do programming in japanese version windows.

about -verbose, i already tried it. Considering theres a long messages, ill screen shot the "warning" and "error" one. intelhaxm_failed4 intelhaxm_failed5 intelhaxm_failed6

raphaelning commented 6 years ago

OK, it looks increasingly likely that this is an Android Emulator/QEMU bug, not a HAXM driver bug.

In short, this could be due to a flaw in emulator.exe's support for Unicode. If a Windows application is fully Unicode-aware, it should never call a Windows API function that takes an ANSI string (char * or LPSTR), e.g. CreateFileA or even CreateFile, which maps to CreateFileA when the string parameter is of type char *. Instead, it should always use the Unicode variant of that API, e.g. CreateFileW, which only accepts Unicode strings (wchar_t * or LPWSTR). Unfortunately, when trying to create the HAXM VM device node, emulator stores the path name (\\.\hax_vm00) in an ANSI string, and passes it to CreateFile. In effect, it calls CreateFileA instead of CreateFileW.

Here's what I think happens next:

  1. Windows implements CreateFileA as a wrapper around CreateFileW. Therefore, the first thing it does is convert the path name from ANSI to Unicode.
  2. This conversion probably depends on the system locale and may not be smart enough. In the Japanese locale, the meaning of ASCII character \ is ambiguous: it can represent either the backslash or the yen sign. My guess is that the conversion function makes the wrong choice and interprets it as the yen sign.
  3. CreateFileW rejects the Unicode path name ¥¥.¥hax_vm00 as invalid, and returns error code 2 (invalid argument).

This theory can also explain the RegGetValueW failed error, because the error code is also 2. There are several places in emulator code that can print RegGetValueW failed, and some of them actually follow an ANSI Windows API call, e.g. RegOpenKeyExA. Anyway, this error does not appear to be fatal.

I can write a patch for QEMU/Emulator to replace CreateFile, etc. with CreateFileW (thus eliminating the ANSI-to-Unicode conversion) . For now, could you try to change your system locale to US English? I know this is not a proper solution and may not even work at all, but I think it's worth a try.