[bug] Fresh Tauri v2 project fails Windows App Certification Kit (WACK) due to Blocked Executables (S Mode Compatibility)

[camilolb]

Describe the bug

Describe the bug
A boilerplate Tauri v2 application (created with npm create tauri-app) fails the Windows App Certification Kit (WACK) during the "Package Sanity Test". This prevents the app from passing the automated and manual review for the Microsoft Store, specifically on systems running Windows 10/11 S Mode.

Steps to reproduce

1. Create a fresh Tauri project: npm create tauri-app.
2. Build the project for Windows (Architecture: x64 or ARM64).
3. Package the output as an MSIX (using MSIX Packaging Tool or cargo-packager).
4. Run the Windows App Certification Kit 10 against the generated MSIX.
5. See the "Package Sanity Test" failure.

Expected behavior
A base Tauri application should not contain blocked executable references that trigger "S Mode" security violations, or at least provide a way to opt-out of these Win32 API calls (like cmd.exe or ShellExecute) to satisfy Microsoft Store requirements.

Evidence from WACK (Screenshot attached)
The test identifies the following blocked references in the main executable:

• kernel32.dll!CreateProcessW
• shell32.dll!ShellExecuteW
• Reference to cmd.exe
• Reference to dNX

Platform Info

• Tauri Version: 2.9.5
• OS: Windows 11 (Targeting 25H2)
• WACK Version: 10.0

Additional context

Update: I ran the Windows App Certification Kit on a clean Tauri v2 project. It failed the "Package Sanity Test" due to blocked executable references:

• kernel32.dll!CreateProcessW
• shell32.dll!ShellExecuteW
• Direct references to cmd.exe and dNX.

These references exist even in a base project, making it impossible to pass the "Windows 10/11 S" compatibility check required by Microsoft Store reviewers. This is blocking the publication of ARM64 apps which are frequently tested on S Mode devices (like Surface Pro).

---

Reproduction

I recived this email from microsoft

appears to be incorrectly configured – the system and hardware requirements you have declared are all met however when trying to launch the product, there is a prompt that the version isn’t correct and the app cannot be launched. This is reproduced on multiple devices, OS 25H2, Windows 11, established internet connection.

The app's limitations or requirements for device input devices needs to be declared and updated in the "Minimum Hardware" or "Recommended Hardware" fields located within the "Properties" section under "System requirements."

If your app requires additional items that aren't listed in the Properties section, such as 3D printers or USB devices, you can also enter additional system requirements under the Store Listings section. You can find additional system requirements under the “Store listings” section for each language.

Expected behavior

No response

Full tauri info output

[✔] Environment
    - OS: Mac OS 15.6.1 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ Xcode: 16.3
    ✔ rustc: 1.92.0 (ded5c06cf 2025-12-08)
    ✔ cargo: 1.92.0 (344c4567c 2025-10-21)
    ✔ rustup: 1.28.2 (e4f3ad6f8 2025-04-28)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 22.17.0
    - yarn: 1.22.22
    - npm: 10.9.2

[-] Packages
    - tauri 🦀: 2.9.5, (outdated, latest: 2.10.2)
    - tauri-build 🦀: 2.5.3, (outdated, latest: 2.5.5)
    - wry 🦀: 0.53.5, (outdated, latest: 0.54.1)
    - tao 🦀: 0.34.5
    - tauri-cli 🦀: 2.10.0
    - @tauri-apps/api  ⱼₛ: 2.9.1 (outdated, latest: 2.10.1)
    - @tauri-apps/cli  ⱼₛ: 2.9.6 (outdated, latest: 2.10.0)

[-] Plugins
    - tauri-plugin-log 🦀: 2.8.0
    - @tauri-apps/plugin-log  ⱼₛ: not installed!
    - tauri-plugin-store 🦀: 2.4.2
    - @tauri-apps/plugin-store  ⱼₛ: 2.4.2

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:5173/
    - framework: React
    - bundler: Vite

Stack trace

Additional context

[camilolb]

Also, create a clean Tauri app from scratch and run the tests, and the result is the same as the image, so the program I created is completely unrelated.

[FabianLars]

oof i think this is impossible to fix. i think this is mostly WebView2 (a Microsoft library btw!) that calls these functions :/