Windows isn't a single operating system any more, it's a series of modules all designed to do different things.
Underlying all or most of them is the .NET Framework, an object-oriented middleware that separates the application layer from the operating system layer.
The increasingly important role of .NET and Metro as middleware were part of my reason for theorizing that, a couple of OS generations from now, Microsoft will be selling an "operating system" that goes with you to whatever machine you're using and is almost completely separated from the portion that actually has to talk to the hardware.
I got part of that theory working; most of the parts of the OS and apps I used were completely separated from the hardware, but not in a useful way.
.NET comes in several layers, all of which are critical to some things, none of which are all coordinated or integrated clearly so that when you have a problem with one version you can identify it quickly and get the rest of the framework to help fix it.
Versions 1 and 1.1 aren't used by Win7 at all. Versions 3 and 3.5 still have some use, but not much and even those don't get along well with the most recent versions.
.NET Framework 4 is the newest, most powerful version, and the one you'd expect to integrate, control or rude herd on the others by making sure they're updated and that the updates don't break anything.
Unfortunately, .NET 4 is a little standoffish toward its more primitive relatives, so Microsoft still updates them (mostly) one at a time and both the code and the updates often conflict, leading to special installation procedures if you're replacing them (in order: 4, 3.5 SP1, 1.1, unless you need version 1.0, in which case you have to go 3.5 SP1, 1.1, 1.0 and then 4. The amount of pain, trial-and-error and persistence needed to figure out and confirm all this are beyond my ken, but apparently are within that of actual Microsoft employee Aaron Stebner, who filed some of the more comprehensive advice, but not all the non-standard solutions that seemed to work for a lot of people.)
Most of the advice had more to do with running Outlook in Safe mode or cleaning out corrupted Views or Rules, which were perfectly valid, but rarely worked for others and certainly didn't for me.
Configuration errors or corrupt files on personal computers weren't causing most of the problems anyway; most appeared to come from conflicts among existing versions of .NET, or updates to one version or another that the rest didn't like.