Avoiding or Fixing Software Rot in Windows 10 – Ask Leo!

“Software rot” is both very real, and one of the most difficult things to explain and understand.

While it’s certainly become better in recent years, it remains something to consider when diagnosing a system experiencing unexpected slowdowns. While there are ways to reduce its impact, fixing it can be a major effort.

Software rot

The concept behind software rot is very simple: for seemingly inexplicable reasons, systems become slower and more unstable over time, even though you’ve done nothing you would think should cause it.

I say “seemingly inexplicable” because understanding exactly what changes are occurring, even though you believe you’ve done nothing, and exactly why those changes are having the effect they seem to have is almost impossible. However the effect you and I experience is very, very real.

To be clear, software is not like some kind of fresh fruit that you have to keep in a refrigerator to keep it from degrading. Software, untouched, should remain exactly as it is as long as the computer it’s installed on keeps running.

And yet, it feels like it does decay over time. It seems to slowly “rot”, if you will.

The key is that word I used above: “untouched”. We’re doing things with and to our computers all the time.

report this ad

Installing and uninstalling software

This might be the number one cause of software rot over time. It particularly affects those who love to try things out by installing them on their computers, and then uninstalling (or perhaps not) after some time.

The issue is a complex one, but boils down to the fact that modern computer programs are incredibly complex. As a result, installing an application is a complex operation affecting many different parts of the computer beyond just the application itself.

Many people tend to focus on the Windows registry as the root of this evil. While poor registry management can be part of the problem, there are frequently much larger issues at play.

Applications try, as much as possible, to avoid duplicating functionality and avoid re-inventing the wheel by sharing code, or by using libraries of code that are designed to be shared among multiple applications. For example:

• Program A installs and uses library Y.
• Program B uses library Y also, but doesn’t need to install it since it’s already there by virtue of program A being installed.

You save disk space, and both programs A and B save development cost since they both didn’t need to each independently invent library Y.

What happens when you uninstall program A? Should it:

• Uninstall library Y, since it was responsible for installing it?
• Leave library Y, since another program is using it?
• Leave library Y, since another program might be using it?

(I have to call out the difference between “is using” and “might be using” since there is no reliable technique to keep track of who’s using what.)

No matter what decision is made, it can be viewed as either right or wrong.

Version accumulation

The situation gets even more complex when applications end up relying on different versions of the same libraries. For example:

• Program A uses version 2.14 of library Y.
• Program B uses version 2.12 of library Y.

If version 2.14 of the library is present because program A was installed first, what should program B do?

• Assume 2.14 is the version to use, since that’s “better than” then version 2.12 that it requires? If that assumption is wrong, program B fails.
• Assume that only 2.12 will do and install it along side of 2.14, if that’s even possible?
• “Downgrade” the library by replacing 2.14 with the version 2.12 that it requires, possibly breaking program A?

Or if program B was installed first, what should program A’s installation do?

• Replace version 2.12 of the library with version 2.14 because it’s a newer version and an “upgrade”, possibly breaking program B?
• Install version 2.14 of the library along side 2.12, if that’s even possible?

And what, if anything, should happen with either program A or B is uninstalled?

The kicker is that all of these answers are absolutely right, and absolutely wrong, depending on the programs involved, the libraries involved, and a multitude of other things.

Most often this is why you’ll often see multiple versions of libraries, like the Visual C++ Runtime, installed in Windows. Apparently the approach taken is to install the version you need if it’s not already there, and then never uninstall it in case another program is using it.

The net result of all this confusion is applications break, misbehave or simply behave poorly because the assumptions that they once made about what resources to use and how to use them are challenged as applications are installed and uninstalled.

Updates

One of the things many folks point at are software updates; specifically Windows Update. We keep hearing news stories of systems that have problems after an update.

Yes, I would say this is a form of software rot. Bad updates can cause problems. Not, however, even completely benign updates can impact your system’s performance by pushing resource requirements higher, perhaps even beyond your system’s ability to cope.

Nonetheless, continuing to regularly take updates is important. You are more likely to be impacted by an unpatched vulnerability if you don’t take updates than you are by some kind of destabilization if you do.

Don’t let headlines spook you into poor decisions. “Bad” updates make headlines because they’re uncommon. “Good” updates never make news because they just work. Most updates, by far, just work.

Preventing software rot

Avoid installing and uninstalling software.

I know it’s nice to try out software from time to time, but if this is something you do frequently it’s best to use a sacrificial machine, or better , a virtual machine, you can rebuild from scratch or restore from a backup image after your experimentation.

Take a backup before and restore it after a software trial. This guarantees changes made by the software are removed from your machine. Take the backup before even if you don’t plan to restore it, just in case something goes wrong.

Fixing software rot

If you suspect software rot as the cause of your machine’s  performance issues and instability there are only two approaches to recovery:

• Restore the machine from an image backup made when it was stable and performing properly.

Or

While the situation has improved in recent years, software rot remains enough of an issue that individuals such as myself whose job it is to try out software of various sorts will simply plan on a complete reinstall of the software on their computer (by restoring a backup or performing an actual reinstall) every few years.