Clean Windows Startup of Unwanted Auto-Launch Apps

What the Windows startup cleaner does

This Automox Worklet™ enumerates the auto-launch entries on Windows endpoints and removes any entry whose name or executable path matches a curated removal list. The Worklet inspects four sources: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, the All Users Startup folder under C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup, and the per-user Startup folder under each profile's AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. Matching entries are removed; unmatched entries are left alone.

The Worklet reads the removal list from a RemoveList parameter, which accepts either entry names or executable file names. Pattern matching uses -like with wildcard support so a single rule can cover product variants (for example, AcroTray* catches both Acrobat and Acrobat Reader startup helpers). The script also reads a RunOnce parameter that controls whether the matching RunOnce keys are removed alongside Run; the default is to leave RunOnce alone because legitimate installer flows use it for first-boot finalization.

Evaluation reads the four startup sources without modifying anything, so endpoints with a clean startup state pass at exit code 0 and remediation is skipped. Policies can sit on a weekly cadence as a result: a software install that opts itself into Run on a Tuesday is caught on the next evaluation cycle, the corresponding registry value is removed, and the activity log records the change without spamming events on the 99% of endpoints that did not drift.

Why control Windows startup at fleet scale

Every auto-launch entry on a Windows endpoint costs boot time, memory, and CPU for the lifetime of the session. Most of those entries are not the user's choice; they are added by software installers that opt themselves into startup by default, by OEM tools that re-add themselves after an uninstall attempt, and by user-installed utilities that ask once and then never again. Over a few months on an active endpoint, the Run hive accumulates eight to twelve entries no one in IT chose, each of them fighting for CPU and disk during the first thirty seconds after login.

Scheduling this Worklet on a weekly cadence keeps the Run keys and Startup folders aligned with the curated removal list, so a fresh login on any Windows endpoint starts from a known baseline. A new software install that opts itself into startup gets caught on the next evaluation rather than waiting until a help desk ticket about slow boot times surfaces it. The same policy pass applies to shared kiosks, developer workstations, and executive laptops in scope, so the boot-time hygiene standard does not trail the loudest user. Pair this Worklet with a separate auto-launch monitoring policy if your runbook requires evidence of what was running before the cleanup ran.

How the startup cleanup works

1. Evaluation phase: The Worklet reads HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with Get-ItemProperty, repeats the read against the HKCU hive for each loaded user profile, and lists the contents of the All Users and per-user Startup folders with Get-ChildItem. Each entry is matched against the RemoveList parameter using -like. If at least one match is found, the endpoint is flagged for remediation. Endpoints with no matches are reported compliant and skipped.

2. Remediation phase: The remediation script removes matching registry values via Remove-ItemProperty and deletes matching shortcut files from the Startup folders via Remove-Item. If the RunOnce parameter is set to true, the script also clears matching entries from the Run-Once registry keys. The script logs every removal to Write-Output with the source key or folder path, then exits 0 on success or non-zero with the offending entry name in stderr if a removal failed due to permissions or a locked file.

Startup cleanup requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7 available

• Local administrator or SYSTEM privileges for the Automox agent (the default agent context satisfies this) so the script can read all user hives and the All Users Startup folder

• A curated RemoveList parameter that enumerates the unwanted entry names; populate it from a first-run inventory pass that lists what auto-launch entries are currently in the fleet

• Awareness that this Worklet does not stop scheduled tasks that auto-launch at logon; pair it with a separate scheduled-task hygiene Worklet if the threat model requires that surface as well

• A documented exclusion process for legitimate auto-launchers (corporate VPN client, MDM agent, endpoint protection) so the curated list does not accidentally remove software the organization needs

Expected Windows startup state after cleanup

After successful remediation, the Run and RunOnce registry keys and the Startup folders contain only entries that are not on the curated removal list. A fresh login on the endpoint launches the approved auto-launchers and nothing else. Subsequent Automox policy runs report the endpoint as compliant unless a new install or user action has re-added an entry on the removal list, at which point the next evaluation catches and removes it.

Validate the Worklet on a single endpoint by running Get-ItemProperty against the Run keys before and after, then comparing the resulting entry sets. For audit evidence, capture the Worklet's Write-Output log showing each removal and store it with the policy run identifier. A regression where the same entries reappear on a later run usually means an installer or update agent is re-registering itself; in that case, add the responsible installer to a separate uninstall policy rather than fighting the symptom on each cleanup pass.