DEV Community

Nisse-Sec
Nisse-Sec

Posted on

How MSIX Package Isolation Broke My Windows Anti-Ransomware Tool (And How I Fixed It)

Hey everyone,

I recently got my Windows anti-ransomware tool, WinRansomProtect, approved and published on the Microsoft Store. I assumed the review would be a standard malware scan. But the MSIX packaging model ended up forcing me to completely rework core parts of my architecture.

If you’re shipping desktop apps to the Store (especially security tools that need elevation), these are the 3 biggest roadblocks I hit, and the workarounds I landed on.

1. The In-App Update Deadlock

My tool is 100% offline. Originally, I let users click "Check Update" to fetch the newest .exe directly from my server.

Microsoft rejected this right away. The reasoning makes sense: MSIX packages cannot download and launch arbitrary external binaries for updates. If they could, the whole Store signing model would be pointless.

The fix: I rewrote the flow. When a user clicks "Check Update", it just opens my product webpage where they can download the new release manually.

2. Registry Virtualization Broke My Licensing Backup

My standalone EXE uses two places to store licensing state: a local file + a global HKLM\Software registry key as a backup. If the local file is deleted, it restores from the registry.

With MSIX, any writes to HKLM\Software get redirected into a private, isolated hive. The standalone EXE can't even see it. That broke my dual-backup design.

For the Store release, licensing state now lives only in a local file inside the package. If a user deletes it, there's no secondary backup and the trial resets. It's a real tradeoff: you get Store isolation, but lose that cross-build resilience.

3. The Ghost UI Deadlock

After passing review, I tested it on 1 physical machine + 3 VMs. It worked fine on 3 of them. But on one specific VM, it was totally unresponsive: tray icon showed, but clicking did nothing.

These edge cases are brutal. I captured a memory dump and saw the main thread was stuck. The root cause was a WMI call. I used Win32_ComputerSystemProduct to pull data for my machine-bound license. Inside MSIX on that VM, the WMI query hung indefinitely and blocked the UI thread.

The fix: I removed WMI entirely. Switched to NetworkInterface APIs and P/Invoking kernel32.dll GetVolumeInformation to generate the ID. Solved it instantly.


A few frustrating days of debugging, but it runs flawlessly now. If you're migrating a desktop app to MSIX for the Microsoft Store, hopefully this saves you some hours staring at crash dumps.

If you want to see the final result in action, here are the links:

Top comments (1)

Collapse
 
nissesec profile image
Nisse-Sec •

What's the most frustrating MSIX issue you've ever faced? I'd love to hear how other devs handle the packaging isolation.