Learn

Bootstrapper And Runtime Internals

The bootstrapper exists because unpackaged and external-location apps do not naturally get the Windows App SDK framework package in their package graph.

Framework-Dependent Startup

Process starts
  -> bootstrapper locates compatible Windows App Runtime
  -> framework package enters package graph
  -> DDLM keeps runtime package from being serviced while in use
  -> app can call Windows App SDK APIs

Bootstrapper API

HRESULT hr = MddBootstrapInitialize(
    WINDOWSAPPSDK_RELEASE_MAJORMINOR,
    WINDOWSAPPSDK_RELEASE_VERSION_TAG_W,
    WINDOWSAPPSDK_RUNTIME_VERSION_UINT64);

if (FAILED(hr))
{
    // Log and show a clear runtime installation error.
}

Use MddBootstrapInitialize2 when the current docs recommend its improved diagnostics for your scenario.

DeploymentManager

Packaged apps can use DeploymentManager.GetStatus and DeploymentManager.Initialize where they need runtime package deployment checks. Do not use deployment APIs as a substitute for understanding the app’s packaging model.

Diagnostics

When runtime startup fails, check:

  • Correct architecture runtime installed.
  • Runtime version matches app expectations.
  • VC++ and .NET prerequisites.
  • Event Viewer and app logs.
  • Whether bootstrap ran before Windows App SDK APIs.
  • Whether app is packaged, external-location, or unpackaged.