How to set up synthetic kernel debugging for Hyper-V virtual machines

Windows 8 (and Windows Server 2012) introduced a new debugging transport called KDNET. As the name implies, it allows kernel debugging over a network and can be faster and easier to set up than its predecessors (e.g. COM and IEEE 1394).

MSDN has great background information on setting up kernel debugging via Visual Studio and by hand, however, Microsoft's official stance on virtual machine debugging is to continue using the old and slow serial port. Even on generation 2 virtual machines. This makes some tasks, like dumping memory or resolving symbols, a slow and tedious task.

But unofficially you can instead use what's internally referred to as "synthetic debugging".

![Figure 1 - Simplified Synthetic Debugging Architecture](/content/images/2015/02/hv_synthetic_simplified.png)
Figure 1 - Simplified Synthetic Debugging Architecture

To understand how it works, first consider a common KDNET scenario on a physical machine. When KDNET is enabled, the Microsoft Kernel Debug Network Adapter built into Windows takes over (and shares) the physical network device installed in the machine. Communication to and from the machine (and kernel debugger) occurs over the network as expected and life is grand. But virtualized environments (in child partitions) add another layer of abstraction to the underlying hardware that presents a problem -- the Kernel Debug Network Adapter cannot latch directly onto the physical network device.

Cue the magic behind synthetic debugging.

To overcome the inability to directly control network hardware, KDNET was built with smarts to detect virtualized environments and switch to communicating over VMBus -- a inter-partition communication mechanism -- with the host operating system (in the parent partition), as shown in Figure 1. The parent then exposes a KDNET endpoint for you to communicate with the virtualized environment over the network. With this set up, the virtualized environment doesn't require network connectivity!

To set up synthetic debugging (for Windows), you need to be running:

  • Windows 8 or Windows Server 2012+ on the host side
  • Windows 8 or Windows Server 2012+ on the guest side (generation 1 or 2)

Here's the step-by-step:

  1. On the guest machine, open an elevated command prompt and issue the commands:

    bcdedit /dbgsettings NET HOSTIP:1.2.3.4 PORT:55555
    bcdedit /debug on
    

    When KDNET kicks in and detects the virtualized environment, the HOSTIP and PORT parameter values are ignored, in favor of the VMBus.

  2. Copy the key value displayed and keep it handy.

  3. On the host machine, open an elevated Powershell instance and run the following script after adjusting the VMName and DesiredDebugPort values:

    $VMName = "Virtual Machine name here"
    $DesiredDebugPort = 55555
    
    $MgmtSvc = gwmi -Class "Msvm_VirtualSystemManagementService" `
    	-Namespace "root\virtualization\v2"
    
    $VM = Get-VM -VMName $VMName
    $Data = gwmi -Namespace "root\virtualization\v2" `
    	-class Msvm_VirtualSystemSettingData
    	| ? ConfigurationID -eq $VM.Id
    
    $Data.DebugPort = $DesiredDebugPort
    $Data.DebugPortEnabled = 1
    $MgmtSvc.ModifySystemSettings($Data.GetText(1))
    

    Be sure to specify an open ephermeral (49152-65535) UDP port here.

    When the machine is powered on (or reset), the virtual machine's specific Virtual Machine Worker Process (vmwp.exe) will attempt to bind to that port on all (management) interfaces.

  4. Power cycle the guest machine. A reset is not sufficient as it doesn't tear down the Virtual Machine Worker Process.

  5. On any machine on the network, connect a debugger to the Hyper-V host machine with the port and key from earlier. For example, to connect with WinDbg, issue the following command:

    windbg.exe -k net:target=hyperv-host,port=55555,key=a.b.c.d
    

When not configured correctly, synthetic debugging can be quite a pain to troubleshoot. Here are some tips if you run into problems:

  • Ensure the guest is running Windows 8 or above and the active BCD entry is configured correctly (via bcdedit).

  • Ensure the guest's Virtual Machine Worker Process has bound to the port you specified with TcpView or CurrPorts. This can be extremely problematic if your Hyper-V host is also a DNS server like mine.

  • Ensure no other virtual machines are configured to use the same port.

  • Ensure any firewalls in the way are configured to allow UDP traffic through via specified debug port.

Happy debugging!

New experimental console features in Windows "Threshold"

