Haxm not installeded error, but it is

[revelator]

I get this one in win 7 64 when trying the haxm version vt-e and vt-d is enabled in bios and latest haxm was installed and the tool for checking haxm also tells me it is enabled and working just not in the ntvdmx64 minnt-haxm build :S.

[leecher1337]

And you are sure that use the haxm-version supplied with this release and not the haxm standard installation (ntvdmx64 is not compatible with the default haxm-installation, only the supplied driver contains all code necessary)? Testsigning is on and test certificate is added to system? What does haxmloader tell you, if you try to load the .sys driver supplied with ntvdmx64?

[revelator]

Oh its incompatible with the standard intel haxm ? ok guess i need to uninstall that and try again allthough i suspected the supplied driver might overwrite the standard one but i see now that it does not.

[revelator]

uploaded a compile of the latest minnt/haxm version here https://sourceforge.net/projects/cbadvanced/files/ntvdmx64/ntvdmx64.7z/download if anyone else wants to try. I password protected the archive to get around nosy antivirus but even sourceforge goes ballistic and warns about malware because they cannot read the contents sigh... You can still download it though, the password is ntvdmx64.

Lenghty compile running on my pc atm. so i cannot restart to check if removing the unmodified haxm driver and reinstalling ntvdmx64 worked yet, i will report if it does though.

[leecher1337]

You should read the readme file: https://github.com/leecher1337/ntvdmx64/blob/master/ntvdmpatch/doc/haxm.txt

The NTVDM stops an IntelHaxm driver instance, if it detects one, as the original
driver doesn't offer the features required by NTVDMx64.
If there is a service named IntelHaxmNtvdm on the system, it tries to start it,
if not already running. 

So you don't necessarily need to uninstall the original Haxm, if you have other use for it, they just cannot run both at the same time. Therefore NTVDMx64 tries to stop an "original" HAXM driver and tries to load its special HAXM-variant which gets its own service name to not collide with the original HAXM driver,in case it finds it installed. However, as I don't have any driver signing certificate, my special driver version needs test signing being turned on on the target system so that the driver can get loaded (instructions are in readme). If anyone wants to sponsor a code signing certificate for the haxm driver, I can sign it, but unfortunetely such a certificate costs money. I already proposed some of my driver enhancement to HAXM project 2 years ago, but they were not committed yet.

[revelator]

Aye i read the document and did the things in there, compile still going my old board just died so im working on a somewhat slower haswell from 2013 heh. Ill see if it changes anything allthough my first attempt on the old board actually loaded your haxm driver this one seems to be not so inclined to unless test signing is on. Sad to hear that the haxm developers have not given your enhancements some thought :/ one would believe any improvement is good news.

[revelator]

Could a selfsigning certificate not be used ? theres a howto here http://woshub.com/how-to-sign-an-unsigned-driver-for-windows-7-x64/ but i suspect you allready tried that ?.

Edit: Ah no i see still need a cross sign from microsoft bleagh...

[leecher1337]

Could a selfsigning certificate not be used ? theres a howto here http://woshub.com/how-to-sign-an-unsigned-driver-for-windows-7-x64/ but i suspect you allready tried that ?.

That's exactly what I'm doing, but Testsigning needs to be turned on in order for this to work, as it would otherwise undermine the "security" that got introduced by charging driver writers to get their code running in x64 Windows (under the assumption that no malware-author would pay these ridiculously high fees, I guess?).

I think I have an error in mkrelease-haxm.bat, though. It copies the haxm-driver to the release\haxm directory and not to the lang dirs. Please copy the haxm-directory to the lang-subdir of the preferred release, so that the install.bat script can catch it and install the correct service and driver for you. I'll fix this shortly.

[revelator]

Ok tried with testsigning and it works now. Hmm the haxm dir is created in the lang dirs here when i do a build allthough if i do a build without haxm it also gets created in the lang dirs. Is that intentional ?.

[leecher1337]

The script accidentally copied the haxm-directory to the "release"-Directory which acts as a template for the language-dirs. Now as soon as you once ran mkrelease-minnt-haxm, it copied the haxm driver to it (but only after it created the language dirs for the first time, so I guess it only worked on second attempt). Now it stays in there, future mkrelease-minnt-haxm will succeed, because it's in the template directory alredy, but as you stated, it also gets copied on non-haxm builds now everytime (altough I recommend to start out completely fresh if you do a normal build as opposed to a haxm-build anyway). This little error in the batch file is fixed now. But releases-directory still needs to be deleted before switching between releases, otherwise the haxm-driver would be already there and the mkrelease-scripts don't do a prior delete.

[revelator]

I see good point :)

[revelator]

Btw careful if you are still on win 7 64 the latest update to windows internet security will kill the ltndvdm.dll loader and delete it and it is impossible to whitelist it anymore :S it simply does not give you the option. I suspect this will also be true for recent win 10 updates to internet security.

[leecher1337]

Microsoft Security Essentials? One more reason not to use crappy Antivirus applications that dont't even allow whitelisting.. Loader code will get some updates for Windows 2003 support, then it may be submitted for whitelisting to the AV vendors again. Some AV vendors are cooperative, others just don't care. I think Microsoft unfortunately is one of the latter, they usually don't react to false positive submissions.

[revelator]

Indeed :( i submitted a false positive on the loader some time back newer got an answer and now it seems they are going through hoops to get rid of it no matter what.

[revelator]

Changed to F-Secure allthough it is also getting flagged by that, atleast it will allow me to whitelist it so all is well.

I fear the day microsoft gets the idea that only there own antivirus solution is the only needed solution and then they bomb any attempt at installing your own.

[revelator]

Btw for others having problems with long path names messing up the DOS loader this might help https://www.rapidee.com its an editor for converting windows long path to short path or 8.3 format, it has helped me immesurably with getting other older software running again. A better approach might be to incorporate the LFN patch from Wengier Wu. This might take some porting though as the patch was intended for dosbox and vdos, but it should also be useable for ntvdmx64.

[leecher1337]

NTVDMX64 has incorporated LFN support already and it works quite fine. Of course, the DOS application you use must support LFN. You can test it i.e. with Volkov Commander (VC).. There is a function in the respective pane (press CTRL+N) to enable LFN support and you will see the long names. So that it not an issue of NTVDMx64, it just depends on your DOS application, therefore I don't see any use for the patch you suggest.

[revelator]

Was not aware of that, np then. The editor still comes in handy for some dos programs i found that dont support LFN so atleast that one is still valid for some.