Building a Microsoft Wireless Display Adapter base image

After I picked up (and disassembled) a Microsoft Wireless Display Adapter, I started bugging Microsoft for the source code to the Linux-powered base image -- the underlying host operating system and support infrastructure. After three months of back and forth, the Source Code Compliance Team finally uploaded a buildroot that can be used to generate a base image. Unfortunately, it came with zero documentation.

Here's my general step-by-step on building the base image with Hyper-V and CentOS 7. Feedback is welcome.

  1. Create a virtual machine and install CentOS 7.

    • If you choose to go down the Generation 2 VM route (recommended), don't forget to shut off Secure Boot.

    • Ensure you create a non-root administrative user during install. Mine will be rafael and will be used for all commands henceforth.

  2. Download the buildroot.

    You only need the buildroot package from the Third Party Source Code Disclosures website.

    A little background: Initially, Microsoft uploaded a bunch of smaller buildroot output artifacts. But after some back and forth, I was able to convince them to upload the buildroot itself, making the other files less useful.

    You'll also want to get the zip copied over and unzipped in the virtual machine. The following instructions will assume you unzipped the buildroot folder in the user's home directory (~/buildroot).

  3. Install some prerequisites.

    Buildroot requires a few packages to operate. They can be installed easily via one command:

    sudo yum install net-tools flex which sed make bison binutils gcc gcc-c++ bash patch gzip bzip2 texinfo perl tar cpio unzip rsync wget ncurses-devel cvs git mercurial subversion python bzr  
    

    If you decide to use 64-bit version of CentOS, you'll also need some 32-bit support packages. They, too, can be installed easily via one command:

    sudo yum install compat-libstdc++-33.i686 libstdc++.i686 libstdc++-devel.i686  
    

  4. Build an old ldconfig
    Due to a bug in newer versions of the GNU C Library, ldconfig has trouble with ARM architectures. So we need to grab a working copy and recompile ldconfig for the toolchain. (Alternatively, we could downgrade the entire OS.)

    Let's first set up the required root folder then download and extract the software:

    mkdir glibc-build  
    cd glibc-build  
    wget http://ftp.gnu.org/gnu/glibc/glibc-2.15.tar.gz  
    tar -zxvf glibc-2.15.tar.gz  
    

    Now, still in the root folder we created, issue the commands:

    ./glibc-2.15/configure --prefix=/usr
    make  
    

    Compilation will take a few minutes. When it's done, copy the replacement ldconfig into the buildroot toolchain:

    cp ./elf/ldconfig ~/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-ldconfig  
    

  5. Configure Buildroot 2012.02

    Before we can build the toolchain and packages, we need to write out a .config file. First, enter the buildroot folder and issue the command:

    make menuconfig  
    

    In the configurator that appears, select Load an Alternate Configuration File and provide the following configuration file:

    ~/buildroot/microsoft.buildroot_config
    

    (Microsoft has provided a slew of configuration files but none of them perfectly match the retail device configuration. For our purposes, however, it's good enough. You're free to select more packages for compilation.)

    Exit the configurator and save your changes.

    Now let's quickly fix up some missing execute permissions and we'll be ready to go:

    chmod +x ~/buildroot/support/scripts/*  
    chmod +x ~/buildroot/support/gnuconfig/config.guess  
    chmod +x ~/buildroot/support/dependencies/*.sh  
    

  6. Build a base image
    This part is easy. Still in the buildroot folder, simply issue the command:

    make  
    

    And wait.

    My virtual machine was configured with a mere 1GB of RAM and 4 virtual processors clocking in at 3.4ghz. The build completed in about 10 minutes.

    After the build completes, you'll have a nearly complete root filesystem for the adapter stored in the target folder.

  7. Deployment?
    Microsoft hasn't provided the scripts or steps necessary to create an actual image to flash onto the Microsoft Wireless Display Adapter, so the instructions must come to abrupt end here.

    If you have root on the device -- coming in a later post -- you can use the toolchain to compile packages and transfer them over to the device.

    Know how to take this further? Or how to connect to/reflash NAND? Or have experience building jigs? Email me. I'd love to pick your brain.

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
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.

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.