UWP Store app crashes while including win32 exe as part of package

Question

UWP Store app crashes while including win32 exe as part of package

Raja Shanmugam 60

Hi,

From our existing windows store application(UWP App), we are trying to include passkey support. For that we have created a Win32 exe (passkeybridge.exe) and a PluginAuthenticator.dll(native dll). which implements IPluginAuthenticator(WebAuthNPluginAddAuthenticator)

Based on the following link

Windows-classic-samples/Samples/PasskeyManager at main · microsoft/Windows-classic-samples · GitHub

Registering the passkey manager app as a COM object in the system registry.
Implementing the IPluginAuthenticator interface for managing webauthn credentials.
Using the WebAuthNPluginAddAuthenticator API to add the plugin authenticator. In the UWP app manifest, we have included this.

    <desktop:Extension Category="windows.fullTrustProcess" Executable="PasskeyBridge.exe"/>
        <com:Extension Category="windows.comServer">
          <com:ComServer> 
            <com:ExeServer Executable="PasskeyBridge.exe" Arguments="-Embedding" DisplayName="Passkey Bridge">
              <com:Class Id="a3c6f76g-d9fa-3cb0-1229-218735314d32" DisplayName="PasskeyBridge"/>
            </com:ExeServer>
          </com:ComServer>
        </com:Extension>

We packaged everything into msix package and everything works fine. UWP App -> PasskeyBridge.exe(win32 exe) -> PluginAuthenticator, to create and manage passkeys.

WACK test also passed before store upload.

When installed from store and the app launches, it crashes.

Getting following error in event viewer

The server 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App did not register with DCOM within the required timeout.

Activation for 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App failed. Error code: The app didn't start.. Activation phase: COM ActivateExtension

Application: UWPAPP.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: exception code e06d7363, exception address 00007FFEC1CEA80A

Why store version crashes while the sideloaded packageis working?

Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-07-23T12:46:09.3033333+00:00

Hi @Raja Shanmugam ,

We are currently investigating the issue and will provide an update soon. Thank you for your patience.
Danny Nguyen (WICLOUD CORPORATION) 8,450 Reputation points Microsoft External Staff Moderator

2026-07-24T06:06:01.5133333+00:00
Hi @Raja Shanmugam ,

Thank you for reaching out and providing the details of the issue you are facing with your UWP app and the bundled Win32 executable.

The error you are seeing, specifically the exception code e06d7363 and the DCOM registration timeout, commonly occurs due to missing C++ runtime dependencies when an app is installed from the Microsoft Store compared to being sideloaded.

Exception code e06d7363 is the standard Microsoft C++ exception code. The scenario you described happens because of how package dependencies are resolved for out-of-process executables:

VCLibs Dependency Scope: Even if your UWP Package.appxmanifest has a PackageDependency on Microsoft.VCLibs, that dependency is only resolved for the main UWP AppContainer process. It does not automatically make those Visual C++ runtime DLLs available to an out-of-process Win32 executable (PasskeyBridge.exe) launched via fullTrustProcess or as a comServer.

Sideloading vs. Store Environments: When you sideload the app on a developer or test machine, the Visual C++ Redistributable is usually installed globally, so the Win32 executable finds vcruntime140.dll via the system path. However, when installed from the Store on a clean user machine, those global libraries might be missing. The Win32 executable fails to load its dynamic dependencies and crashes on startup, which manifests as the COM activation timeout and the C++ runtime exception.

I recommend the following solutions:

Statically Link the C++ Runtime (Recommended): Change the build configuration for PasskeyBridge.exe and PluginAuthenticator.dll to statically link the C++ runtime (use the /MT or /MTd compiler flag instead of /MD). This embeds the necessary runtime directly into your binaries, eliminating the external dependency.

App-Local Deployment of CRT DLLs: Alternatively, you can include the required C++ runtime DLLs (e.g., vcruntime140.dll, msvcp140.dll) directly within your MSIX package, placing them in the same directory as PasskeyBridge.exe.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.
Raja Shanmugam 60 Reputation points

2026-07-24T07:18:52.1933333+00:00

Hi Danny,

Thanks for your reply.

We will try to upload store with your Statically Link the C++ Runtime (Recommended) approach.

