`windows-reactor` `as_self_contained()` + `bootstrap()` fails with STATUS_DLL_NOT_FOUND (missing `MddBootstrapInitialize2`)

[Matuco19]

Summary

A minimal windows-reactor application created from scratch fails to start when using windows_reactor_setup::as_self_contained() in build.rs and bootstrap()? in main(). The executable builds successfully, but immediately exits with:

error: process didn't exit successfully: `target\debug\wahnote.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)

Opening the executable with Dependencies shows that the missing import is MddBootstrapInitialize2 from Microsoft.WindowsAppRuntime.Bootstrap.dll, and interestingly, there are two configurations that work:

// build.rs
fn main() {
    windows_reactor_setup::as_framework_dependent();
}

with

// main.rs
fn main() -> Result<()> {
    bootstrap()?;
    App::new().title("example").render(app)
}

// build.rs
fn main() {
    windows_reactor_setup::as_self_contained();
}

with

// main.rs
fn main() -> Result<()> {
    App::new().title("example").render(app)
}

The only configuration that fails is:

// build.rs
fn main() {
    windows_reactor_setup::as_self_contained();
}

combined with

// main.rs
fn main() -> Result<()> {
    bootstrap()?;
    App::new().title("example").render(app)
}

This makes me think there is either: a packaging issue in as_self_contained(), or bootstrap() should not be used for self-contained deployments and the documentation should mention this (but since it hasn't been published to crates.io (as mentioned here yet, it seems like something undone).

I think that as_self_contained() should produce a working executable when used together with bootstrap(), or bootstrap() should not be required (or should become a no-op) for self-contained deployments, and this should be documented.

It is also worth noting that the windows-reactor Getting Started example itself in documentation can reproduce this error, as as_self_contained() + bootstrap()?; is being used.

Environment

• OS: Windows 11 Pro Insider Preview
• Build: 10.0.26200
• Rust: stable (rustc 1.97.0 (2d8144b78 2026-07-07))
• windows-reactor: git (current main, commit 07f344c019b8fdae4d398d4c2591596044cb416a)
• windows-reactor-setup: git (current main, commit 07f344c019b8fdae4d398d4c2591596044cb416a)

An additional info is that my machine has multiple versions of the Windows App Runtime installed (including 2.x), but i don't see why this would be the problem, the issue appears to be specific to the combination of self-contained deployment + explicit bootstrap.

Crate manifest

[package]
name = "wahnote"
version = "0.1.0"
edition = "2024"

[dependencies]
windows-reactor = { git = "https://github.com/microsoft/windows-rs" }

[build-dependencies]
windows-reactor-setup = { git = "https://github.com/microsoft/windows-rs" }

Crate code

main.rs:

use windows_reactor::*;

fn main() -> Result<()> {
    bootstrap()?;
    App::new().title("WahNotepad").render(app)
}

fn app(_cx: &mut RenderCx) -> Element {

    vstack((
        text_box("")
            .height(500.0)
            .header("New Note")
            .width(400.0),

    ))
    .into()
}

build.rs:

fn main() {
    windows_reactor_setup::as_self_contained();
}

[riverar]

Sorry for the confusion, the bootstrap is only needed when your app is framework dependent. We'll do another review pass on the docs, looks like some of that nuance got lost in recent updates.

[riverar]

Here's another set of docs that may be more helpful: #4487

[Matuco19]

Thanks for the clarification, that explains this behavior, also one more thing worth considering while you're in there, is that since Microsoft.WindowsAppRuntime.Bootstrap.dll simply isn't staged for a self-contained build, calling bootstrap() currently fails at the OS loader level (STATUS_DLL_NOT_FOUND) rather than through a Rust-level error. Since this seems like an easy mistake to make (especially when copying the getting-started example or other reason), it might be worth having as_self_contained() record the chosen deployment model (env var / build-time flag) so bootstrap() can detect the mismatch and return a descriptive Result::Err instead of crashing at the loader level, no?

(Also, sorry if i said anything nonsense, i'm quite sleepy right now lol)

[riverar]

I agree it's a sharp edge right now. We're exploring a few ideas to simplify the build workflow/bootstrapping process.