Flour Power

It seems that the quest to get Windows Live Messenger to function properly at work has a new chapter. After fixing error 8100030F, his friend 80048820 showed up and got taken care of. But this is apparently a persistent foe, and yesterday decided to show his face again. Since the previous solution couldn’t be used again, I used the built-in troubleshoot option to try and figure out the problem:

So the problem is caused by some inability to connect because the program can’t use the required ports. Since I’m behind the company firewall, nothing could be done about that, so I had to do a few searches and a few minutes later, I did find a way to solve the problem. Open Internet Explorer, go to Tools –> Internet Options, choose the Connections tab, click the LAN settings button and tick the Automatically detect settings checkbox. That got it working again. Now let’s see for how long.

In the last few days I started getting this error when trying to login to Windows Live Messenger:

Which is a bit odd, since I didn't do any recent changes that could have caused it.

A quick Google search returns pages saying that this is quite a generic problem and there are a lot of possible causes for it. Those include incorrect system date and time definitions, corrupted security libraries, incorrect proxy settings, access blocked by firewall, etc. In my specific case, none of these were the problem: firewall-blocking and incorrect proxy settings are easy to check by asking a coworker to try it, checking the system clock is even easier, and I didn't even try to fix the security libraries as I thought it highly unlikely for the issue to be there.

Digging a bit further I found this page with a similar set of possible solutions and one that caught my eye: DNS cache flushing. In short, DNS (Domain Name Service) is a component responsible for translating domain names meaningful to humans into the numerical identifiers associated with networking equipment. The rationale behind this solution was that domain names that have already been translated into "machine-speak" are kept in a cache, avoiding the need to query the DNS server all the time. So if the underlying address changes, the cache has to be updated so that it contains the correct address. This usually happens automatically and no changes have to be done by the user, but "flushing the cache" is a way to force it. This reminded me of error 8100030F.

The solution to error 8100030F was adding the following line to the hosts file:

65.54.239.80 messenger.hotmail.com

What this does is bypassing any DNS service and using the specified IP address all the time. I figured that the address had changed and I was still using the old one, with no way for Windows Live Messenger to get to the new one because I was bypassing the DNS service. All it took was removing that line and everything is back to normal now.

The hosts file can be found at C:\windows\system32\drivers\etc\.

When trying to run the newest version of Windows Live Messenger (at the time of writing this post, that's version 2009, build 14) I was getting this error:

We can't sign you in to Windows Live Messenger

Signing in to Windows Live Messenger failed because the authentication service is not compatible with this version of the program.

Error code: 8100030f

All it takes to solve it is browsing to C:\windows\system32\drivers\etc\, opening the file called hosts, and adding the following line after the last entry:

65.54.239.80 messenger.hotmail.com

I'm using Windows Vista but this fix has been reported to work on XP as well.