Version mismatch not allowing helper to initialize

[MrRobotjs]

Issue: First time installing GoTweaks on my GPD Win 5 and it seemed like it installed fine. I open the gamebar and go to GoTweaks and I’m met with the UAC prompt for the helper and I allow it and after waiting for the initialization it errors says the helper isn’t there. I looked in the helper logs and it seemed to be breaking after the UAC.

Solution: AI. Seriously though lol I didn’t feel like digging into it more so I gave Gemini a go at it and it fixed it for me.

I know developers aren’t fond of AI and if you don’t like this or don’t find it useful then it’s fine but it’s what helped me.

Gemini AI Slop

GoTweaks Version Mismatch & UAC Loop Analysis

This document provides a comprehensive breakdown of the version mismatch bug causing the infinite UAC setup loop in GoTweaks, the code-level fixes, and instructions on how users can resolve it on their existing systems.

---

1. Issue Breakdown & Symptoms

When a user launches the GoTweaks Gaming Bar widget, they are repeatedly prompted for User Account Control (UAC) elevation to perform initial setup.

• The Loop: Even if the user approves the UAC prompt, the next widget launch displays a "Version mismatch" or "Initial Setup in progress" message and requests UAC elevation again.
• The Log Evidence:

  INFO  HelperDeploymentServ Deployment needed: Version mismatch (deployed=, current=0.3.2556.0)
  INFO  ElevationBootstrappe Deployment valid: False, Deployment needed: True, Task configured: True
  INFO  ElevationBootstrappe Setup needed - launching with --setup flag (will trigger UAC)...
  

  The logs show that the non-elevated helper process expects the version 0.3.2556.0 (or whatever the active package version is), but reads either nothing or 1.0.0.0 for the deployed version.

---

2. Root Cause Analysis

The bug is caused by two overlapping issues in HelperDeploymentService.cs:

Cause A: Skipped .version Stamp (The Early Return Bug)

In HelperDeploymentService.DeployHelper(), the method contains an optimization to prevent self-deletion when the deploy source folder is identical to the target folder:

// HelperDeploymentService.cs (lines 285-289)
if (PathsAreSame(sourceDir, HelperFolder))
{
    Logger.Warn($"Deploy source equals deployed folder ({HelperFolder}); skipping self-copy (files already in place).");
    return File.Exists(DeployedExePath);
}

• The Problem: If PathsAreSame is true, the method returns early. In doing so, it skips the code at the end of the method that stamps the .version file:

