WSAPatch — Binary Patcher for WSABuilds on Windows 11 26H1

Table of Contents

• The Problem
• Debugging Session
• Full crash call chain
• Why E_ACCESSDENIED on 26H1
• The Two Patches
• Anchor-based scan
• Usage
• Project layout
• Technical highlights
• Building from source
• Requirements

The Problem

WSA (WSABuilds / MustardChef 2407.40000.4.0) crashes within a few seconds to ~40 seconds on Windows 11 26H1 (build 10.0.28000+). The subsystem loads, apps launch — then WsaClient.exe silently dies.

Everything starts fine. WSA loads, Android apps launch. Then WsaClient.exe calls AppUriHandlerRegistrationManager.UpdateAsync() to register URI scheme handlers (deep links) — the API returns E_ACCESSDENIED, the WinRT exception propagates uncaught, and combase!RoFailFastWithErrorContext terminates the process.

Debugging Session

Step 1 — Capturing the crash dump

WER (Windows Error Reporting) was set to capture a full dump on WsaClient.exe crash. Initial triage with CDB:

.ecxr
k 50
!analyze -v

Output:

Faulting module:  combase!RoFailFastWithErrorContextInternal2
Stowed exception: ResultCode = 0x80070005 (E_ACCESSDENIED)
                  ExceptionAddress = WsaClient+0x82AEB

STATUS_STOWED_EXCEPTION is a WinRT mechanism: when a WinRT exception crosses the ABI boundary without being caught, the runtime stores it ("stows" it) and later calls RoFailFastWithErrorContext. The stored HRESULT here was E_ACCESSDENIED.

Step 2 — Identifying the WinRT interface

The stowed exception address led to a vtable pointer. Inspecting the interface GUID:

da WsaClient+0x35f788
dq WsaClient+0x316d58 L1
ln poi(WsaClient+0x316d58)
dq WsaClient+0x4ad278 L1
ln poi(WsaClient+0x4ad278)

Result:

Step 3 — Finding the two crash points

Two independent code paths both lead to the fatal handler:

Point A — HRESULT dispatcher at WsaClient+0xC93D

A 13-entry dispatch table maps known error codes to handlers. One entry checks for E_ACCESSDENIED:

; WsaClient+0xC93D
cmp  ebx, 80070005h    ; E_ACCESSDENIED
jne  +0x19             ; 75 19 — skip to next entry
; falls through to fatal handler if matched

Point B — directly after IAsyncOperation::GetResults() at WsaClient+0x81EE5

; WsaClient+0x81EE5
call qword ptr [rdi+40h]   ; GetResults() → eax = 0x80070005
test eax, eax              ; SF=1 (HRESULT failure bit)
js   +0x26                 ; 78 26 — jump to error path
; should fall through to normal epilogue

Full crash call chain

Why E_ACCESSDENIED on 26H1

AppUriHandlerRegistrationManager.UpdateAsync() registers URI scheme handlers (deep links) for MSIX/UWP/Android apps at runtime. WSA calls it at startup so Windows knows which Android app should handle a given URI scheme.

At some point Microsoft tightened the capability requirements for this API — it now requires restrictedAppUriHandlerHost or equivalent package trust level. WSA's AppxManifest.xml declares windows.appUriHandler and runFullTrust, but that is no longer sufficient on 26H1.

The Two Patches

Both patches are located by anchor-based scanning — pre-bytes and post-bytes bracket the site — making the patcher robust against minor linker layout differences.

Patch 1 — Bypass E_ACCESSDENIED in HRESULT dispatcher

Turns a conditional branch into an unconditional one: the dispatcher always skips to the non-fatal path, so E_ACCESSDENIED is never routed to the fatal handler.

Patch 2 — Ignore HRESULT from GetResults()

Removes the signed-jump that redirected to the error path. Execution falls through to the normal function epilogue, stack canary check and ret — no exception thrown, no crash.

Anchor-based scan

Each patch site is described by a PATCH_DESC struct (48 bytes):

ScanPatch (implemented in scan.asm) walks the file image byte-by-byte:

The result is one of three states: ST_NEEDS_PATCH, ST_ALREADY_PATCHED, or ST_NOT_FOUND. If any patch returns ST_NOT_FOUND, the file is not written — unsupported version, no damage.

Usage

Run from an elevated command prompt (Administrator):

WSAPatch.exe [path\to\WsaClient.exe]

Without a path argument, WSAPatch discovers WsaClient.exe automatically via the registry:

HKLM\SYSTEM\CurrentControlSet\Services\WsaService\ImagePath

FindWsaPath (reg.asm) reads the ImagePath value, strips WsaService.exe and the WsaService\ directory component, then appends \WsaClient\WsaClient.exe. Supports both REG_SZ and REG_EXPAND_SZ (calls ExpandEnvironmentStringsA).

A .bak backup is created before any write. Running on an already-patched file prints Already patched and exits cleanly (idempotent).

Example output — fresh patch:

WsaClient.exe patcher for Windows 11 26H1
==========================================
[*] No path given - searching via WsaService registry...
[*] Target: C:\wsa\WsaClient\WsaClient.exe
[*] Path found via registry

[*] Read 0x4DFC00 bytes

Patch 1: Bypass E_ACCESSDENIED check (JNE->JMP)
  [+] Found at 0xC93D, patching 0xC943: 75  -> EB

Patch 2: Ignore HRESULT from GetResults() (JS->NOP NOP)
  [+] Found at 0x81EE5, patching 0x81EE7: 78 26  -> 90 90

[*] Backup saved to *.bak
[*] Done. 2 patches applied.

Project layout

WSAPatch/
├── x64/
│   ├── consts.inc   Win32 constants, PATCH_DESC struct definition
│   ├── globals.inc  Exported data variable declarations
│   ├── io.asm       OutStr / OutHex / OutByte (WriteFile, no CRT)
│   ├── scan.asm     ScanPatch — anchor-based binary scan
│   ├── reg.asm      FindWsaPath — registry path discovery
│   └── patch.asm    Entry point, patch table, orchestration
└── build.ps1        ML64 + LINK64, /NODEFAULTLIB, UAC manifest

Technical highlights

Building from source

Requires Visual Studio 2026 / Build Tools v18 (MASM x64 + LINK):

.\build.ps1

Output: bin\WSAPatch.exe — verified no CRT imports by the build script (dumpbin /imports).

The build script calls ML64.exe for each .asm file, then LINK64.exe with /NODEFAULTLIB and an embedded UAC manifest (/MANIFESTUAC:level='requireAdministrator').

Requirements

WSAPatch — Pure MASM x64, zero external dependencies.
kvc.pl | [email protected] | GitHub