Wednesday, 7 October 2009

Of ActiveX, and service packs, and firewalls, and things ...

I have recently had cause to reinstall a Windows XP Pro machine after a serious virus infection. Not a big job, really. I'm sure I could go on about how installing $linux_distribution only takes 20 minutes, but all in I reckon a full XP Pro install, including drivers, should only take about an hour.

Or so I thought. What actually happened was a comedy of errors lasting almost 20 hours filled with grief, annoyance, frustration and a large amount of tea. The basic installation worked fine, the drivers all went on perfectly, and even the PCI wireless card was no problem. All was looking well, until I tried to update to the latest service pack.

Upon launching the Windows Update site, I was presented with the usual "checking version" message that precedes every scan for updates. So far so good, but a couple of minutes later it all went badly wrong. Rather than the nice list of service packs and hotfixes I was expecting, all I got was an error message: 0x8DDD0004. Nice and cryptic.

A quick google for this error indicates that there are quite a few KB articles about it. The problems that cause it range from a wrongly installed service to bad registry entries, missing ActiveX controls to invalid root CA certificates. I tried them all. Twice. I reinstalled the entire machine. Twice. I manually upgraded to the next service pack through wails and gnashing of teeth, and I even got hold of a streamlined install CD with SP3 already on it to see if it made an ounce of difference.

Nothing. Still the same error, 0x8DDD0004.

So I start digging on my own. Clearly the knowledge base articles cover a great many causes for this problem, but not the one I am seeing. During this digging, I discovered a nasty little problem that had been plaguing me. One of the DIMMs was bad, so half the memory didn't work. Removing that actually sped up the machine and made the rather irritating lock-ups go away. Having sorted that, looking at the Windows Update log gave me a different error code, related to it failing to download a file named wuredir.cab. Another avenue of investigation!

Once again deep in the Microsoft knowledge base, I found another five articles explaining the new error code. Some of the fixes were the same as previous ones I'd found, and some were new. Again, I tried them all to no avail. At this point, I was fed up, and it occurred to me to check that the Windows Update service was working at all. I couldn't find any service affecting issues listed on the MS KnowledgeBase, but I did have a second Windows XP virtual machine that had previous installed updates without a hitch. I gave it at try.

Aha! Exactly the same error. So the problem, it turns out, wasn't with the other machine. Well, apart from the bad memory module and the multitude of viruses. Still, the problem was reproducible. An excellent start in any debugging exercise. I also now had the full URL of the file that was failing to download, so out of interest I tried downloading it directly from my browser on a variety of other machines. They all failed, Windows, Linux and Mac OS alike, in exactly the same way. Headers received, timeout waiting for content.

It then occurred to me to check if the URL was the problem, or if there were other network conditions causing the problem to manifest only for me. I had a poke around, got on another machine not connected to my home internet connection, and tried to access the URL. It worked. A good thing, I suppose, because it means that once I figure the problem, the service is up. A bad thing because it means that the problem is still mine to fix.

Armed with the knowledge that the service was at least responding, I figured the problem had to be somewhere between my router and Microsoft's server. Not the greatest leap of intuition, admittedly, but I was very tired by this point and not firing on all, if any, cylinders. I checked the router log.
CP Packet - Source:1xx.1xx.1xx.2xx,60349 Destination:2xx.4xx.1xx.9xx,80 - [Firewall Log-Filter ActiveX]
I looked at it, then looked at it again.
CP Packet - Source:1xx.1xx.1xx.2xx,60349 Destination:2xx.4xx.1xx.9xx,80 - [Firewall Log-Filter ActiveX]

How and why was my router filtering ActiveX? I checked the firewall settings, and sure enough, there it was. Filter ActiveX, ticked and dropping packets like nobody's business. I unchecked it, saved the configuration, and tried the URL again. It worked like a charm. I sank back in my seat, closed my eyes and muttered a number of exotic curses under my breath.

So the root of this entire issue was that my router was dropping any and all packets deemed to have a payload of an ActiveX control. I don't remember ever turning that on. Why would I? I very rarely use Windows machines on my network, and when I do I'm likely to just be installing them for someone else. Having working ActiveX would be something of a necessity. In fact, my Windows VM ran successful updates only a couple of months ago.

The only thing I can think is that either:
  1. I was reconfiguring my firewall while drunk, or
  2. Something had happened to the router to make it turn that option on
A couple of weeks ago, the router did get overheated after being put in close proximity to an Iomega NAS (which you may remember from previous rantings, and is thankfully now deceased). After that, I had to fiddle with some settings to get my ADSL and WiFi connections working again. I can only assume that, either by accident or design, this fritzing of the router caused the firewall settings to be modified. As far as I know the ActiveX blocker isn't on by default, so it must have been switched on post-install.

So if you're having problems with Windows Update, and nobody else can help, and if you can find it, maybe you will find that the fault has nothing to do with Windows after all. Granted, it usually does, but on this one rare occassion, it was something else entirely.

Of course, if Microsoft didn't use ActiveX to push updates at all, this problem wouldn't have existed. ActiveX is a known security risk. So well known that router manufacturers put special firewall rules into their consumer products specifically to block it. In the end, this whole fisaco essentially boiled down to an overzealous firewall and a lot of wasted time.

Where does the blame lie? Nowhere really. Microsoft's update service was working properly the whole time, and the router (after being subject to some hardware abuse) was just doing what it thought I had told it to do. And I, having never specifically configured content filtering in the firewall, went through all this to find that toggling a single checkbox fixed the whole issue.

Computers, eh? Can't work with 'em, can't work without 'em.

No comments:

Post a Comment