Microsoft is expected to deliver its first technical preview release of Windows codenamed "Threshold" tomorrowish. And while the usual outlets will be covering the big changes, I wanted to document a relatively smaller set of welcome changes to the Command Prompt (and the underlying Console Host).

Experimental Tab in the new Command Prompt

Here's the new experimental tab in Threshold's Command Prompt properties window. This tab exposes switches that turn on and off new experimental features that apply to all console windows -- including the one that hosts PowerShell.

Let's go over them.

Enable line wrapping selection

In previous versions of the Command Prompt, selecting text for copy involved crudely painting a selection box on the screen and hitting the Enter key. But you weren't done. You also had to paste that text into a text editor to correct the abrupt line endings. It was a terribly slow and error-prone process.

But that's all in the past now.

In Threshold, you can now select and copy text as you would expect to in any text editor.

Filter clipboard contents on paste

Pasted text void of fancy quotes and tabs in the new Command Prompt

Ever pasted in a command only to realize (after it errored out) it was peppered with tabs and fancy quotation marks? I have. And I won't ever again, thanks to a new paste filter in Threshold.

Now when pasting text, fancy quotation marks are converted into their straighter equivalents and stray tabs are removed.

Wrap text output on resize

Text resized in new Command Prompt

Resizing the Command Prompt window has always been an alien task. If you somehow managed to get the window to shrink, a horizontal scrollbar would appear and text would remain static and not reflow or wrap given the new constraints.

With this feature enabled, however, the window and its text behave the way you expect.

Enable new Ctrl key shortcuts

Some handy new keyboard shortcuts have found their way into the new Command Prompt as well. I say some because I can't be sure I covered them all. We'll have to wait for the official documentation to come online.

  • CTRL + A - Select all
  • CTRL + C - Copy
  • CTRL + F - Find
  • CTRL + M - Mark
  • CTRL + V - Paste
  • CTRL + / - Scroll (line) up/down
  • CTRL + PgUp/PgDn - Scroll (page) up/down

Extended edit keys

There's not a lot of information available on extended edit keys. This feature has existed in Windows for quite some time but has never really been exposed to users until Threshold.

We'll have to wait for the official word on this feature.

Trim leading zeros on selection

Leading zeros selected in the new Command Prompt

If you find yourself working with a lot of numerical data in the Command Prompt, you may want to turn this on.

When selecting a number with leading zeros (e.g. via double-click), the selection box will begin after any insignificant zeros present. For example, 000001234 becomes 1234. Hexadecimal and decimal prefaced numbers, however, override this rule. That is, 0x1234 and 0n1234 remain selectable in their entirety.

Opacity

This one is an oddball.

This slider ranges from a ghostly 30% all the way up to 100% (default). But it affects all console windows on your system and the entire host window, not just the background. (That color is still tweakable via the Properties window, mind you.)

As translucency increases, text readability decreases, so it's not immediately clear who would ever use this. But it's a neat technical demo and nods at the Windows enthusiast crowd that has undoubtly been asking for this for years.

Taking a peek at Xbox One-formatted disks in Windows

A few weeks ago Microsoft pushed out an update to Xbox One, enabling support for external storage via its USB 3.0 ports. It works as you would expect -- you plug in a disk, it gets formatted, and away you go. But you lose the ability to use that disk on other PCs and devices. Let's take a look at why.

Here's what an Xbox One-formatted disk looks like on a Windows PC via Disk Management:

Unknown disk in Disk Management

Windows clearly has no idea what's going on here, which isn't surprising. The Not Initialized state here indicates the disk doesn't have the expected Master Boot Record (MBR) at the beginning (sector 0) of the disk.

Here's what the beginning of the disk looks like in a hex editor:

A slice of the disk's sector 0 in a hex editor

On a traditional disk, the first 446 bytes of this sector would contain bootstrap code used for boot purposes. The Xbox One isn't booting from the disk so this area is blanked out with the exception of some placeholder bytes near the end.

The bytes that follow represent various disk and partition parameters.

The EE byte sits in the partition type slot and is used by Microsoft to indicate a GUID Partition Table (GPT) partitioning scheme is in use. Windows should have no problem recognizing this.

The last two bytes of sector 0 signify what's called the boot signature -- an arbitrary but known marker to indicate that this sector represents a MBR structure and isn't just a bunch of random data. Windows (and most systems) expect these two bytes to be 55 AA (0xAA55). The Xbox One, however, opted for 99 CC (0xCC99). This is why Windows thinks the disk is uninitialized.

