Launcher feedback: startup visibility + uninstaller cleanup (trust issue)

[clever musk]

Hey team — I want to flag something that can look really sketchy from a user-trust perspective, even if it’s unintended.

What a user experienced

A friend tried Somnium about a month ago and noticed Somnium-related components still running / still present after uninstalling. Her immediate reaction was basically: “Why is something still in the background after uninstall — is this a crypto miner or something?”

To be clear: I’m not claiming that’s what’s happening. But given how many people have been burned by crypto scams/malware in recent years, this exact pattern (background activity + incomplete uninstall) instantly triggers distrust and will cause people to warn others.

What I can confirm on my machine (Windows)

• The launcher starting with Windows is fine.

• The issue is how it starts:

  • On Windows, most tech-savvy users check Task Manager → Startup apps first.
  • Somnium doesn’t appear there (screenshot attached), which makes it look “hidden”.
  • Instead, it seems to use Task Scheduler, which most users associate with legacy/enterprise tooling and, unfortunately, persistence techniques used by unwanted software.

Requested improvements (high impact for trust)

1. Use Windows Startup Apps integration on modern Windows

   • If the launcher is set to start with Windows, it should show up in Task Manager → Startup apps (and Windows Settings → Apps → Startup).
   • If Task Scheduler is needed for older OS versions, consider a simple OS/version check and use the modern method where available.

2. Fix uninstaller cleanup

   • On uninstall, it should remove:

     • scheduled tasks created by the launcher
     • any startup entries
     • leftover background processes/services (if any)
     • any supporting runtime components it bundled/installed (without breaking system runtimes)

3. Add a transparency note

   • A short release note / KB entry like “What runs in the background and why” + “How to fully remove Somnium components” would immediately reduce fear and speculation.

Why I’m pushing this

Even if everything is benign, perception matters. If users feel anything persists “invisibly,” they’ll assume the worst and it spreads fast. Making startup behavior visible and uninstall clean will restore a lot of confidence quickly.

Happy to provide more details (Windows version, where the scheduled task is located, etc.) if needed.

[radiant vector]

There is a known issue with the uninstall process that has been resolved on the next update.

You can manually "fix" it by following these instructions: #🙋┃support message

And the reasons for running in background is:

• We have a built-in chat (launcher is needed while in game too, as it is all run through this)
• Any updates will automatically install (if needed)
• Reduces initial "get into Somnium" time by a lot.

We are not mining crpyto, not sure why people think this, as that would be extremely illegal.

[clever musk]

Ah that's great!! 👍

---

I understand the reasons and they are valid.

I am not saying, that Somnium launcher should not be in Autostart.

But the System it uses is being used by a lot of untrustworthy software.

I get wanting to support old OS versions, that don't use the new Autostart system and you can still keep doing that, but by giving the User the choice to see and control that stuff in the Task Manager, you will make using Somnium a lot more ergonomic and people will appreciate you for this.

On another note, a lot of software uses a lightweight updater daemon (Java, Teams, Others) so that could be an option as well( also put that in Task Manager Startup xD)

I think this could be an EZ fix that would make it a lot easier to calm people down that are overly afraid of using anything that uses blockchain technologies.

Just an idea

[clever musk]

Because a lot of people are taumatized by bad experiences. it's a almost like collective PTSD

[radiant vector]

We can look at being included into the "start up" in windows, I'll ping @meager ravine to see if we can.

For now, you can simply disable it here:

The only parts of blockchain we use, is the proof of creation, for avatars, items and parcels in the base reality - As it cant be deleted, removed, stolen etc.

and that you can use CUBE to buy and sell, but we are looking at integrating STRIPE fully (same way the Tip Jar works)

Let me reiterate, there is no "mining" happening in the launcher, it just simply has features, similar to Steam, like chat, world browsing, events, real time map etc etc and they do take up tiny amounts of resources.

[clever musk]

Yes I know you guys ain't doing that <3

And I love that you are using the blockchain technology for what it is actually intended for. Big Ups to that!

Idk if this could be helpful, but I vibe coded a little example function real quick xD

C# (.NET) — decide autostart method by OS/build

using System;

public enum AutostartMethod
{
    RegistryRunKey,  // Visible in Task Manager -> Startup apps
    TaskScheduler    // Legacy fallback
}

public static class AutostartSelector
{
    // Windows 10 RTM is build 10240
    private const int Windows10BuildMin = 10240;

    public static AutostartMethod ChooseAutostartMethod()
    {
        if (!OperatingSystem.IsWindows())
            throw new PlatformNotSupportedException("Autostart selector is Windows-only.");

        // Works on .NET 5+ and is accurate on Windows 10/11
        Version v = Environment.OSVersion.Version; // major.minor.build.revision
        int build = v.Build;

        // Windows 10/11: show in Task Manager Startup apps via HKCU\...\Run
        if (build >= Windows10BuildMin)
            return AutostartMethod.RegistryRunKey;

        // Older Windows: fallback
        return AutostartMethod.TaskScheduler;
    }

    public static string DescribeOs()
    {
        var v = Environment.OSVersion.Version;
        return $"Windows version: {v.Major}.{v.Minor}.{v.Build}.{v.Revision}";
    }
}

If you want it even more explicit, you can also special-case Windows 11 by build (22000+) — but treating 10/11 the same is usually fine.

---

C++ — decide autostart method by OS/build (WinAPI)

#include <windows.h>
#include <string>

enum class AutostartMethod
{
    RegistryRunKey,
    TaskScheduler
};

// Helper to get Windows build number reliably.
// (Requires application manifest to avoid compatibility shims for some APIs.)
static DWORD GetWindowsBuildNumber()
{
    OSVERSIONINFOEXW osvi = {};
    osvi.dwOSVersionInfoSize = sizeof(osvi);

    // NOTE: GetVersionEx is deprecated and can lie without proper manifest.
    // For production, prefer Version Helper APIs or RtlGetVersion.
    // Here’s a minimal approach using RtlGetVersion (undocumented but common).
    using RtlGetVersionPtr = LONG (WINAPI*)(PRTL_OSVERSIONINFOW);

    HMODULE hMod = ::GetModuleHandleW(L"ntdll.dll");
    if (hMod)
    {
        auto rtlGetVersion = (RtlGetVersionPtr)::GetProcAddress(hMod, "RtlGetVersion");
        if (rtlGetVersion)
        {
            RTL_OSVERSIONINFOW rovi = {};
            rovi.dwOSVersionInfoSize = sizeof(rovi);
            if (rtlGetVersion(&rovi) == 0)
                return rovi.dwBuildNumber;
        }
    }

    return 0; // unknown
}

AutostartMethod ChooseAutostartMethod()
{
    const DWORD build = GetWindowsBuildNumber();

    // Windows 10 RTM = 10240
    if (build >= 10240)
        return AutostartMethod::RegistryRunKey;

    return AutostartMethod::TaskScheduler;
}

---

(Optional) What “RegistryRunKey” usually means (C# snippet)

If you want the “modern visible” method implementation too:

using Microsoft.Win32;

public static class AutostartRegistry
{
    private const string RunKeyPath = @"Software\Microsoft\Windows\CurrentVersion\Run";

    public static void SetEnabled(string appName, string commandLine, bool enabled)
    {
        using var key = Registry.CurrentUser.OpenSubKey(RunKeyPath, writable: true)
                     ?? Registry.CurrentUser.CreateSubKey(RunKeyPath);

        if (enabled)
            key.SetValue(appName, commandLine);
        else
            key.DeleteValue(appName, throwOnMissingValue: false);
    }

    public static bool IsEnabled(string appName)
    {
        using var key = Registry.CurrentUser.OpenSubKey(RunKeyPath, writable: false);
        return key?.GetValue(appName) != null;
    }
}

[meager ravine]

Yep, it’s doable and I’ll try to include this in our next update

Thanks for the feedback btw, about uninstalling part it’s already a known issue and we are working on it

[clever musk]

sick!

[sonic turret]

Using the scheduled task to start the launcher is most probably because it is currently ran elevated. Once it doesn't need to run elevated, it can be started through the Run in registry

There should be no code necessary to check for the windows version or build. That is usually always causing issues in future windows releases or the windows version is misinterpreted. If you need specific features, query for the feature instead of relying on the windows version number

[clever musk]

I'm pretty sure having a switch case or if/else that checks for certain identifiers or windows builds can be achieved without breaking something and without being too much of a maintenance overhead regarding future releases.

The reason the launcher is running elevated right now is, because of the updater, I assume.
A possible solution for that was already provided so yea. It's certainly not impossible

[clever musk]

I haven't actually dug into the APIs windows provides, but usually if you have sane defaults , you don't break anything.

Instead of checking for OS version, another approach might be testing if the APIs and functions needed for the new Run in Registry feature exist.

This is very sovable and can be done in a way that doesn't break functionality even for future windows releases