So the fix to bypass this error, download and install the Windows Installer CleanUp Utility and remove all instances of the failed install attempts of MSXML and SQL Server components.

Viola, problem solved.

Over the past few years, when approached with the question of which OS one should run on their corporate network, I unwaveringly respond, “Windows XP” [of course]. The principle argument being that most small businesses cannot afford a full-time system administrator to administer a non-Windows network. It is nice to now have some numbers to support my argument. Keep in mind, I do not state one way or the other which OS is more secure, reliable, or robust. I only mention this for the simple fact that running a Windows based network, over the long run, will almost always be more affordable.

Compete solely on price, no thanks

First off, sniff the TCP/UDP traffic

After launching TCP Viewer and letting it do its thing for a few seconds, I noticed that there was a group of three or so applications connecting and disconnecting in sequence, port scanning out my machine to my router on destination port 5678. Lo and behold, it ended up being the svchost.exe application. Not just one or two ports, but scanning tens if not hundreds if left to do its thing.

Next, Find the Application and Kill It

I launched Process Explorer to try to figure out if svchost.exe was truly the offending thread. I then isolated the application with the same PID as the one reported in TCP Viewer (in my case 1324). Yep, svchost.exe. Right-click | Kill Application. Bye-bye. No more solid blinking lights across my gigabit Ethernet connection!

Conclusion

Now you ask, what service or application would be sending and receiving such a high rate of packets (ultimately crashing my router due to the amount of hits it was getting)? Well, it turns out that the UPnP services (which I had assumed I had disabled) were for some reason hanging on the requests to my router. All requests were headed to the router’s internal interface (10.0.0.1) on port 5678. From what I can tell, the router was either dropping the packets or not responding properly so the SSDP Discover Service was scanning out ports to try to “do its thing”.

Solution

Launch the local service manager, stop, and then finally DISABLE the following services:

• Universal Plug and Play Device Host
• SSDP Discovery Service

I do not plan on going in to detail on what these services do, but suffice it to say, they are unnecessary and in this case, a pain in the behind. There are a bunch of other article on this topic, but there did not appear to be one detailing this exact scenario, so hopefully this helps someone else from having to spend hours troubleshooting.

Happy computing