Tasty
Steve has been throwing chairs around again...
Users across the globe are reporting that they're unable to log-in to Microsoft's Live Messenger instant messaging service. According to Reg readers in the UK and users worldwide posting to Twitter and Microsoft's help forums, attempts to log-in have been repeatedly met with the error code 85AE001D. According to some, the …
The MSN Messenger service has been getting worse and worse lately with messages constantly failing to be delivered. File transfers take a month of Sundays, a friend and I have been trialling GoogleTalk, much faster and reliable, but MSN is where my contacts are :(
Now here's the really funny part (MS bashers, tool up):
Pidgin can sign in fine (on Linux, I'm assuming Windows too), as can HiMSN on Android, the official MSN Messenger client does indeed whine about contact list not being available.
Time to abandon more MS software?
I can just see the source code :-
#define ERR_FATAL_EXCEPTION 0x1
#define ERR_CRASH 0x2
.
.
.
#define ERR_NO_CONTACTS 0x85AE001D
How many errors have they thought of ????
#define ERR_KETTLE_NOT_BOILED 0xFFBCFDEA
#define ERR_KETTLE_EMPTY 0xFFBCFDEB
.
.
.
#define ERR_NO_POWER_TO_THIS_COMPUTER WTF ???
In reality, I would say this is something daft, such as a buffer overrun trashing the real error code returned, hence the enormous 0x value. Looking at the 8 digit length of the 0x value, it fits with being an int (4 bytes on most systems).
My 2p for what it's worth !
I haven't been able to log into msn messenger for about 7 months now... I always get a similar, if not the same, error... had to fallback to pidgin, been using it since in my windows machine, while using adium in my mac machine. Guess MS is just getting worse at supporting their "live" products each day...
While I agree with the sentiment, only the low 16 bits are used for the error code. The high 16 bits are used to identify the source and provide other classification info:
http://msdn.microsoft.com/en-us/library/ms819773.aspx
So if it's a genuine windows error, it's code 0x1D (29).
At least it would be getting somewhere. I'm stuck with something that appears to be port related and the corp firewall, it say no.
I'm guessing here, but my money's on the voice 'n video side. Looking at what this wants, it needs a right shedload of open ports. I reckon that the older versions (8.5 and lower) just used to accept that they were closed, disable the cruft and get on with the real job at hand that you installed the sodding thing for in the first place. The new versions sit in a corner and sulk. Can't for the life of me figure out why they'd make this change though, assuming that I'm on the right track (although sheer blind stupidity's got to be a prime suspect).