How to Disable Startup Programs in Windows 11: Startup Folders and Autoruns
Find startup programs that do not appear in the normal Windows 11 Startup list by checking Startup folders and, for advanced troubleshooting, Microsoft Sysinternals Autoruns.
- Applies to Windows 11
- 4 min read
View article illustration

Use this guide when a recognised app opens at sign-in but is absent from the normal Startup list, or still opens after you disabled its listed entry. If it appears normally in Settings, use the simpler startup-app controls first.
Identify what actually launches
Record the app name, the account affected and the moment it appears: before sign-in, immediately after sign-in, or only after another app opens. An entry with a similar name is not enough evidence to remove it. Check the executable's path and publisher against the application you installed.
| Observation | Next check |
|---|---|
| Only one account gets the unwanted window | Inspect that account’s Startup folder first. |
| Multiple accounts show the same app | Inspect the all-users folder; do not change shared behaviour without considering other users. |
| No matching shortcut is present | Use Autoruns to identify the launch location, keeping the first pass read-only. |
| The delay occurs before sign-in, without an unwanted app window | Return to startup-delay diagnosis; removing a sign-in shortcut may not address it. |
Check the current user's Startup folder
Press Win + R and enter:
shell:startupThis opens the current account's Startup folder. Inspect a matching shortcut's Properties and target before changing it. For a reversible trial, move only the recognised shortcut to a clearly named folder outside Startup, and record its original location. Leave the installed application itself in place.
Save work and restart, then check whether the unwanted launch stopped. If you need the previous behaviour, put that shortcut back in the same Startup folder and check the next sign-in. If no shortcut matches, an empty folder is a finding—not a reason to remove something else.
Check the all-users Startup folder
In the Run dialog, enter:
shell:common startupThis is a shared launch location. A change here can affect other accounts and may require administrator permission. Apply the same identify, record, move and restore workflow only if you are responsible for the shared setting. Stop if policy or permissions prevent the change.
Use Autoruns for advanced troubleshooting
Get Autoruns from Microsoft Sysinternals. It lists launch locations beyond ordinary startup apps, including scheduled tasks, services and other system components. Begin by locating the suspected app and recording its entry, image path and launch location.
- Use the category tabs to narrow the investigation. Start with logon entries for an app that opens after sign-in.
- Inspect Properties and Jump to Entry to understand what you found.
- Hide Signed Microsoft Entries can reduce clutter; it does not declare remaining entries safe to disable.
- For a positively identified, optional application entry, uncheck it rather than delete it. Record the change, restart and check the symptom.
- If needed, recheck that same entry to restore it.
What about MSConfig?
A clean boot answers a different question: whether background software is causing a conflict. It temporarily changes more than one launch setting and requires a recovery plan for normal startup. Follow Microsoft's clean-boot procedure when that diagnosis is warranted, rather than using MSConfig as a permanent speed preset.
Registry startup entries
Finding a registry launch location does not mean you need to edit it. Prefer the application's supported settings or the reversible entry control above. If an entry returns, record whether it follows an app update, sign-in or another trigger and consult the vendor or IT; do not fight it with repeated deletion.
Keep your investigation notes private when they contain usernames or file paths. A useful support report includes the app version, launch timing, entry location, one change tried and whether restoring it restored the previous behaviour.
Documentation review: 6 October 2026. Checked against the linked primary sources. This is an editorial troubleshooting workflow, not a measured speed-up or a claim that these changes were tested on your PC.