Also i am attaching you screenshot of WindowsApps installation folder of the app (Sideloaded (working) vs Store (FlightPackage). Both have (Compile with .Net Native tool chain Enabled)

(Sideloaded)

Store Installed ( you could see the Uwp .exe and dll size and all dependencies are seperate eventough Compile with .Net Native tool chain is enabled)

Could this be an issue on why Sideloaded works and Storeinstalled is not working?
Danny Nguyen (WICLOUD CORPORATION) 8,450 Reputation points Microsoft External Staff Moderator

2026-07-24T08:26:04.4433333+00:00

Thank you for the update.

The structural differences between the packages are expected. When you build for the Store using .appxupload, the payload uses MSIL and is compiled in the cloud, resulting in separate managed DLLs. Sideloaded .appxbundle files compile to .NET Native locally, combining everything.

However, this does not cause the crash. The e06d7363 exception is a C++ crash strictly within your Win32 process (PasskeyBridge.exe).

Because Store installations do not automatically provide the C++ runtime (VCLibs) to out-of-process Win32 components, the application fails to start unless those libraries are bundled or statically linked. Please proceed with the answer approach to see if it helps or anything comes up.
Raja Shanmugam 60 Reputation points

2026-07-24T13:05:40.5733333+00:00

Getting the same error with this Statically Link the C++ Runtime (Recommended) approach. we have used /MT option

Also currently we are adding the PasskeyBridge.exe and PluginAuthenticator.dll to the UWP App and creating .msixupload for store. Or do we need to use windows application packaging project? does this matter?

Application: UWPApp.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: exception code e06d7363, exception address 00007FFEC1CEA80A

The server 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App did not register with DCOM within the required timeout.

Activation for 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App failed. Error code: The app didn't start.. Activation phase: COM ActivateExtension Dependencies info:
PasskeyBridge.exe — ole32.lib;oleaut32.lib;shell32.lib;WindowsApp.lib;webauthn.lib;ncrypt.lib;bcrypt.lib;rpcrt4.lib
PasskeyAuthenticator.dll — ncrypt.lib;bcrypt.lib;crypt32.lib;ole32.lib;oleaut32.lib
Raja Shanmugam 60 Reputation points

2026-07-27T07:11:46.4433333+00:00

If we bundle the PasskeyBridge.exe to the existing uwp project and create .msixupload, it was working locally but after store installation, app crashes.

The issue is resolved after using "windows application packaging project" to create .msixupload, then it works.

Answer accepted by question author

0 additional answers

Your answer

Jack Dang (WICLOUD CORPORATION) 18,975 Reputation points Microsoft External Staff Moderator

2026-07-23T12:46:09.3033333+00:00

Hi @Raja Shanmugam ,

We are currently investigating the issue and will provide an update soon. Thank you for your patience.
Raja Shanmugam 60 Reputation points

2026-07-24T07:18:52.1933333+00:00

Hi Danny,

Thanks for your reply.

We will try to upload store with your Statically Link the C++ Runtime (Recommended) approach.

Also i am attaching you screenshot of WindowsApps installation folder of the app (Sideloaded (working) vs Store (FlightPackage). Both have (Compile with .Net Native tool chain Enabled)

(Sideloaded)

Store Installed ( you could see the Uwp .exe and dll size and all dependencies are seperate eventough Compile with .Net Native tool chain is enabled)

Could this be an issue on why Sideloaded works and Storeinstalled is not working?
Danny Nguyen (WICLOUD CORPORATION) 8,450 Reputation points Microsoft External Staff Moderator

2026-07-24T08:26:04.4433333+00:00

Thank you for the update.

The structural differences between the packages are expected. When you build for the Store using .appxupload, the payload uses MSIL and is compiled in the cloud, resulting in separate managed DLLs. Sideloaded .appxbundle files compile to .NET Native locally, combining everything.

However, this does not cause the crash. The e06d7363 exception is a C++ crash strictly within your Win32 process (PasskeyBridge.exe).

Because Store installations do not automatically provide the C++ runtime (VCLibs) to out-of-process Win32 components, the application fails to start unless those libraries are bundled or statically linked. Please proceed with the answer approach to see if it helps or anything comes up.
Raja Shanmugam 60 Reputation points

2026-07-24T13:05:40.5733333+00:00

Getting the same error with this Statically Link the C++ Runtime (Recommended) approach. we have used /MT option

Also currently we are adding the PasskeyBridge.exe and PluginAuthenticator.dll to the UWP App and creating .msixupload for store. Or do we need to use windows application packaging project? does this matter?

Application: UWPApp.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: exception code e06d7363, exception address 00007FFEC1CEA80A

The server 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App did not register with DCOM within the required timeout.

Activation for 03AC1CFB.UWPAPP_2.0.0.0_x64__ghj8hg3x9mj8j!App failed. Error code: The app didn't start.. Activation phase: COM ActivateExtension Dependencies info:
PasskeyBridge.exe — ole32.lib;oleaut32.lib;shell32.lib;WindowsApp.lib;webauthn.lib;ncrypt.lib;bcrypt.lib;rpcrt4.lib
PasskeyAuthenticator.dll — ncrypt.lib;bcrypt.lib;crypt32.lib;ole32.lib;oleaut32.lib
Raja Shanmugam 60 Reputation points

2026-07-27T07:11:46.4433333+00:00

If we bundle the PasskeyBridge.exe to the existing uwp project and create .msixupload, it was working locally but after store installation, app crashes.

The issue is resolved after using "windows application packaging project" to create .msixupload, then it works.

Answer 1

Hi @Raja Shanmugam ,

Thank you for the update and for sharing your solution that using the Windows Application Packaging (WAP) Project works for this scenario.

While adding a Win32 executable directly to a traditional UWP .appxmanifest often works locally (sideloaded), Store deployment imposes stricter boundaries. A classic UWP project structure doesn't always guarantee that out-of-process Win32 dependencies, COM server identities, and runtime trust contexts are perfectly carried over through the Store's compilation and ingestion process.

The Windows Application Packaging Project could in theory bridge this. While I cannot be certain of the exact internal failure without a dump, it is likely that migrating to WAP resolved the issue because it correctly wires up the activation pathways between different project types (managed UWP vs native Win32). When you manually add a Win32 executable to a classic UWP project, the Store submission compilation (which separates architecture-specific payloads and strips framework dependencies) often strips or misaligns the native library pathways or deployment layout. A WAP project acts as a unified orchestrator, ensuring that when the .msixupload is built for the Store, the native C++ dependencies, COM execution aliases, and Trust/Capabilities are preserved properly alongside the managed UI.

I am glad to hear the issue is resolved. If you found my responses helpful or informative during your troubleshooting process, I would greatly appreciate it if you could provide feedback by interacting with the system or leaving a comment below.

Thank you.