This is for basic background so I can tell clients who ask me. If activation detects a VM, are you detecting actual VM hardware or could, say, VT-x being enabled by some AV result in the same symptom?
We have clients who get the error and swear they aren't using a VM. Naturally we are thinking Hyper-v, but I'd like to know about other possible explanations you know of.
All the best.
We're detecting actual VMs. We err on the side of false-negative (not detecting a VM when it is a VM).
If you want us to check this customer there are a few options:
1. Start with an activation that we can look at (so provide us a product key that has been activated on the machine).
2. Schedule a time to do a remote debug. So we can dig into the computer to see what's happening (likely the customer just no understanding VMs -- for instance, computers in the cloud are VMs)
The clients in question work for a big mega corp and are trying to activate the software from behind their firewalls. Even if you could reach them I doubt they would let you try. They all sorts of AV scareware junk installed, but of course we can't just say that.
The did however send us msinfo output, I see that "Hypervisor based security" and specifically "Credential Guard" is enabled. Is either of those a problem?
Also msinfo says that options for Hyper-v can't be displayed because a hypervisor is already detected. I don't use Hyper-v so don't know if that's normal for Win10 when running as a Hyper-v guest.
>> "The did however send us msinfo output, I see that "Hypervisor based security" "
>> "Also msinfo says that options for Hyper-v can't be displayed because a hypervisor is already detected."
Right, so Windows is telling you exactly what TurboActivate is telling you. They're in a VM (hypervisor).
Yes, I obviously understand that both things are telling me that. The question was whether you are aware of other things, such as enabling CredentialGuard that could produce the same results.
I'm a moderator on the VirtualBox forums. I understand what a VM is. What I don't know for certain is what TurboActivate (or msinfo) calls a VM. Hence my question, which anticipates the question I expect the client to ask.
Yes, because CredentialGuard uses Hyper-V: https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/
Ok, I had our own IT people set up a test scenario on a new laptop. I had him install our software on a bare metal Win10 PC and then do nothing except enable CredentialGuard. Activation (using TurboActivate) failed using the same error code as the client saw.
Yes, CredentialGuard relies on a component of Hyper-v, which does involve enabling VT-x, however my (very good) IT guy assures me (100% certain) that the Win 10 OS is _not_ running as a VM, the hardware is not virtualized, and it therefore should not be identified as a VM: i.e. apart from a limitation in TurboActivate I see no reason why our software should legitimately refuse to install on such a PC.
At least we now know for certain that CredentialGuard is a problem, so we can pass that knowledge along to the client.
Hi Wyatt,
Is there anyway for application software to distinguish between a physical Windows 10 machine with Credential/Device Guard enabled versus a virtual instance of Windows 10 running on Hyper-V?
Or are the two cases truly indistinguishable from application's point of view?
Carol
That is certainly the crux of the matter. I can tell a big client not to run our software in a VM, they understand why. They may not do it, but they understand why.
If I ask them to disable a security feature mandated by company policy then they may not understand why that.
Plus I'm sure that the two cases will be differentiable. It's just that in the past they didn't need to be.
