[windows] "open with" file association and opds custom scheme callback not working on the win11 pro both exe and appx

[panaC]

What is the state of my computer before the test:

• fresh installation of the latest win11 pro version with MAS activation.
• multiple installation of thorium 3.3.0 both appx (msstore) and github exe installer

What is worked before the test:

• When I first install the github exe installer everything works fine: open with association worked, as well as the opds custom scheme. After several restarts, Thorium's behaviour (first instance opened or closed) remained unchanged, everything was functioning correctly.
• I then installed the appx version from the Microsoft Store, and everything worked correctly again, without me knowing which instance of thorium was currently running on my computer

What is the issue:

• When I remove both version of thorium 3.3.0 (exe, appx)
• Then I install the msstore (appx) version, file association and opds custom scheme association only work on the first opening of the application.
• All subsequent attempts to open the Thorium application fail! I can therefore reproduce the issue.
• Same behaviour when I do the same thing with the exe installer version

So this is not an issue with the appx version neither with the exe installer, but from an installation mix between them, I cannot be 100% sure if the appx worked correctly before my dysfunctional test, because I ran mostly the exe installer first. What I find very strange, is why is it working on the first launch, and stop working then. File association and opds custom scheme both are working on the first start after fresh installation. But why, this is strange ? File association are working as a parameters on the command line arguments of the application. So in this case, maybe the argument position of the filepath is not the same, or not sent. Same thing for the opds custom scheme is it registered on the first start of the application and then triggered with a electron event. So maybe the system does not send the event properly. We need to deep dive in it and better understand how is it working under the hood on win11.

[panaC]

Diagnosis (confirmed)

This is not an application runtime bug and not specific to either the EXE or APPX build.

The failure is caused by mixing EXE (Win32) and APPX (MSIX / Store) installations on the same Windows 11 system, which leaves stale and conflicting registry entries for file associations and custom URI schemes.

---

Observed behavior (100% reproducible)

1. Fresh Windows 11 Pro installation
2. Install Thorium EXE only → file association + OPDS protocol work
3. Install Thorium APPX (MS Store) → still works
4. Uninstall both versions
5. Reinstall only one version (EXE or APPX)

Result:

• File association and OPDS custom scheme work only on first launch
• All subsequent launches:
  • Application opens without file path
  • OPDS protocol callback is never delivered

This happens with both EXE and APPX once the system has seen both.

---

Root cause (confirmed)

Windows 11 does not fully clean protocol and file-association registrations when uninstalling mixed Win32 and MSIX packages that:

• share the same protocol name (e.g. opds://)
• share the same file associations
• share the same Electron App ID / ProgID

After the mix:

• Windows resolves associations to orphaned or invalid handlers
• Payload (file path / protocol URL) is not passed to the application
• Electron never receives process.argv nor open-url events

---

Proof

Manually deleting all registry keys containing thorium immediately restores correct behavior.

➡️ This confirms the issue is Windows association resolution corruption, not application logic.

---

Conclusion

• ❌ Not an Electron bug
• ❌ Not an EXE bug
• ❌ Not an APPX bug
• ✅ Installer coexistence / uninstall-cleanup defect on Windows 11

EXE and APPX builds must not be installed on the same system unless identifiers and cleanup are fully isolated.

---

Recommended actions

• Block coexistence of EXE and APPX installs
• Use distinct App IDs / protocol identifiers per packaging type
• Explicitly clean protocol + file-association registry keys on uninstall
• At minimum: document EXE + MS Store builds as mutually exclusive

I'm closing, the issue is not actionable

[panaC]

Hi,

I’m not a Windows specialist, but in this situation the issue comes from conflicts between the MS Store version and the EXE-installed version of Thorium.

What I did was manually remove all registry keys related to “Thorium” — either where Thorium appears in the key name or in the key value.

Important warning: Editing the Windows Registry can be risky. Deleting the wrong key may break applications or even parts of the system. This should only be done if you understand what you're removing.

The real difficulty here is that both installers (MS Store and EXE) use different installation mechanisms, but Windows still keeps shared traces (file associations, protocol handlers, uninstall info, etc.). When both versions are installed — or were installed at different times — leftover registry entries can cause conflicts.

Because of this, the safest recommendation for users is:

Do not mix installation types

• Use MS Store version → better for casual users, automatic updates, sandboxed environment
• Use EXE installer → better for power users, enterprise deployment, or controlled environments

If someone needs to test both versions for debugging, a safer approach is to:

• Use a virtual machine, or
• Completely uninstall one version and clean remaining registry entries before installing the other.

Developing an uninstaller that handles every edge case in the Windows Registry is complex and risky, because we must fully understand how Windows created each entry before removing it.

[llemeurfr]

See also #3344