2009-02-02

Windows update error 0x8024402c

Well, like everybody else, this error has been driving me nuts. Plus it manifested itself in such a weird way I couldn't believe.

I already had that issue last week on a brand new Vista 64 install, and somehow, it appeared that resetting the LAN paramaters to default did the trick, and after a short hour struggle, I was able to apply the updates.

I was not so lucky with that old laptop of mine running XP, which was badly in need of critical updates, but that couldn't seem to download them. Well, actually, at first, it started to download the updates alright (got through about 8-10 of them) but then it failed! Tried every hint from the link above. None worked...

This is a job for... Is it a bird? Is it a plane? No, it's Wireshark!
OK, so Wireshark reveals that, despite everything Microsoft wants to make you believe, the issue is really with au.download.windowsupdate.com not being resolved. Of course, one has to wonder why an Irish based Windows has to pick up its updates from Australia, but hey, that's Microsoft for you.
Indeed, a few tests from the commandline show that au.download.microsoft.com is indeed not resolvable. OK, let's see what the DSL router (which can also do basic diagnostic checks) has to say about it... WTF? The DSL router sees no issue there:
Resolving au.download.windowsupdate.com ... 65.54.84.196
Reply from 65.54.84.196
Reply from 65.54.84.196
Reply from 65.54.84.196
Ping Host Successful
And this is where it gets really weird, as it appears that my Linux machines also cannot resolve the host... while the router can?!?! No way!

OK, by now I need to apply these updates badly, and therefore, yes, you got it, we're gonna edit the systems32/drivers/etc/hosts file of course and get done with it.
So here goes:
65.54.84.196 au.download.windowsupdate.com
and try downloading the updates again (with Wireshark still running in the background).
What the hell?!? No difference - We still get DNS requests for au.download.windowsupdate.com that don't seem to resolve. But how on earth is that possible with a triple checked hosts file?

The answer of course is that Microsoft deliberately screwed up their DNS resolution so that their update servers can NOT be overridden by the hosts file. Yeah, I can understand the logic of it, but how about relying on https and certificates instead, to check that the server is legit, rather than breaking down DNS. Talk about another half assed approach to security...

Well, that will teach me to try to work around a problem rather than solve it, because with no DNS override, I'm back to square one. And I'm not really willing to install my own DNS server just to work around this problem either.

Now, further use of nslookup with various Irish DNS seem to indicate that they ALL have the same issue??? Is someone out there to get me or what, because none of this makes any sense!

At this stage, instead of banging your head against the wall, you gotta try to apply logic. If all of the Irish DNSs were failing to resolve the Windows Update servers, you'd probably get people armed with pitchforks on the streets within minutes, so I must be doing something wrong.
A quick change of NS lookup tool actually confirms it (DON'T USE NSLOOKUP ANY MORE STUPID!). dig quickly shows that it's only the DNS that I was using (Eircom's 159.134.237.6 & 159.134.248.17 - never trust the incumbant!) can't resolve the bloody server, while my own ISP's DNS can.

A quick change of DNS servers on the DSL router, a full reboot (ipconfig /release + /renew would probably have done the trick, but with M$, you can never be too sure), and Windows Update is happy again.

Good thing I didn't have anything better to do this morning. And just to sum up the lessons for today:
- 0x8024402c happens if Windows cannot resolve the IP of the download servers
- Windows update CAN switch download servers on the fly while downloading (!)
- Use Wireshark to find out which download servers Windows Update is trying to use
- Windows name resolution is screwed so that it will always try to use DNS and not the hosts file for the download servers
- Don't trust what your DSL router tells you about Name Resolution - it might not be using the configured DNS servers!
- DON'T USE NSLOOKUP ANY MORE! Use dig instead.
- Screw Eircom!

No comments:

Post a Comment

Note: only a member of this blog may post a comment.