Store Pitfalls #1: My App's Dependency Installed a Ghost Start Menu Entry
2026-05-28
Tags: Windows · MSIX · Microsoft Store · Store Pitfalls
Publishing Windows apps to the Microsoft Store isn't always smooth sailing. This series documents the real pitfalls I've encountered — one per post, short and practical.
Here's the first one.
Background
RDP Heartbeat started out as a Python + Tkinter tool — a tiny breathing dot that tells you whether your RDP session is still alive. It worked, but packaging a Python desktop app for the Microsoft Store was a saga: Python source → PyInstaller exe → Inno Setup installer → MSIX package. We wrote about the whole journey.
So I rewrote it from scratch in native WinUI 3 using Windows App SDK 2.0.1. The native path was supposed to be smooth sailing — no more Python packaging gymnastics. And it was, right up until Store certification.
"Pass with Required Fix"
The certification result came back:
Status: Pass with required fix
10.1.1.11 On Device Tiles: Your submission installs multiple components to the device. Please make sure the additional installed components that are visible in the Start Menu have a unique name that clearly identifies which item is the main product.
Passed — but with a warning. Something extra had shown up in the Start Menu, and it wasn't my app.
The Ghost Entry
The certification report said something extra appeared in the Start Menu. So I looked — and honestly, nothing out of the ordinary. My Start Menu looked exactly as expected, with no extra tiles.
I went through the entire project: checked the package manifest, looked at the build output, compared it against my other Store apps. No extra packages, no suspicious extensions, nothing stood out.
But there was one difference. My other apps — EnvStudio, GhostWin, QuickGUID — all use Windows App SDK 1.8.x. RDP Heartbeat is the only one on SDK 2.0.1. That's the sole variable that changed.
WinUI 3 apps depend on the Windows App SDK runtime, which is distributed as MSIX packages installed as shared system dependencies. The only suspect I can point to is the SDK 2.x runtime — somehow, on Microsoft's test environment (but not on my machine), its deployment produces a visible Start Menu tile. Why exactly, I don't know.
What Can You Do About It?
Here's the frustrating part: you can't directly fix it. The runtime packages are authored by Microsoft — you have no control over how they appear in the Start Menu.
Your practical options:
- Accept it and document it — Add a note in your Store submission explaining that the extra tile is a Microsoft-provided runtime dependency, not a separate product. This is what I did, and certification passed.
- Switch to self-contained deployment — Bundle the runtime directly into your app package by setting
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>in your.csproj. This eliminates the DEPN entirely, but adds ~40 MB per architecture to your download size.
The Takeaway
If you're building with Windows App SDK 2.x for the Microsoft Store:
- Be aware that the runtime dependency may create a visible Start Menu tile
- It's a side effect of the 2.x runtime, not a bug in your app
- Document it in your submission notes to avoid certification delays
- If the ghost entry is unacceptable, self-contained deployment is the cleanest workaround
Part of the Store Pitfalls series.