Nothing says “good morning” like opening a laptop and watching it light up with six auto-starting apps you didn’t ask for. The fans spin, the VPN client argues with the Wi‑Fi, and Teams decides it’s the most important thing in your life—again.
If you’ve tried “disable in Task Manager” and the app came back anyway, you’re not crazy. You just hit the reality that Windows startup is not one thing. It’s a collection of mechanisms. You have to shut the right doors, in the right order, with proof.
Why it keeps coming back (startup is a hydra)
When people say “an app starts with Windows,” they usually imagine a single toggle. Windows does have a friendly UI for some of it. But the OS also supports:
- Startup folders (per-user and all-users)
- Registry “Run” keys (per-user and machine-wide)
- Services (some are apps in a trench coat)
- Scheduled tasks (logon triggers, startup triggers, “on idle,” and “every 5 minutes forever”)
- Group Policy (enforcement that quietly reverts your “fix”)
- Installer repair/self-heal (reinstalls an autostart entry during “update”)
- App-managed settings (the app rewrites keys on launch)
The reason your change “doesn’t stick” is usually one of these:
- You disabled the entry in one place, but it exists in two others.
- A scheduled task re-adds the registry key at next login.
- The entry is in HKLM, but you disabled it in HKCU (or vice versa).
- GPO or MDM re-applies it, because corporate life is built on control.
- You disabled the wrong thing and the app now “fails open” by using a different startup path.
The PowerShell method that actually sticks is not one command. It’s a disciplined workflow:
- Inventory all autostart mechanisms.
- Disable with intent (and in the right scope: user vs machine).
- Verify after reboot and after an update cycle.
- Keep rollback data so you can undo without drama.
One operational quote worth keeping on your desk: “Hope is not a strategy.”
— General Gordon R. Sullivan. In ops, hope looks like “I disabled it once in Task Manager and moved on.” Don’t do that.
Interesting facts and short history (why startup is like this)
- Startup folders predate modern Windows security models. They’re a simple shell feature: put a shortcut here, it runs at logon.
- The “Run” registry keys were built for convenience. They became a standard mechanism for installers long before “least privilege” was fashionable.
- Task Scheduler is older than most “autostart managers.” It’s extremely capable, which means it’s also extremely abused.
- Windows services aren’t just OS plumbing. Vendors run update agents and background sync tools as services because services start early and can run without a user session.
- 64-bit Windows has two “views” of some registry paths. Redirection can cause you to disable one view while the other still launches components.
- Autoruns-style persistence is a security problem, not just a convenience feature. Malware and “legitimate” software both use the same autostart surfaces.
- Task Manager’s Startup tab is curated. It doesn’t show everything. It shows what Microsoft decided should be user-facing and safe-ish to toggle.
- GPO startup/logon scripts are still alive. They’re boring, reliable, and frequently the hidden hand behind “it keeps coming back.”
Joke #1 (short and relevant): Windows has so many startup paths that “disable startup” is basically a scavenger hunt—except the prize is fewer background processes.
Fast diagnosis playbook (check these first)
When a machine boots slowly or launches unwanted apps, don’t immediately start deleting registry keys like it’s 2009. Move fast, but with a map.
First: identify the mechanism (folder vs registry vs task vs service)
- Task Scheduler triggers (logon/startup) are the #1 reason a “disabled” app resurrects.
- Run keys are the #1 reason an app appears instantly after login.
- Services are the #1 reason you “disabled it” but it still runs in the background without UI.
Second: identify scope (per-user vs machine-wide)
- If it happens for every user, suspect HKLM, All Users Startup folder, services, scheduled tasks, or GPO.
- If it happens for one user, suspect HKCU, per-user Startup folder, or app profile settings.
Third: prove change persistence
- Reboot once to validate baseline.
- Trigger an update cycle (or wait for it) and re-check.
- If managed by IT, run policy refresh and re-check.
The autostart map: every place apps sneak in
Here are the surfaces that matter in the real world. If you cover these, you catch most “sticky” startup behavior without turning into a forensic analyst.
1) Startup folders
- Per-user:
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup - All users:
%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup
These are blunt instruments. If there’s a shortcut, it runs. If you remove it, it doesn’t. The downside: installers love dropping shortcuts here; users also love dropping nonsense here.
2) Registry Run keys
- Per-user:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run - Machine-wide:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run - Also check:
...\RunOncefor one-time startup actions
Run keys are the classic “launch this at logon” mechanism. They’re easy to set, easy to abuse, and annoyingly persistent across upgrades.
3) Scheduled Tasks
Tasks can be configured with triggers like:
- At log on (any user or specific user)
- At startup
- On idle
- On workstation unlock
- On an event log entry
If a vendor wants “reliability,” they use Task Scheduler. If a vendor wants “persistence,” they also use Task Scheduler. Same tool, different vibe.
4) Services
Services start before you log in and can run forever. If an app has an “update service” or “helper,” it might start the user-facing process after login. Disabling the app UI autostart may do nothing because the service restarts it.
5) Group Policy / MDM
GPO can deploy scheduled tasks, set registry entries, run scripts at logon, and more. MDM profiles can do similar enforcement. The key operational insight: if policy owns it, your local tweak is a temporary illusion.
Practical tasks with commands, outputs, and decisions
Below are real tasks you can run from PowerShell. I’m using a shell-style prompt in the code blocks for consistency; run the commands in an elevated PowerShell where needed. Each task includes: the command, what typical output means, and the decision you make next.
Task 1: Get a quick view of user startup folder items
cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Force \"$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\" | Select-Object Name,FullName"
Name FullName
---- --------
Teams.lnk C:\Users\alice\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Teams.lnk
OneDrive.lnk C:\Users\alice\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk
What it means: Shortcuts in this folder will run at logon for this user.
Decision: If the unwanted app is here, remove the shortcut (or move it to a quarantine folder) rather than “disabling” in UI.
Task 2: Check the all-users startup folder
cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Force \"$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\" | Select Name,FullName"
Name FullName
---- --------
VendorUpdater.lnk C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\VendorUpdater.lnk
What it means: Anything here hits every user who logs onto the box.
Decision: If this is a corporate build, confirm with IT policy owners before removing; otherwise you’ll “fix” it and the next baseline enforcement will put it back.
Task 3: Enumerate HKCU Run entries (per-user)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' | Select-Object * -ExcludeProperty PS*"
OneDrive : "C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background
Teams : "C:\Users\alice\AppData\Local\Microsoft\Teams\current\Teams.exe" --processStart "Teams.exe"
What it means: These values are executed at logon for this user.
Decision: If an app is here, remove just that value—don’t nuke the whole key. Save the existing value first for rollback.
Task 4: Enumerate HKLM Run entries (machine-wide)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run' | Select-Object * -ExcludeProperty PS*"
SecurityHealth : %windir%\system32\SecurityHealthSystray.exe
VendorAgent : "C:\Program Files\Vendor\Agent\agent.exe" --startup
What it means: These run for all users at logon. Requires admin to change.
Decision: If it’s a vendor agent with corporate purpose (security, compliance), don’t disable it casually. If it’s bloat, disable it with a recorded change and a rollback plan.
Task 5: Export Run keys before you touch them (rollback insurance)
cr0x@server:~$ powershell -NoProfile -Command "reg export 'HKCU\Software\Microsoft\Windows\CurrentVersion\Run' $env:TEMP\hkcu-run-backup.reg /y; reg export 'HKLM\Software\Microsoft\Windows\CurrentVersion\Run' $env:TEMP\hklm-run-backup.reg /y; dir $env:TEMP\*-run-backup.reg"
Directory: C:\Users\alice\AppData\Local\Temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2/5/2026 9:14 AM 1320 hkcu-run-backup.reg
-a---- 2/5/2026 9:14 AM 1987 hklm-run-backup.reg
What it means: You now have a restore path that doesn’t depend on your memory.
Decision: If you can’t or won’t take a backup, you’re not ready to make a change on someone else’s machine.
Task 6: Remove a specific HKCU Run value (surgical change)
cr0x@server:~$ powershell -NoProfile -Command "Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'Teams' -ErrorAction Stop; 'Removed HKCU Run value: Teams'"
Removed HKCU Run value: Teams
What it means: The value is gone. It won’t launch from that mechanism.
Decision: Re-check after reboot. If it comes back, you’re dealing with a task, service, policy, or the app rewriting its own key.
Task 7: List scheduled tasks that trigger at logon or startup
cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object { ($_.Triggers | Out-String) -match 'Logon|Startup' } | Select-Object TaskName,TaskPath,State | Sort-Object TaskPath,TaskName | Format-Table -AutoSize"
TaskName TaskPath State
-------- -------- -----
Vendor Updater \Vendor\ Ready
Teams Update Task \Microsoft\Teams\ Ready
OneDrive Standalone \Microsoft\OneDrive\ Ready
What it means: These are candidates for “it came back.” The trigger details are simplified here; the presence is your clue.
Decision: Inspect the specific task’s action and principal before disabling. Some tasks run under SYSTEM; some only at a user logon.
Task 8: Inspect a specific scheduled task (action + trigger + run-as)
cr0x@server:~$ powershell -NoProfile -Command "$t=Get-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\'; $t | Select-Object TaskName,State; $t.Principal | Select-Object UserId,LogonType,RunLevel; $t.Actions | Select-Object Execute,Arguments; $t.Triggers | Select-Object *"
TaskName State
-------- -----
Teams Update Task Ready
UserId LogonType RunLevel
------ --------- --------
SYSTEM ServiceAccount Highest
Execute Arguments
------- ---------
C:\Users\alice\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
Enabled : True
Delay : PT30S
UserId :
What it means: This task runs as SYSTEM and launches an updater that can relaunch the app. Disabling HKCU Run won’t stop this.
Decision: If you need the updater but not the launch, look for an argument that starts the UI. If policy allows, disable the task and confirm the app doesn’t respawn it.
Task 9: Disable a scheduled task (reversible)
cr0x@server:~$ powershell -NoProfile -Command "Disable-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\' | Out-Null; (Get-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\').State"
Disabled
What it means: The task is disabled. It won’t run on its triggers.
Decision: Reboot and confirm. If the task re-enables itself, that’s usually GPO/MDM or the updater running as admin elsewhere.
Task 10: Find services set to Automatic that look vendor-ish
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' } | Select-Object Name,StartName,State,PathName | Sort-Object Name | Select-Object -First 8"
Name StartName State PathName
---- --------- ----- --------
BITS LocalSystem Running C:\Windows\System32\svchost.exe -k netsvcs -p
VendorAgent LocalSystem Running "C:\Program Files\Vendor\Agent\agentservice.exe"
VendorUpdater LocalSystem Running "C:\Program Files\Vendor\Updater\updater.exe" /service
wuauserv LocalSystem Running C:\Windows\system32\svchost.exe -k netsvcs -p
What it means: Services with vendor paths can be legitimate (security/management) or pure “always-on marketing.”
Decision: If you disable a service, document it and know what depends on it. Don’t guess on production endpoints used by execs five minutes before a board call.
Task 11: Disable a service auto-start (do it safely)
cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name 'VendorUpdater' -StartupType Disabled; Get-Service -Name 'VendorUpdater' | Select Name,Status,StartType"
Name Status StartType
---- ------ ---------
VendorUpdater Running Disabled
What it means: StartupType is disabled, but the service is still running right now.
Decision: If you want it stopped immediately, stop it explicitly (next task). If you’re doing this on a server, check change windows and dependent services first.
Task 12: Stop the service now and verify it stays down
cr0x@server:~$ powershell -NoProfile -Command "Stop-Service -Name 'VendorUpdater' -Force; Get-Service -Name 'VendorUpdater' | Select Name,Status,StartType"
Name Status StartType
---- ------ ---------
VendorUpdater Stopped Disabled
What it means: It’s stopped and won’t restart automatically via service control manager.
Decision: If the process reappears anyway, something else is starting it: a scheduled task, another service, or an app self-heal.
Task 13: Check whether GPO is applying startup/logon scripts
cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Logon Scripts|Startup Scripts|Applied Group Policy Objects' -Context 0,3"
Applied Group Policy Objects
-----------------------------
Corp-Workstation-Baseline
Corp-App-Deployment
Logon Scripts
--------------
\domain\netlogon\corp-logon.ps1
What it means: Logon scripts exist. They can add Run keys, create scheduled tasks, or drop startup shortcuts.
Decision: If policy is involved, stop doing local-only hacks. Escalate to whoever owns the baseline and fix it at the source.
Task 14: Force a policy refresh (to test whether your change gets reverted)
cr0x@server:~$ powershell -NoProfile -Command "gpupdate /force"
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
What it means: Policies re-applied. If your setting “undoes” now, you’ve proven policy ownership.
Decision: Either adjust the GPO/MDM config or accept that this startup item is mandated and focus on performance impact instead.
Task 15: Verify what actually started since last boot (process reality check)
cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object StartTime -Descending | Select-Object -First 10 Name,Id,StartTime"
Name Id StartTime
---- -- ---------
Teams 884 02/05/2026 09:21:40
OneDrive 910 02/05/2026 09:21:35
VendorAgent 622 02/05/2026 09:20:58
explorer 4020 02/05/2026 09:20:40
What it means: You’re looking at observed behavior, not configuration intent.
Decision: If the app is still starting, you missed a mechanism or something is re-enabling it. Go back to tasks/svc/registry.
Task 16: Track file/command responsible for a startup shortcut
cr0x@server:~$ powershell -NoProfile -Command "$lnk=Join-Path $env:APPDATA 'Microsoft\Windows\Start Menu\Programs\Startup\Teams.lnk'; $w=New-Object -ComObject WScript.Shell; $s=$w.CreateShortcut($lnk); $s.TargetPath; $s.Arguments"
C:\Users\alice\AppData\Local\Microsoft\Teams\current\Teams.exe
--processStart "Teams.exe"
What it means: You’ve resolved the shortcut to the actual binary and arguments.
Decision: Use this to confirm whether you’re disabling the right thing. If the target is an updater that launches the app, your fix needs to address the updater too.
Task 17: Detect “RunOnce” surprises (one-time entries that still matter)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce' -ErrorAction SilentlyContinue | Select-Object * -ExcludeProperty PS*"
UpdateFinalize : "C:\Program Files\Vendor\Updater\finalize.exe" /boot
What it means: RunOnce entries are meant to run and disappear, but they can reappear if an updater keeps scheduling them.
Decision: If boot performance is the issue, these are prime suspects. Don’t delete blindly; fix the updater behavior if it’s looping.
Three corporate mini-stories from the trenches
Mini-story 1: The incident caused by a wrong assumption (Task Manager is not the truth)
A desktop engineering team got a wave of tickets: “Laptop boot is slow, Teams keeps opening, CPU pinned at login.” They did what everyone does at first—they told users to disable Teams in Task Manager’s Startup tab. The tickets paused, then came back. Same symptoms, same users, same machines.
The wrong assumption was subtle: they assumed the Startup tab was a complete view. It wasn’t. On those builds, the UI toggle disabled a registry Run entry, but a scheduled task remained. The task ran at logon as SYSTEM, launched an updater, and the updater launched the UI process anyway.
Worse, the task was deployed by a baseline policy, so even when someone disabled it locally, it re-enabled at the next policy refresh. That created the “it doesn’t stick” pattern that erodes trust. Users started treating IT guidance like weather forecasts.
The fix wasn’t heroic. They audited logon/startup tasks, identified the exact task and action, and changed the baseline to run the updater without launching the UI at login. The important part: they added verification—post-login process checks and policy refresh tests—so they could prove it stayed fixed.
Mini-story 2: The optimization that backfired (disabling the updater service)
A different org had a performance push: reduce boot time, reduce background services, “make laptops feel fast.” A well-meaning engineer found a vendor updater service set to Automatic. It looked nonessential, so they disabled it across a pilot group.
Boot time improved. People clapped. Then, a few weeks later, a critical security update for that vendor’s client lagged on the pilot machines. The updater service wasn’t just “nice to have”—it was the delivery path for patches and configuration fixes.
The backfire wasn’t that disabling a service is inherently bad. It was that they optimized one metric (boot speed) without preserving the system’s ability to maintain itself. In SRE terms: they improved latency while quietly reducing reliability.
The recovery plan was a compromise: set the service to Manual (or Automatic (Delayed Start) where supported), stop launching UI components at login, and keep update mechanisms intact. They also added monitoring: machines missing updates were flagged. You don’t want to discover “we disabled patch delivery” by reading a post-incident report.
Mini-story 3: The boring but correct practice that saved the day (backup + controlled disable)
A finance department endpoint started launching a legacy reporting tool at every login. It took a full minute to load, and it dragged network shares into the authentication path. On month-end close, that minute turned into angry humans quickly.
An engineer did the least glamorous thing imaginable: before changing anything, they exported the relevant registry keys and recorded current scheduled task definitions. They then disabled the startup entries one mechanism at a time, rebooting and verifying after each change. Slow, methodical, annoyingly correct.
Two days later, an update re-added a Run key entry. Because they had a baseline snapshot, they could prove what changed and when. They didn’t argue with the vendor; they presented evidence: “Your updater reintroduced this autostart on update.” That changed the conversation.
The final fix was stable: remove the logon trigger task, keep the update task, and enforce “no UI auto-launch” via configuration. The month-end close went back to being boring. Boring is an underrated feature.
Checklists / step-by-step plan that doesn’t rot
Checklist A: Single machine, you just want the app to stop launching
- Inventory current state
- Startup folders (per-user and all-users)
- HKCU and HKLM Run keys
- Scheduled tasks with Logon/Startup triggers
- Services with vendor paths, set to Auto
- Back up
- Export Run keys to .reg files
- Record task name/path and service startup types
- Disable in the most precise place first
- Remove a specific Run value
- Disable the specific scheduled task that launches the UI
- Remove the startup shortcut
- Reboot and verify
- Confirm the process is not running after login
- Confirm the entry doesn’t come back
- Trigger reversion forces
- Run policy refresh
- Let the app update (or run its updater) and re-check
Checklist B: Corporate fleet, you need it to stick across updates and users
- Decide ownership first: local change vs baseline policy vs app configuration.
- Find the canonical startup mechanism: task/service/Run key created by the installer or management tool.
- Prefer “disable UI auto-launch” over “break update delivery”.
- Implement centrally: scheduled task deployment, registry preference, or MDM setting—whatever your org uses consistently.
- Add validation: a compliance check that the autostart entry is absent/disabled and the process isn’t running post-login.
- Document rollback: what to re-enable and what side effects you expect.
Joke #2 (short and relevant): If you disable the wrong startup entry, Windows will teach you humility at the next reboot—free of charge.
Common mistakes: symptom → root cause → fix
1) Symptom: “Disabled in Task Manager, but it still launches”
Root cause: Scheduled task or service launches it; Task Manager only toggled one surface.
Fix: Enumerate tasks with Logon/Startup triggers, inspect the task action, disable or adjust the specific task. Then check services that might spawn the UI process.
2) Symptom: “It stops for me, but not for other users”
Root cause: You changed HKCU or per-user Startup folder only.
Fix: Check HKLM Run and All Users Startup folder, plus scheduled tasks triggered for “Any user.” Apply the fix at the machine scope if appropriate.
3) Symptom: “It comes back after an update”
Root cause: App self-heal re-adds Run keys/tasks; updater runs with elevated rights.
Fix: Disable the specific “launch at login” behavior (often a task) while leaving update mechanisms. If you must remove keys, script it and run after updates via management tooling.
4) Symptom: “I disabled the service, now the app breaks in weird ways”
Root cause: You disabled a shared component (update/telemetry/auth broker) the app depends on.
Fix: Re-enable the service and change the UI autostart path instead. If the service is the problem, set to Manual or Delayed Start and validate app behavior.
5) Symptom: “I can’t remove it; access denied”
Root cause: HKLM keys, system tasks, or services require admin. Or policy is enforcing it.
Fix: Elevate properly; if the item reappears after gpupdate /force, it’s policy-owned. Fix centrally, not locally.
6) Symptom: “No startup items found, but the app still opens”
Root cause: App uses a non-obvious trigger: event-based scheduled task, Explorer shell extension, or another app launches it.
Fix: Inspect scheduled tasks beyond simple Logon/Startup, and check what process is parent-launching it (requires deeper tooling). Start by searching Task Scheduler library for vendor names.
7) Symptom: “Boot is slow; nothing obvious starts”
Root cause: Background services and drivers, not user apps. Or tasks run during startup before login UI.
Fix: Audit Automatic services and startup tasks. Don’t focus only on user-facing autostart.
FAQ (the questions people ask five minutes before a change window)
1) Is Task Manager’s Startup tab enough?
No. It’s a convenient slice of the problem. Scheduled tasks and services often bypass it completely, and policy can override it.
2) What’s the safest thing to disable first?
The specific entry that launches the UI at login: a per-user Run value or a logon-triggered scheduled task. Avoid disabling update services unless you understand patching consequences.
3) How do I know if the startup is per-user or machine-wide?
Check where the entry lives. HKCU and the user Startup folder affect one user. HKLM, all-users Startup, services, and many tasks affect everyone.
4) Why does it come back after I delete a registry value?
Because something else is rewriting it: an updater task, a service, or policy. Prove ownership by disabling the task and forcing policy refresh to see what reverts.
5) Should I delete the whole Run key to “clean it up”?
No. That’s how you break legitimate startup components and create a troubleshooting mess. Remove the specific named value only, and back up first.
6) What about “RunOnce” keys—should I clear them?
Only if they’re stuck in a loop and you’ve confirmed the underlying updater is misbehaving. RunOnce is often legitimate for installers and post-update finalization.
7) How do I handle corporate devices where policy re-enables everything?
Stop fighting locally. Identify the GPO/MDM artifact (task, registry preference, script) and change it centrally. Local tweaks are temporary and create inconsistent fleets.
8) Can I “disable autostart” but still allow the app to run when needed?
Yes. Disabling autostart doesn’t uninstall the app. Your goal is to stop automatic launch paths, not remove binaries—unless you’re also decommissioning the app.
9) If I disable a scheduled task, could something break?
Yes. Some tasks are update pipelines or maintenance jobs. Inspect the task action first. If it launches the UI process at logon, disable that one; keep update-only tasks if possible.
10) What’s the “stickiest” method?
The stickiest method is the one that matches the owner. If the app uses a scheduled task, disable or modify that task. If IT policy deploys it, change the policy. Otherwise you’re playing whack-a-mole.
Conclusion: next steps that actually reduce noise
If you want startup control that sticks, stop treating it like a single toggle. Treat it like a small reliability problem: multiple inputs, multiple controllers, and plenty of opportunities for silent revert.
Do this next, in order:
- Run an inventory: Startup folders, HKCU/HKLM Run keys, scheduled tasks, and Automatic services.
- Back up the state (export Run keys; record tasks/services).
- Disable the exact mechanism that launches the app, starting with scheduled tasks and Run values.
- Reboot and verify by observing processes, not just configuration.
- Force policy refresh and wait for an update cycle—then verify again.
When it “doesn’t stick,” that’s not failure. That’s information. It tells you who owns the behavior: the app, the updater, or the policy engine. Once you know the owner, the fix becomes boring. And boring is how production stays up.