WildDragonLLC/teamsiso
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases 1 Packages Wiki Activity Actions

docs(work-log): add root-cause finding for activation blocker
Some checks failed
CI / build-and-test (push) Failing after 27s
Details

Browse source 
MddBootstrapInitialize2 probe identifies HR=0x80670016 =
MDD_E_BOOTSTRAP_INITIALIZE_DDLM_NOT_FOUND. Three suggested fixes
documented inline, with option 2 (switch to WindowsAppSDK 1.8, which
has its DDLM installed) already taken in commit 166e7d6.

After fix #2 the bootstrap succeeds and the .exe launches, but a
secondary XAML parse error (HR=0x802b000a) terminates it within 1s.
Triaging that is the next session's task.
This commit is contained in:
Zac Gaetano 2026-05-13 00:40:02 -04:00
parent 166e7d6e6a
commit 07f4a1b716
1 changed files with 40 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
docs/superpowers/work-log-2026-05-12.md
View file

@ -122,18 +122,47 @@ Teams ISO/
* The UndockedRegFreeWinRT auto-init ModuleInitializer was disabled —
still fails
**Top suspect**: the managed assembly's static dependencies include
`Microsoft.WinUI.dll` which itself has DllImport-style native dependencies
that the .NET host probes during managed-assembly load. Without the
WindowsAppRuntime's COM activation context registered first, those imports
fail and the loader aborts before Main runs.
**ROOT CAUSE IDENTIFIED (post-log-update):**
**Recommended first action when you're up**: open the WinUI project in
Visual Studio if you have it installed; the F5 launch path will show the
actual activation error in a way the command-line launch doesn't. If no
VS, try installing the `Microsoft.WindowsAppRuntime.1.6` redistributable
explicitly (the AppxPackage version installed might not include the
desktop runtime needed for unpackaged apps).
I built a tiny diagnostic console probe
(`src/TeamsISO.App.WinUI.Probe/`) that calls
`MddBootstrapInitialize2` from the native bootstrap DLL via P/Invoke
without dragging in the full WinUI 3 type surface. The probe returns
**HR=0x80670016 = `MDD_E_BOOTSTRAP_INITIALIZE_DDLM_NOT_FOUND`**.
Translation: the framework package (Microsoft.WindowsAppRuntime.1.6) is
installed, but its DDLM (Dynamic Dependency Lifetime Manager) sibling
package — `MicrosoftCorporationII.WinAppRuntime.Main.1.6` — is NOT.
Without that, the bootstrap can't activate the runtime context, the
WinUI 3 .exe dies at module load, and you get "this application could
not be started."
Looking at `Get-AppxPackage`, this machine has Main.1.5 (5001.373) and
Main.1.8 (8000.836) installed, but NO Main.1.6.
**Three fixes, pick one:**
1. **Install the 1.6 DDLM** redistributable. Download
`Microsoft.WindowsAppRuntime.1.6` from
https://aka.ms/windowsappsdk/1.6/latest/windowsappruntimeinstall-x64.exe
and run it. After it installs, `Get-AppxPackage MicrosoftCorporationII.WinAppRuntime.Main.1.6`
should return a row.
2. **Switch the .csproj to WindowsAppSDK 1.8** (the package version
would be `Microsoft.WindowsAppSDK` 1.8.260508005, and the major.minor
in `Program.cs` becomes `0x00010008`). 1.8 IS fully installed on
this machine.
3. **Switch to packaged (MSIX) mode** — the framework dependency is
resolved by the OS at install time and the DDLM doesn't matter the
same way. Means giving up the existing MSI installer path for now.
Option 2 is the fastest. Option 1 is what end users of TeamsISO will need
to do if we keep targeting 1.6 LTS.
To reproduce the diagnosis from scratch:
cd src/TeamsISO.App.WinUI.Probe
dotnet build
dotnet bin/Debug/net8.0-windows/win-x64/TeamsISO.App.WinUI.Probe.dll
## What I did NOT do