Overwriting the boot signature with the expected bytes and unplugging/replugging the drive results in a happier Disk Management tool.

Recognized disk in Disk Management

And here's a view from File Explorer:

Recognized disk in File Explorer

(That file with the GUID represents the Netflix app that I copied onto the disk.)

Presumably, you could write some code to swap the boot signature bytes to flip-flop between PC and Xbox One disk compatibility. But I'd be weary of relying on any data stored on this file system given Windows still thinks "there's a problem with this drive". I suspect, like FAT on Xbox 360, the NTFS filesystem structure was tweaked to meet the needs of Xbox One.

Maybe we should start calling this NTFSX.

The WinX Menu and its hashing algorithm

This post first appeared on Within Windows on April 4, 2012.

Last week, a reader – "Windows Fan" – tipped me off to an article on Vishal Guptas blog indicating how to customize the new WinX menu in Windows 8. (You know, the menu that appears when you right-click the lower-left Start tip.) Not happy with hacking core system files and peeling back file system security, I dug a little deeper to understand what's going on and came up with a simpler solution.

So let's start at the top. The WinX menu is a simple context menu that appears when you right-click the Start tip that appears when you squish the mouse into the lower-left corner of the screen. The purpose of the menu is not to act as a Start Menu replacement but rather as a springboard to perform advanced system functions that are slightly out of reach. For example, if you’re trying to kill a runaway system process, you will probably need quick access to Task Manager, an elevated Command Prompt, and perhaps Programs and Features to uninstall the culprit app. Launching those applications in succession via the Start Screen would be a pain in the rump.

The entries on the menu are driven by shortcut (.lnk) files present in each Group folder located at %LocalAppData%\Microsoft\Windows\WinX. But you can’t manipulate the shortcuts within or add new ones. That’s because at first invocation (e.g. a fresh boot), the menu scans for and only adds approved shortcuts. Why? Again, Microsoft doesn’t want this becoming another Start Menu or, worse, an icon landfill for installers a la Quick Launch back in Windows Vista.

But an argument could be made for that small sliver of folks who genuinely want to lightly extend the menu, perhaps with utilities such as Process Monitor and DebugView. So let’s talk about what makes an approved shortcut.

An approved shortcut – a moniker I made up – is a .lnk file that has the appropriate markings to indicate to Windows “Hey, I’m special.” The marking is a simple 4-byte hash of several pieces of information. From the .lnk itself, two points are collected:

The link’s target application path/file (e.g. C:\Games\Minecraft.exe)
The link’s target application arguments (e.g. –windowed)
The third ingredient is simply a hard-coded chunk of text, or a salt if you will, to keep things interesting. That string is, literally, “Do not prehash links. This should only be done by the user.”

With these three strings in hand, Windows then glues them together, lowercases everything, and runs them through the HashData function. But you’re probably wondering at this point, what does it compare to?

Let’s shift our focus to .lnk files. We know them as shortcuts to things. But they’re officially called Shell Links and can store a lot of information on other data objects in Windows. More specifically, they support storing a structure of data called a PropertyStoreDataBlock that acts as a container for arbitrary string or numeric key/value pairs. Yep, the “WinX hash” is stored in here. If you’re curious, the key can be defined as such:

DEFINE_PROPERTYKEY(PKEY_WINX_HASH,
0xFB8D2D7B, 0x90D1, 0x4E34, 0xBF, 0x60, 0x6E, 0xAC, 0x09, 0x92, 0x2B, 0xBF, 0x02);

So to tie it all together, Windows – the Shell specifically – iterates through the .lnk files in each GroupN folder; opens them up; pulls out and concatenates the target path, args, and an arbitrary string; then finally hashes the result. This hash is then compared with the one stored in the .lnk to determine if it’s approved. Rinse and repeat.

