Skip navigation
Surface Pro 3 Tip: Hyper-V vs. Connected Standby

Surface Pro 3 Tip: Hyper-V vs. Connected Standby

They don't play nice

Surface Pro 3 has attracted interest from a wide range of new user types, including IT pros, business travelers, developers, creative professionals and more. But this expansion of the user base often results in obscure issues that impact certain users doing certain things. And here's a great example: The Hyper-V functionality in Windows 8.1 doesn't play nice with Surface Pro 3's Connected Standby functionality.

If you're not familiar, Hyper-V is Microsoft's virtualization platform. It debuted in Windows Server 2008 and is designed first and foremost for such systems, and of course for cloud-based platforms like Microsoft Azure, where customers can run virtualized PCs remotely. Hyper-V can be used for many reasons, but in the context of the Windows client, it's most often used by developers who need to test their apps in different OS versions.

Hyper-V Manager, for managing Hyper-V instances locally and/or on remote servers

It's also a requirement for Windows Phone 8+ software development, since the device emulators that you test your new apps on run within Hyper-V. And that's why Hyper-V ended up on my Surface Pro 3: I had installed Visual Studio 2013 Express for Windows, which is used to create Modern apps for Windows 8.x, Windows Phone 8.x apps, and universal apps that can run on both platforms.

(I have never stopped dabbling with software development—in fact, I spent hours last night on this very task—and also use these tools to better understand both what's happening under the covers and what Microsoft really names things.)

Visual Studio runs wonderfully on Surface Pro 3, especially the version I have, with its 8 GB of RAM and speedy 256 GB SSD. It's a natural pairing, and Surface Pro 3 an ideal mobile development workstation.

Visual Studio with emulated Windows Phone handset running in Client Hyper-V

If you're familiar with Hyper-V, you know that it hasn't always played nice with power management, which makes sense given its server/cloud roots. But the version of Hyper-V in the client versions of Windows 8+ is a little different. It's called Client Hyper-V and Microsoft has evolved this platform to accommodate some of the needs of a typical PC. So it supports Wi-Fi based networking, for example, and can operate normally with the Sleep and Hibernation power management modes.

There's just one problem. Surface Pro 3 includes support for advanced, device-like Connected Standby (now called InstantGo) power management functionality. Indeed, it's one of this device's key differentiators. But Hyper-V is not compatible with Connected Standby. So if you install Hyper-V on Surface Pro 3 (or any other Connected Standby-based system), it disables Connected Standby.

In real world terms, what this means is that Surface Pro 3 stops acting like a device and acts more like a PC. When you close the Type Cover, the machine doesn't sleep. If you press the button to wake it up, it comes up out of hibernation (i.e. boots for several seconds) instead of just coming on instantly. It's not horrible. But it's not the fluid, seamless experience that Surface Pro 3 users expect.

You can see what's going on by using the powercfg.exe command line utility. Surface Pro 3 will normally report that it supports Connected Standby, Hibernate and Fast Startup.

But if you enable Hyper-V, Connected Standby is no longer listed. Only Hibernate and Fast Startup are supported.

There is a workaround, and its applicability will depend on your needs.

If you're only using Hyper-V occasionally, you can disable and enable Hyper-V on the fly via an admin-level command prompt. This information comes courtesy of Microsoft program manager James Clarke (via Rafael Rivera, my Windows 8.1 Field Guide co-author).

To disable Hyper-V and restore Connected Standby functionality, use the following at the command line:

bcdedit /set hypervisorlaunchtype off

To re-enable Hyper-V when you need it (and thus disable Connected Standby again):

bcdedit /set hypervisorlaunchtype auto

The bad news? You need to reboot after change. The good news? It works great.

If you actually use Hyper-V regularly for whatever reason, this isn't ideal, so my advice is to just suck it up and forget about Connected Standby. But at least now you'll understand why the device isn't behaving optimally.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish