MeshBay -- cleaning a Windows machine that has already been used for testing ========================================================================== Goal: bring the machine back to "never had MeshBay", so the next install is a genuine first install. Work through the sections in order. Commands are PowerShell (Windows PowerShell 5.1 is fine). [ADMIN] marks a step that needs an elevated PowerShell ("Run as administrator"); everything else runs as the normal user. Run the [ADMIN] steps as the SAME Windows account that used MeshBay (elevate that account, do not log in as another admin), because the paths below are per-user. Nothing here touches a hub. Section 9 covers what is left on the hub side. 0. Before deleting anything: keep what you may want back --------------------------------------------------------- %LOCALAPPDATA%\meshbay holds the node's identity (keystore.enc + unlock.key) and its data. Deleting it means that node, and the groups it hosted, are gone for good. If in doubt, move it instead of deleting it: $bak = "$env:USERPROFILE\meshbay-backup-$(Get-Date -Format yyyyMMdd-HHmm)" New-Item -ItemType Directory $bak | Out-Null Move-Item "$env:LOCALAPPDATA\meshbay" "$bak\Local-meshbay" -ErrorAction SilentlyContinue Move-Item "$env:APPDATA\meshbay-client" "$bak\Roaming-meshbay-client" -ErrorAction SilentlyContinue (Do this after section 1, once nothing holds those files open.) 1. Running processes -- every session, including session 0 ----------------------------------------------------------- What can be running: - MeshBay.exe the desktop app (several processes: main, GPU, renderers, utility -- all named MeshBay.exe). It may be hidden in the tray: right-click the tray icon > Quit. - meshbay-node.exe the node. In service mode it runs in SESSION 0 (the boot task's S4U logon), invisible on the desktop and out of reach of a non-elevated taskkill. A CLI command (meshbay-node status, ...) is also meshbay-node.exe for as long as it runs. - ffmpeg.exe / ffprobe.exe children of the node (transcodes, probes). - wscript.exe only for a moment, at sign-in, if the Startup launcher exists. - a python.exe running meshbay_node only on a developer machine (venv). See them, with their session: Get-Process MeshBay, meshbay-node, ffmpeg, ffprobe -ErrorAction SilentlyContinue | Select-Object Name, Id, SessionId, StartTime, Path Stop the node properly first (graceful, any session, no elevation): & "$env:LOCALAPPDATA\Programs\MeshBay\resources\node-runtime\meshbay-node.exe" autostart stop (or: meshbay-node autostart stop, if it is on PATH) Then quit the app (tray > Quit), and force whatever is left: Stop-Process -Name MeshBay -Force -ErrorAction SilentlyContinue [ADMIN] (reaches session 0): Get-Process meshbay-node, ffmpeg, ffprobe -ErrorAction SilentlyContinue | Stop-Process -Force Check that nothing is left: Get-Process MeshBay, meshbay-node -ErrorAction SilentlyContinue # must print nothing Get-NetTCPConnection -LocalPort 18000 -State Listen -ErrorAction SilentlyContinue # node control API, must be empty 2. The boot task (service mode) [ADMIN] -------------------------------------------------------------------------------- schtasks /query /tn "MeshBay Node" /fo list /v # see what it runs, and as whom schtasks /end /tn "MeshBay Node" schtasks /delete /tn "MeshBay Node" /f Look for anything else named after MeshBay (an older test may have used another name): Get-ScheduledTask | Where-Object { $_.TaskName -like "*MeshBay*" -or ($_.Actions.Execute -join " ") -like "*meshbay*" } 3. The sign-in launcher ("At sign-in" mode) ------------------------------------------- Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\MeshBay Node.vbs" -ErrorAction SilentlyContinue Also check the Startup folder for anything else MeshBay-related: Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" 4. Firewall rules [ADMIN] -------------------------------------------------------------------------------- Ours: "MeshBay", "MeshBay Node", "MeshBay Cast", "MeshBay Cast Discovery". Windows' own: "meshbay.exe" / "meshbay-node.exe" (TCP and UDP, "Query User"), created when somebody answered the Windows Defender Firewall pop-up -- they point at a specific path and survive everything else. Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*meshbay*" } | Select-Object DisplayName, Name, Enabled, Direction Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*meshbay*" } | Remove-NetFirewallRule 5. Uninstall the application(s) -------------------------------- a) The NSIS install (MeshBay-Setup-x.y.z.exe): Settings > Apps > Installed apps > MeshBay > Uninstall (or run "%LOCALAPPDATA%\Programs\MeshBay\Uninstall MeshBay.exe"). Run interactively, it also removes the firewall rules and the boot task with one UAC prompt. A silent uninstall (/S) does NOT -- that is why sections 2 and 4 exist. Afterwards: Test-Path "$env:LOCALAPPDATA\Programs\MeshBay" # must be False Remove-Item "$env:LOCALAPPDATA\Programs\MeshBay" -Recurse -Force # if it is not b) An AppX/MSIX build (sideloaded MeshBay-x.y.z.appx), if one was ever installed: Get-AppxPackage *MeshBay* | Select-Object Name, Version, InstallLocation Get-AppxPackage *MeshBay* | Remove-AppxPackage Its private data goes with it (%LOCALAPPDATA%\Packages\MeshBay.MeshBay_*); remove the folder if it survived. If Developer Mode was turned on only to sideload it: Settings > System > For developers > Developer Mode > Off. c) A Start-menu or desktop shortcut left behind: Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs", "$env:USERPROFILE\Desktop" -Recurse -Filter "*MeshBay*" 6. The per-user PATH -------------------- Setup adds ...\resources\node-runtime to the user PATH. Old installs, old dev builds and an MSIX can each have left their own entry, and the first one found wins: a stale entry makes `meshbay-node` in a terminal run an old version. [Environment]::GetEnvironmentVariable("Path", "User") -split ";" | Where-Object { $_ -match "meshbay|node-runtime" } Remove them (keeps every other entry): $p = [Environment]::GetEnvironmentVariable("Path", "User") -split ";" | Where-Object { $_ -and $_ -notmatch "node-runtime" } [Environment]::SetEnvironmentVariable("Path", ($p -join ";"), "User") Then check nothing answers any more (in a NEW terminal): where.exe meshbay-node # must find nothing 7. Data and profile folders (user) ---------------------------------- Moved aside in section 0 if you kept them; otherwise delete: %LOCALAPPDATA%\meshbay node.toml, keystore.enc, unlock.key, hub_pk_*.pem, data\ (roster, index, chat, media caches, ui-token), state\node.log %APPDATA%\meshbay-client the app's Electron profile: config.json (which hub), secrets.bin (device key, DPAPI), IndexedDB / Local Storage (session), caches %LOCALAPPDATA%\meshbay-client-updater left by electron-builder Remove-Item "$env:LOCALAPPDATA\meshbay", "$env:APPDATA\meshbay-client", "$env:LOCALAPPDATA\meshbay-client-updater" -Recurse -Force -ErrorAction SilentlyContinue Temporary files: Remove-Item "$env:TEMP\meshbay-firewall.log", "$env:TEMP\meshbay-elevate-service-mode.ps1", "$env:TEMP\meshbay-ffmpeg-smoke.mp4" -ErrorAction SilentlyContinue Look for anything else (older names, test copies such as meshbay.openfresh*): Get-ChildItem $env:LOCALAPPDATA, $env:APPDATA -Force -Filter "*meshbay*" Nothing is stored in Windows Credential Manager (secrets are DPAPI files in the profile above), and the app registers no URL protocol or file association. 8. Developer leftovers (only on a machine used for development) --------------------------------------------------------------- - venvs with an editable meshbay-node (e.g. C:\Users\\devel\_wintest, _pyibuild) and a meshbay-node.exe in a Python Scripts folder on PATH: where.exe meshbay-node pip uninstall meshbay-node meshbay-hub meshbay-common (in that Python) - a boot task that runs a venv's meshbay-node.EXE (section 2 finds it). - build caches: %LOCALAPPDATA%\meshbay-build-cache (ffmpeg zip), %LOCALAPPDATA%\electron-builder, the repo's dist\ and dist-msix\ folders. - IMPORTANT on a machine where tests were run from inside a packaged (Store/MSIX) app such as Claude Desktop: files that app's processes wrote under %LOCALAPPDATA% / %APPDATA% are virtualised into %LOCALAPPDATA%\Packages\\LocalCache\{Local,Roaming}\. Look there for meshbay* folders too; they are invisible elsewhere. 9. Session and environment -------------------------- - Sign out of Windows and back in (or reboot) at the end: running Explorer and terminals keep the old PATH, and a session-0 node only goes away for certain with the boot task deleted and a restart. - After the reboot, check section 1 again: no meshbay-node.exe at all. 10. Hub side (not on the machine, but it decides what the next install does) ---------------------------------------------------------------------------- - The test account still has the OLD machine's node key linked. The app deliberately never replaces another node's key on its own, so a new install signed in with that account will leave its node unlinked ("your account is linked to another node"). Before reinstalling with the same account: Node page > Settings > Unlink (on the old machine, before wiping it), or Profile > Link Node on the new one to move the link. - Groups the old node hosted stay listed on the hub with no host; delete them from the group's settings if they were test groups. - Throwaway test accounts: the hub operator deletes them. 11. Final check (everything must come back empty / False) --------------------------------------------------------- Get-Process MeshBay, meshbay-node -ErrorAction SilentlyContinue schtasks /query /tn "MeshBay Node" 2>$null Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*meshbay*" } Get-AppxPackage *MeshBay* Test-Path "$env:LOCALAPPDATA\Programs\MeshBay", "$env:LOCALAPPDATA\meshbay", "$env:APPDATA\meshbay-client" Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\MeshBay Node.vbs" [Environment]::GetEnvironmentVariable("Path", "User") -split ";" | Where-Object { $_ -match "node-runtime" } where.exe meshbay-node