Chargle 1.1.1

What's new in 1.1.1

Chargle no longer dies every time you sign in.

Run at login worked everywhere except at login

If you turned on Start Chargle when I sign in, the Store build never survived the sign-in that followed. A splash screen sat on screen for around two minutes, then vanished, and there was no tray icon and no Chargle. Opening it from the Start menu straight afterwards worked perfectly, which made it look like the app disliked being started early rather than being started at all.

The manifest is where it went wrong. The startup task declared its entry point as $targetentrypoint$, the same token the main application entry uses. The MSIX tooling substitutes that token on the Application element and nowhere else, so what shipped inside the package was the literal string, dollar signs and all:

xml
<Application Id="App" Executable="Chargle.exe" EntryPoint="Windows.FullTrustApplication">
<uap5:Extension Category="windows.startupTask" Executable="Chargle.exe"
EntryPoint="$targetentrypoint$">

Launching from the Start menu goes through the first line and gets full-trust Win32 activation. Signing in goes through the second, and Windows took the unrecognised entry point to mean this was an ordinary packaged app, not a Win32 one. So it did what it does for those：put the splash screen up and waited for a CoreWindow to appear. Chargle is a Win32 app and never creates one.

Meanwhile Microsoft.UI.Xaml.Application.Start failed immediately with REGDB_E_CLASSNOTREG, because the XAML runtime cannot start under that kind of activation. The process was gone in under half a second. The two minutes were the shell waiting for a window from a process that had already exited, and the splash screen was the clearest evidence available all along — a full-trust launch never shows one.

The startup task now names Windows.FullTrustApplication outright, with a comment next to it explaining why it cannot be the token.

The crash log was empty the whole time

Chargle writes unhandled exceptions to crash.log precisely so that a tray app dying quietly leaves something behind. It had nothing to say about any of this.

The handlers that write that file are installed in OnLaunched, and OnLaunched never ran — the failure happened in Application.Start, one frame further out, before there was an application to hand it to. The only record was an entry in Event Viewer.
…

Full release notes »