Cybersecurity

Where Persistence Hides in Windows

MD Syful Islam Rasel

— 4 min read
Share
A Windows desktop computer sits on an office desk with a monitor, keyboard, and mouse.

If a program keeps coming back after restart, check the common Windows persistence spots in this order: Startup folders, `Run` and `RunOnce`, Scheduled Tasks, services, and then the less obvious built-in places like WMI event subscriptions, shell extensions, and logon scripts. Those are the places Windows uses to launch apps again after reboot, and they’re the fastest way to find what is relaunching. Before you change anything, write down what starts, from where, and under which account so you can tell a normal startup item from something you should leave alone.

Prerequisites

  • A Windows PC you can sign in to and restart
  • Permission to open Registry Editor, Task Scheduler, and Services
  • File Explorer access to the Startup folders
  • If this is a small-office domain, a way to check whether a policy or script is being pushed from a server

Start with the places Windows checks every time you sign in

Before you remove or disable an entry, note these details for each item:

  • Full path to the file or command
  • Display name and publisher, if present
  • The exact command line, including arguments
  • Which user or system account runs it
  • The trigger or location where you found it
  • Whether it appears in more than one startup spot

That record helps you compare the entry with the software you expected to find. It also gives you a clean way to restore a legitimate item if you later discover it was part of something normal, like a printer utility or cloud backup agent.

If you’re using Registry Editor or Task Scheduler, take a screenshot or export the key/task first when that’s possible. For files in Startup folders, keep the shortcut properties and target path. The goal is to know exactly what changed, not just that something changed.

A Windows desktop computer shows an open folder window on a monitor in a small office.

How to decide whether an item is normal or worth deeper review

Compare the entry with installed software and with what the vendor usually installs. A browser updater, for example, may reasonably appear in Startup, Run, a scheduled task, and a service. That does not make it bad. It may just mean the vendor split the work across several built-in Windows locations.

A few signs that an item is probably normal:

  • The publisher matches software you already use
  • The file path points into a known program folder
  • The name matches an installed app or updater
  • The trigger makes sense for that software

A few signs that deserve deeper review:

  • The file runs from a temporary folder, user profile, or odd-looking path
  • The name sounds generic but the path does not match the name
  • The command line uses extra arguments that you do not recognize
  • The item returns after you remove it, which suggests another launcher is recreating it

If you’re comparing a browser updater with an unknown executable, trust the one that matches a known install path and known publisher first. The unknown one is the one to inspect more carefully.

A technician stands beside a Windows desktop computer while reviewing its settings.

Finish by checking that the item no longer comes back after restart

After you disable or remove the item you identified, restart the computer and sign back in. Then check the same location you used before, along with any other startup spot that pointed to the same file.

If the program no longer launches, you’ve likely found the right persistence point. If it still comes back, the app is probably using another startup location, or a scheduled task, service, script, or policy is recreating it.

The last check is simple: reboot, sign in, and confirm that the same entry is gone and the software does not relaunch from that location.

A Windows desktop computer is shown after a restart with the desktop loaded on screen.

Conclusion

The practical order is the one that saves time: Startup folders, `Run` and `RunOnce`, Scheduled Tasks, services, then the less obvious locations if the first pass doesn’t explain it. Keep notes as you go so you can separate a normal updater from an entry that does not belong. Once you’ve found the source, verify it after a restart so you know the change held.

Frequently Asked Questions

Why does a program come back even after I delete it from Startup?

Because Startup is only one common launch point. The same program may also be set in `Run`, a scheduled task, a service, a WMI subscription, or a logon script, so you need to check those too.

Do I need to check both 32-bit and 64-bit registry views?

On 64-bit Windows, yes, if the entry still isn’t explained by the normal keys. Some software writes to the `Wow6432Node` view, so checking only one side can miss the real launch entry.

Is every scheduled task suspicious?

No. Many normal apps use tasks for updates, sync, maintenance, and logon actions. The key is whether the task matches software you recognize and whether its trigger and command line make sense.

Read more