A case that Hyper-V freezes host operating system

Two days ago I set up a new virtual machine for applications that require isolated security. When I put my computer into Connected Standby mode, I noticed SoC fan didn’t stop. To verify whether it was OS inconsistency or persistent issue, I manually initiated a system restart. However, it froze at login screen then. Nothing responded, including Ctrl + Alt + Delete key sequence. Attempting to force shutdown and start the computer almost didn’t improve the situation. After about ten attempts I managed to enter my desktop. There was no clue in event viewer: everything went well then suddenly the system froze.

I remembered that an alternative OS loader entry was configured to bypass Hypervisor launch at startup. I selected this entry to see whether it was related to Hyper-V. Test results indicated the freeze issue was strongly related to Hyper-V.

I tried to remember what I did before virtual machine configuration. I removed a virtual switch bridged to Surface Ethernet Adapter on my Surface Dock, then added a virtual switch bridged to VMware NAT adapter (which works better with Wireless network). Then I checked adapters in Network and Sharing Center, the old virtual switch didn’t get removed at all – and the “Remove” menu entry was unavailable. At last, I removed this adapter from Device Manager, and the issue was resolved.

This issue is likely related to OS inconsistency. When Hyper-V infrastructure attempts to initialize (bring up) all enabled network adapters including these Hyper-V virtual switches, the “removed” adapter is brought up, then enters failure state due to inconsistency in configuration. Because host operating system is a virtual machine on Hyper-V (with privileges), the host OS didn’t even get a chance to record what happened at that point.

The good thing is that I fixed it by myself; The bad thing is I missed an opportunity to report this bug and let Microsoft fix it.


My light workload SQL Server process eats CPU!

You might want to see this to turn memory page lock on.


Openconnect and Active Directory Certificate Service

Previously my openconnect server deployment plan utilizes PAM authentication (via Kerberos/Active Directory) as the primary authentication method. It works but it’s complicated (password every time). I just enabled certificate authentication today and it worked fine.

Things to note

  • Enable certificate authentication as an alternative authentication method (up to you, but some guys in our domain don’t use certificate-capable device)
  • Use “Smartcard Logon” certificate template with subject information in “Common Name” style
  • Set OID as user identifier in openconnect server configuration
  • Provision root CA, CRL and OCSP (CRL and OCSP are optional but essential as part of the best-practice)

Something else

I provisioned the same certificate in my Yubikey PIV and TPM-based virtual smartcard, but neither works for AnyConnect client. Certificate in user certificate store is fine.

AnyConnect client refused to use smartcard
AnyConnect client refused to use smartcard