MSIX startup abruptly aborts Visual Studio 2022

[sigmarsson]

F5 but application fails to startup packaged in MSIX. Is this related and if so what does it mean ?

Version : 1.1.4 App SDK.

:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(166)\Microsoft.WindowsAppRuntime.Bootstrap.dll!7A2885AC: (caller: 08A1B63F) ReturnHr(1) tid(34f0) 80070032 The request is not supported.
    CallContext:[\Initialize] 
The thread 0x364c has exited with code

[DarranRowe]

I encountered this when I was working on a sparse packaged application. It would run normally when the package wasn't installed, but as soon as the package was installed then it failed. But the thing which should be hard to miss is the full set of messages.

D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(129)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFAC26A6DE9: (caller: 00007FF7002EB9AC) LogHr(1) tid(cf4) 80070032 The request is not supported.
    Msg:[MddBootstrapInitialize called in a process with package identity] CallContext:[\Initialize] 
D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(166)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFAC26A6EE7: (caller: 00007FF7002EB9AC) ReturnHr(1) tid(cf4) 80070032 The request is not supported.
    CallContext:[\Initialize] 

The first one is important, basically, MddBootstrapInitialize (or MddBootstrapInitialize2) doesn't work in a packaged application naturally. But if you look at the documentation for MddBootstrapInitialize2, it explains this and it also states that any errors are logged in the system's event log.
But what if you are not calling this yourself I hear you ask. Well, there is the WindowsPackageType project property. If you put this into your project file then the build will compile and link the auto-initializer. If you see a file like MddBootstrapAutoInitializer.cpp in the build output in Visual Studio then you have put this into the project file
If your project is only ever meant to be packaged then never allow MddBootstrapInitialize(2) to be called. Basically, a packaged application should never set WindowsPackageType. This is also true if your application has a separate packaging project (.wapproj). If your application can be run packaged or unpackaged then you have two options. First is to call this function yourself, but check if your application has a package identity first. The other option is to set WindowsAppSDKBootstrapAutoInitializeOptions_OnPackageIdentity_NoOp in the project file.
If this isn't the error you are encountering, look at the debug output and find all appropriate messages. Also open up Event Viewer to find any log entries there.