If you’re interested in stuffing items into that menu, I wrote a tool to mark your shortcuts as approved. (The source code is on Github, if you're interested.)

NOTE: The WinX menu doesn’t seem to handle architecture-dependent environment string expansion very well, so shortcuts to %ProgramFiles% may not work (e.g. Internet Explorer 64-bit). I suspect this is a WONTFIX given it’s not designed to work with your own shortcuts.

Tinkering with uncertified Play To devices on Windows 8

Microsoft supports a feature in Windows called Play To that allows you to stream music, video, and photos from your computer to TVs or speakers on your home network. But anyone who has tried using Play To knows it can be an extremely frustrating experience, thanks in part to brittle OEM implementations of the underlying Digital Living Network Alliance (DLNA) spec.

As part of its continuing DLNA compliance push, Windows 8 now requires that Play To devices be certified before use in the new Windows Store application model. (But not via desktop applications.) That is, an uncertified device will not appear in the Devices charm from a Windows Store app (e.g. Video). But for those of us geeks with flaky sort-of-working DLNA devices, we're out of luck.

Or were, anyway.

As part of a Powershell learning experience, I wrote a script that suspends the aforementioned checks in Windows 8 and offers facilities to generate the required device metadata.

Here's a quick run through:

  • Read the readme, just in case.
  • Download the latest playto-tools script + dependencies from my repository.
  • Open an administrative instance of Powershell, in the directory holding all the downloaded files.
  • Dot source the script. (. .\playto-tools.ps1)
  • Call Suspend-CertifiedDeviceChecks to patch the Device Property Manager to accept unsigned metadata.
  • Call Get-MediaRenderers to list the media renderers on your network. You need to grab the hardware ID of the device you wish to enable Play To for.
  • Pass this hardware ID (and the -Install switch) to New-DeviceMetadata to generate and install metadata into the Device Metadata Store.

In my case, I was testing with one device and was able to string everything together:

New-DeviceMetadata (Get-MediaRenderers | Select -First 1 -exp HardwareID) -Install

Alternatively, you could also boot Windows in test mode.

Dissecting the //build/ Badge (Part 2)

A little under a month ago, I dissolved Paul Thurrott's //build/ badge to reveal an embedded NFC integrated circuit (IC). But I had to stop short of actually reading its data due to the lack of a proper NFC reader. (Windows Phone 8 doesn't give you raw NFC access.) I purchased an ACS ACR122T and after weeks of waiting and experimenting I can now complete the story.

So, let's start off with a correction. In Part 1, I incorrectly guessed that the IC was a MIFARE Ultralight. Turns out, it's an older MIFARE Classic 1K complete with key-based security. But before I wrote the IC off as encrypted and inaccessible, I learned that these ICs were compromised back in 2008 -- with a card-only attack following in early 2009.

Let's take a brief moment to talk about these keys.

Without getting too technical, these NFC ICs have chunks of data. Each chunk of data can be secured via a pair of keys -- A and B. Each of these keys can be used separately to access the data it protects. (For example, you may give a read-only key A to conference vendors, while maintaining the read-write key B for administrative purposes.)

Back to the badge.

Without access to an authorized //build/ badge reader, I had to use a software implementation (mfcuk) of the card-only attack I mentioned earlier to recover keys A and B. After weeks of painfully fiddling with the timings of the attack, I successfully recovered key B on one chunk of data. (I then made quick work of the rest of the keys/chunks using another attack [mfoc].)

Key A was recovered but isn't worth sharing because it appears to be unique per badge. (Tested with two badges.) Key A is usually programmed as a read-only key -- presumably for vendors on the conference floor. But given its uniqueness I'm confused as to how vendors would obtain a valid key at scan time. Perhaps the readers were networked to a key management system? Or maybe Key A is computed at runtime using a mash of the badge unique ID and a shared secret? Or maybe there's a handful of keys per attendee group (e.g. media, student, presenter). What do you think?

Key B is static, thankfully. On two badges I examined, Key B was given write permissions card-wide. So I named it The //build/ Badge Administrative Key. That key is f4a9ef2afc6d.

Using the Badge Administrative Key, I dumped out the entire //build/ badge. Surprisingly, it's not empty! It contains the following information:

  • Two sets of identifiers(?) (6 digit, 4 digit) (e.g. 756552, 1269)
  • Badge Full Name
  • Badge Title
  • Full address
  • Phone number
  • Email address
  • Affiliation label, if applicable (e.g. Media)

So if you're planning to toss the badge into the trash, you may want first wipe the IC. But if you're a developer looking to dip into NFC, you may want to salvage the tag and format it to NDEF specs so you have something Windows Phone compatible to play with.