// HelperDeploymentService.cs (lines 356-364) - SKIPPED on early return!
bool deployOk = failCount == 0 && File.Exists(DeployedExePath);
if (deployOk)
{
    var currentVersion = GetCurrentPackageVersion();
    try
    {
        File.WriteAllText(VersionFilePath, currentVersion);
        Logger.Info($"Version file written: {currentVersion}");

• Result: When UAC setup is launched from the deployed location, the early return occurs, and the .version file is never written. The non-elevated process looks for this file, finds it missing, and believes a new deployment is needed, prompting the user for UAC again.

Cause B: Assembly Version vs. Package Version (Elevation Loss of Package Identity)

In HelperDeploymentService.GetCurrentPackageVersion():

• When running non-elevated (within the MSIX container), global::Windows.ApplicationModel.Package.Current succeeds and returns the actual package version (0.3.2556.0).
• When running elevated (as admin/UAC setup), the process loses package identity. Package.Current throws an exception, and the code falls back to Assembly.GetExecutingAssembly().GetName().Version (which is hardcoded to 1.0.0.0 in AssemblyInfo.cs).
• Result: Even if the setup writes the .version file (e.g., when deploying from another directory like Downloads), it stamps it with 1.0.0.0. The non-elevated widget reads it, compares it with 0.3.2556.0, detects a version mismatch, and triggers the UAC loop.

---

3. Code-Level Solution

To fix this robustly in the codebase:

Step 1: Pass Configuration Parameters via Command Line

Modify LaunchElevatedForSetup in the non-elevated bootstrapper to pass the correct target path and package version:

private static bool LaunchElevatedForSetup(string exePath, string[] args)
{
    try
    {
        var argsList = args.Where(a => a != "--setup" && !a.StartsWith("--helper-folder=") && !a.StartsWith("--package-version=")).ToList();
        argsList.Add("--setup");
        argsList.Add($"--helper-folder=\"{HelperDeploymentService.HelperFolder}\"");
        argsList.Add($"--package-version=\"{HelperDeploymentService.GetCurrentPackageVersion()}\"");
        string arguments = string.Join(" ", argsList);
        ...

Step 2: Parse Configuration Parameters on Startup

In Program.Main, parse these custom arguments before running setup:

static async Task Main(string[] args)
{
    if (args != null)
    {
        string customHelperFolder = args.FirstOrDefault(a => a.StartsWith("--helper-folder="))?.Split(new[] { '=' }, 2).ElementAtOrDefault(1)?.Trim('"');
        string customPackageVersion = args.FirstOrDefault(a => a.StartsWith("--package-version="))?.Split(new[] { '=' }, 2).ElementAtOrDefault(1)?.Trim('"');

        if (!string.IsNullOrEmpty(customHelperFolder))
            HelperDeploymentService.SetCustomHelperFolder(customHelperFolder);
        if (!string.IsNullOrEmpty(customPackageVersion))
            HelperDeploymentService.SetCustomPackageVersion(customPackageVersion);
    }
    ...

Step 3: Make Helper Paths and Version Dynamic

Update HelperDeploymentService.cs to use dynamic properties:

private static string _customHelperFolder = null;
private static string _customPackageVersion = null;

public static void SetCustomHelperFolder(string path) => _customHelperFolder = path;
public static void SetCustomPackageVersion(string version) => _customPackageVersion = version;

public static string HelperFolder => !string.IsNullOrEmpty(_customHelperFolder) 
    ? _customHelperFolder 
    : Path.Combine(GetPackageLocalCachePath(), "GoTweaks", "Helper");

public static string DeployedExePath => Path.Combine(HelperFolder, "XboxGamingBarHelper.exe");
private static string VersionFilePath => Path.Combine(HelperFolder, ".version");

public static string GetCurrentPackageVersion()
{
    if (!string.IsNullOrEmpty(_customPackageVersion))
        return _customPackageVersion;
        
    try
    {
        var package = global::Windows.ApplicationModel.Package.Current;
        var version = package.Id.Version;
        return $"{version.Major}.{version.Minor}.{version.Build}.{version.Revision}";
    }
    catch
    {
        // Try fallback of reading AppxManifest.xml from executing path if not in MSIX container
        ...
    }
}

---

4. How Existing Users Can Fix Their Install (Without Rebuilding)

Existing users can stop the loop by manually writing the expected .version file into their local package cache folder.

Step-by-Step Instructions

1. Locate the Package Local Cache:
   Navigate to the following directory in File Explorer (replace chris with your Windows username):
   C:\Users\<username>\AppData\Local\Packages\PlayandBuildCustom.10365195AA1EC_8edemd50ez3gg\LocalCache\GoTweaks\Helper

2. Create the .version file:

   • Right-click in the directory, select New -> Text Document.
   • Rename the file to .version (ensure you delete the .txt extension at the end).
   • Open the file in Notepad, type your active GoTweaks package version (e.g., 0.3.2556.0), and save it.

3. Kill Stuck Helper Processes:

   • Open Task Manager.
   • Search for XboxGamingBarHelper.exe.
   • Right-click and select End Task to close any running zombie instances.

4. Start the Widget:

   • Launch the GoTweaks widget in the Xbox Gaming Bar (Win + G).
   • The widget will successfully find the .version file, match it to the current package version, and start the helper through the Task Scheduler without showing a UAC prompt.