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:

<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.

Chargle now supplies its own entry point instead of using the generated one, so Application.Start runs inside a try. A failure there is logged and then rethrown rather than swallowed：with no window and no message loop there is nothing left to recover to, and quietly exiting would have destroyed the Windows Error Reporting entry too, which was the only usable evidence this time round.

Nothing else changed

No settings move, and nothing needs turning back on. If run-at-login is already switched on, it will simply work at your next sign-in.

Getting it

The Microsoft Store version updates on its own once this build is through review.

winget install 9PP0T5VTMSC2

That is the Store build, through winget's msstore source.

The portable build was never affected by this. It registers run-at-login with a Run key under HKCU and passes --background on the command line, so no part of the package manifest is involved. Both builds are attached below.