Tech Behind ThingsHow the ordinary machinery actually works

Software

Why Uninstalling Leaves Pieces Of A Program Behind

An uninstaller removes what its own installer recorded, which excludes everything the program created afterward, so files and settings routinely survive removal.

Vibrant and engaging code displayed on a computer screen, showcasing programming concepts.
Photograph by Seraphfim Gallery via Pexels
Editorial note. Independent reporting and analysis. Nothing here is sponsored or paid for. How we work.

Removing an application rarely returns a machine to the state it was in before. The reason is structural: an uninstaller knows about installation, and almost nothing a program leaves behind was created during installation.

Removal is driven by a list

An installer records what it placed on the system, including files, shortcuts and registry entries, and the uninstaller works through that record in reverse.

Anything not on the list is invisible to it. The mechanism is bookkeeping rather than inspection, and it cannot remove what it was never told about.

Files written by the program during years of use fall entirely outside the record, because they did not exist when the record was made.

User data is excluded deliberately

Settings, caches, saved sessions and documents live in per-user directories, and removing them would destroy work if the user is upgrading or reinstalling.

Uninstallers therefore leave them alone by default, which is the right choice for a reinstall and the wrong one for a permanent removal.

The consequence is that reinstalling an application often restores the exact configuration that was causing the problem the reinstall was meant to solve.

Shared components cannot be removed safely

Runtimes, drivers and shared libraries are installed once and used by several applications, tracked by a count of how many programs depend on them.

Removing one application decrements the count, and the component is only removed at zero. A miscounted dependency leaves it installed permanently.

The alternative was worse. Systems that removed shared components eagerly used to break unrelated software, which is why the conservative behavior became standard.

Some pieces cannot be deleted while running

Files in use, kernel drivers and services that are still loaded cannot be removed immediately, so uninstallers schedule deletion for the next restart.

If the machine is not restarted, or if the scheduled operation fails silently, those files remain with nothing left to remove them.

This is the origin of leftover folders that reappear in the same place after every attempt to delete them manually.

Cloud accounts keep their own copy

Applications that sync settings to an account store configuration on a server, and uninstalling the local copy does not touch it.

Signing in again on a fresh installation pulls the old state back down, which makes a clean reinstall genuinely difficult without removing the account-side data separately.

Anyone actually trying to reset an application therefore has to deal with three locations: the installed files, the local user data, and whatever the account is holding.

Questions readers ask

Why does a copied folder show a different size?

Block allocation, compression and metadata differ between filesystems. The contents are identical while the space consumed is not.

Is defragmenting a solid state drive useful?

No. There is no seek penalty to remove, and rewriting every block consumes write endurance for no measurable benefit.

Softwarestoragesoftwareoperating systemsdata
Junko Ishida
Contributing writer, Tech Behind Things

Junko covers batteries, charging and energy density, and is unimpressed by most battery claims.

Also by Junko Ishida