[Bug 20188] MSN Messenger 7.5 hangs while signing in

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=20188





--- Comment #3 from Juan Lang <juan_lang at yahoo.com>  2009-09-29 12:58:34 ---
It's hard to say whether this is a wininet bug with the
INTERNET_DIAGNOSTIC_SOCKET_INFO stub like I first thought, or something else.

Here's a snippet from your +winsock log:
fixme:wininet:HTTPREQ_QueryOption INTERNET_DIAGNOSTIC_SOCKET_INFO stub
trace:winsock:WS_getpeername socket: 0000, ptr 0x353c6a0, len 00000010
trace:winsock:WS_getsockname socket: 0000, ptr 0x353c6e8, len       10

That is, the app is querying for the socket handle used with a wininet
connection with INTERNET_DIAGNOSTIC_SOCKET_INFO.  It's then quaring for the
socket's local and remote names, via getpeername and getsockname.  Obviously
those fail, since the socket handle is 0.  (It isn't really, but wininet
incorrectly doesn't use winsock, so it lies and returns 0 as the socket
handle.)

But the app doesn't just die there:  there's still some data transferred using
winsock after this.  So, while this is clearly a problem, it may not be the
problem that's causing the hang.

Here's another suspicious bit in the log:
trace:winsock:WS_bind socket 031c, ptr 0x32f9c4 { family AF_INET, address
192.168.2.4, port 9 }, length 16
warn:winsock:WS_bind     failure - errno = 13
warn:winsock:wsaErrno errno 13, (Permiso denegado).
trace:winsock:WS_closesocket socket 031c
err:ole:CoGetClassObject class {b9c2e9c4-68c1-4d42-a7a1-e76a26982ad6} not
registered
err:ole:CoGetClassObject no class object {b9c2e9c4-68c1-4d42-a7a1-e76a26982ad6}
could be created for context 0x1
err:ole:CoGetClassObject class {ae1e00aa-3fd5-403c-8a27-2bbdc30cd0e1} not
registered
err:ole:CoGetClassObject no class object {ae1e00aa-3fd5-403c-8a27-2bbdc30cd0e1}
could be created for context 0x1

That is, the app is attempting to bind to a private address and a low port
number.

Binding to a low port number is a problem with Unix in general, as you either
need to be root to do that, or need the capability to bind to a low port
number.

Binding to a private address is likely to be a problem, if it's expecting the
server to connect to it at that address.  The COM objects it tries to load
immediately after that, b9c2e9c4-68c1-4d42-a7a1-e76a26982ad6 and
ae1e00aa-3fd5-403c-8a27-2bbdc30cd0e1, are attempts to work around the private
address, I imagine.  The first is apparently the DirectPlay NAT Helper UPnP
Object, and the second is IUPnPNAT, part of hnetcfg.dll.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.