Regardless, case closed.

Dissecting the //build/ Badge (Part 1)

If you were at //build/ this year, you probably remember tapping your badge on a reader before picking up your free Surface and Nokia Lumia 920 devices. It turns out, the badge hides NFC tech as opposed to that boring ol' RFID stuff.

Tear down photos follow.

8168776248_f443bae6f7
I managed to steal a badge from some random chump.

8168777656_033c190f0c
Acetone made quick work of the plastic badge... Wait, what's that?

8168778444_876ea786b7
NXP MIFARE Ultralight NFC IC

But what secrets does it store within? Sadly, the tag doesn't appear to have been NDEF formatted so reading it with Windows Phone is out. (It is detected just fine, though.) I ordered an ACR122T reader/writer to lend a hand so check back in a week or so for the big reveal.

Disabling animations in Office 2013

This is a legacy post imported from my previous Within Windows blog.

Back in April, Paul Thurrott wrote about an awful typing animation present in Office -- particularly Word -- "15" Technical Preview. While this animation has been tweaked and improved in the new Office 2013 Customer Preview, some of you may wish to turn it off.

You can do so by navigating to HKCU\Software\Microsoft\Office\15.0\Common\Graphics and creating a DWORD value named DisableAnimations. Set its data to 1 and you're set.

The WinX Menu and its hashing algorithm revisited

This post first appeared on Within Windows on June 1, 2012.

In an April post, I covered the new "Win-X" menu, named after the keyboard shortcut used to access it, and how it features a hashing algorithm to determine if a shortcut was approved for display. I also offered a tool that would sign shortcuts, upgrading them the to coveted approved status.

This won't be a regurgitation of all that again. Instead, I will simply cover some changes made to the menu in Windows 8 Release Preview. (And more importantly, offer an updated version of hashlnk!)

First of the notable changes to the WinX menu in Windows 8 Release Preview is the unfortunate removal of the Network Connections shortcut. This shortcut provided a sneaky backdoor to the legacy Network Connections area, offering immediate access to network interfaces -- you know, the very items we stumble around looking for in that abhorrent Network and Sharing Center. But on the flip side, Network Connections is becoming less and less useful, thanks to better software (e.g. Windows, network drivers/stack) and the cluttering up of pseudo-interfaces like Virtual Wifi NICs, VMware and Hyper-V virtual switches and complex VPN thingamajigs. No worries.

The more important change, however, was to its hashing algorithm that sussed out whether a shortcut was approved for display in the menu. I created a tool for folks to upgrade their own shortcut files (.lnk) however it broke with the new Windows release. Let's dig a little deeper into why.

In previous versions of Windows 8, WinX would grab a shortcut, pull out the target path and arguments, hash it, and compare with an embedded value in the shortcut. This worked great, until shortcuts with environment variables were used. (I noted this as a bug in my previous post.)

For example, let's consider a shortcut pointing to %SystemRoot%\Explorer.exe. In the process of examining the shortcut, the WinX menu would expand this path -- that is replace any variables present with values fed from the OS. On a 64-bit system, the path would likely expand to C:\Windows. In some rare cases, however, this could expand to possibly C:\Winnt or even C:\Winderz for the haters out there. (The drive letter in previous versions of the algorithm was ignored.) This means the hash could be viewed as invalid and not render in the WinX menu; that kind of runtime inconsistency just won't fly in Windows.

So it was fixed.

But how?

Nothing magic really. WinX now takes the path and runs it through a quick search and replace function. It looks for matches using OS backed "folder IDs", specifically FOLDERID_ProgramFiles, FOLDERID_System, and FOLDERID_Windows. On a typical 64-bit system, these IDs would point to the values "C:\Program Files", "C:\Windows\System32", and "C:\Windows". If a match is found, WinX strips this part of the path out and replaces it with the folder ID's GUID.

To continue our example above, %SystemRoot%\Explorer.exe would expand to C:\Windows\Explorer. Having FOLDERID_System in the path, it would then ultimately transmogrify to {F38BF404-1D43-42F2-9305-67DE0B28FC23}\Explorer.exe.

That's it.

If you want to re-sign your shortcuts to now work on Windows 8 Release Preview, I updated the hashlnk tool bringing it to 0.2.0.0. Both the binaries and code at on GitHub.

Feedback is very welcome.