Been trying all day to fix it. Clearing the relevant appdata folders, the registry keys. Still 8100030d, and I’m not using any usually implicated security solutions.
Temporarily disabling Kaspersky results in 80072745 instead.
I and several friends of me all have the same problem. However, disabling KIS gives the same error message as before (8100030d).
I have found a temporary solution, and that is to restart the computer; then it is possible to sign in again (until the problem occurs next time…)
I currently “upgraded” to 2011 which is able to sign in.
It was 2009 that was having the 8100030d problem, and that occurred just a couple of days ago after waking the machine and re-launching WLM. My other computer also has the same problem when it hasn’t been used for a while, which seems like too much of a coincidence.
I thought restarting might’ve made a difference and it was one of the things I tried first, but that didn’t work.
I’d like to try and find a solution to get 2009 to sign in again though.
Thanks yuka for advice; I can confirm that upgrading from 2009 to 2011 seems to solve the problem on all computers my friends and I have tested.
There was a change this past week which would have forced HTTP mode. 2011/2012 work a little differently in this regard, but Reviver 2.3.5 does try and work around this problem a bit for 2008 and 2009 clients by changing the initial server you connect to. If either of you are interested in going back to 2009, please try the latest version of Reviver and see if it makes a difference.
Also if you have any interest and the problem is still there, a connection log of the 2009 failed connection attempt would be helpful.
1 Like
Just retried with 2009 from the Reviver. No longer reports 8100030d, but instead only 80072745.
Connection log will be sent privately.
Edit: after a computer restart I’m getting 8100030d again.
Got it, thanks. Based on the log you sent, the error codes may be different but in both cases it’s just not able to connect. The 0x80072745 is connection aborted, the 8100030d is not 100% known but is probably a fault with encryption/certificates.
The real mystery is what it’s connecting to. In every instance, according to the log, Messenger is being told by the initial Messenger server to connect to 127.0.0.1 (that as you probably know, the local IP of your own PC). Since you aren’t a Messenger server, the connection is rejected and the sign in fails. You’ll see this in the log here:
CMNSConnection::CheckForNetMsgs@0021B540: Recv >XFR 0 NS 127.0.0.1:51723 G D<
The 51723 part is the port and is different each time (which also is unusual). The XFR is the Messenger protocol command to transfer you to another notification server (NS). However, with the current trickery in Reviver 2.3.5, it shouldn’t even be sending an XFR command.
The newer protocol used in 2011/2012 protocol won’t do this, which is why the problem doesn’t exist there.
There’s two possibilities I can think of right now:
- There’s a server problem with your account which is the causing the server to send the wrong commands, you might try creating a new Hotmail/Microsoft account to test and see if the problem happens in a new account too.
- Security/monitoring software is messing around with the Messenger connection. Over Messenger’s lifetime, it’s been a well known feature of internet security products to tell the Messenger client what to do and sending the XFR to your own PC on a random port sounds like a great trick to monitor/interfere with your contact list and conversations. I think this is the most likely scenario and even if you’ve disabled the software, parts of it might still be trying to interfere, so I’d encourage you to temporarily uninstall anything that you think might be doing this.
In the case of the latter, I can’t really say whether or not this has broken due to the changes made this week (likely), or some other problem.
Hopefully this helps.
1 Like
I have installed 2009 again and I can confirm that the latest reviver is working without problems. Thanks.
I got connected via 2009 today, it seems.
I’m uncertain if it’s related to it, but I tried adding a messenger server to the hosts file as outlined by dx. However my connection logs indicate an external IP that is not the IP I added to the hosts file.
The XFR command is still being used, too.
Changing by the hosts file won’t work in 2.3.5 revived clients because it’s redirected to a host on that list already that has been checked and tested to work. So no need to worry there.
Is the XFR command still pointing to yourself, 127.0.0.1? If so, you can use a tool like Process Monitor to find out what process responded on that port to identify the culprit.
To do so, have Messenger clear your log file, then shut down Messenger and then open Process Monitor. Uncheck the File, Registry, Process/Thread activity buttons at the top, leaving only Networking. Here’s what that part of the toolbar should look like afterwards:
Next, if it’s not already started capturing and bringing in results, press Ctrl-E to start the capture. Then press Ctrl-X to clear the Process Monitor screen and then proceed to sign into Messenger.
That probably should be enough, you can go back to Process Monitor and press Ctrl-E to stop capturing. Head over to your MsnMsgr log, look in the file for the XFR 127.0.0.1 entries and make a note of the port number in each.
Then go back to Process Monitor, choose the Edit menu, then Find… and search for :portnumber
Replace portnumber with one of the entries you just noted in your log file. So for example, in the one (XFR 0 NS 127.0.0.1:51723) I noted previously, you would search for :51723.
(you may need to do Up or Down directions, depending on where you are in the capture).
This should hopefully bring you to where this is happening. Specifically, you are looking or a process that isn’t msnmsgr.exe, with the operation being TCP Receive. As an example, I have a local SSH server on my computer and if I connect to it via 127.0.0.1, Process Monitor will show this:
The BvSshServer.exe would be the equivalent of what you’re looking for, as it’s TCP Receive on the SSH port. Underneath you’ll see Telnet.exe is the client (TCP Send), and would be the equivalent of msnmsgr.exe in this case. Prower is the name of my computer, you’ll see your computer name on your capture as well.
You can double-click an entry, click the Process tab and find out all the important details that hopefully should help you identify what’s listening on that port. Hopefully it won’t be disguised by another process, if it is, you might get hints by looking at the Stack when you double-click for details.
If you’re having trouble, do File, Save, and save/send the PML file and I’d be happy to have a look.
1 Like
After getting the sign in errors I’ve been okay for a few days, then an intermittent 8100030d (and again, right now.). Tried tracing connections with Process Monitor as you’ve suggested, the latest XFR 0 NS points to 49641 - but Process Monitor did not capture anything making a TCP Receive on that port, only TCP Connect/Accept//Disconnect.
Following though it seems that 49641 goes to another port which in turn goes to nfsd-status which is under Kaspersky.
It starts with Kaspersky (51652) then to messenger discovery (extension app), which is 49641 (the XFR port), then to MSN itself which is 51651. Then from there it goes to nfsd-status which in turn shows up as Kaspersky.
These exchanges seem to happen a few times.
Edit: tried removing MD. Seems to have solved the problem for now.
Thanks for the all the effort in figuring that out yuka. I had already installed the latest Kaspersky, but installing Messenger Discovery is what started the same XFR commands in the log, but only sometimes - it doesn’t always seem to happen consistently for me. In fact I’ve only seen it twice in the dozen or so login/use attempts.
I know earlier versions of MD did use a local proxy to work, I’m using 3.0.150 to test here, what version were you using?
I was in the Messenger Plus! camp, so I admit my initial knowledge of how MD worked is low without spending significant time figuring it out. Regardless, I wouldn’t really recommend anyone use it when there’s other options for most of its functions.
1 Like
I’m a long time user of Plus! but when I was introduced to Discovery I decided to make use of both, for a very full-featured Messenger. Later versions of Discovery are annoyingly problematic in their own way, and I was using a very old edition - 2.1.79. If you’d like to test it I still have the installer.
I’m still using Plus!, but I guess I can make do without Discovery’s features.
If you’re still game, I wouldn’t mind that installer actually. If you need a place to upload it to, just let me know.
1 Like
Sorry about the super late response. I forgot about it somehow.
Here’s a link to MD 2.1.79.
On the other hand I’ve gotten 80072efd again, so I’m going to wait a little longer.