Addendum:

VIX seems not to be the Problem:

Commandline returns with error after a while, but GUI still hangs "at the same place", after command finished.

On the other hand:

Looks fine to me.

Regards, Sarge

Unfortunately the problem isn't solved by adjusting the Limit of inactive IP connections to higher than 10. (Although this obviously did help).

Yesterday the problem reoccurred. I decided not to care about the pixelmap on my desktop, that ought to become a window some time (and not kill the hanging player process), and - about 30 minutes later - the player application window was there and usable. The behavior is reproducable. once the window is fully up, there seem to be no problems anymore

all vmware processes/services seem to run normal before the start of the player (and also after starting it). I see nothing special in the Event logs about the time of the start. sometimes an event from source "ufad-ws60" (information) in the application log, which says, that the respective service is started. Once i saw a"VMnetDHCP, 1,dispatch: Timeout waiting for input data" in the system log during the freeze period. But this seems to be an effect, not the cause.

since I didn't install anything on the host after the player and the VIX API, I suppose there might be some group policy interfering, however.
Does the Player 3.0 modify the GINA-DLL, changing it to some vmgina.dll, as the vmware server 2.0 does? If so, it was changed back automatically by an Utimaco encryption software.
Maybe the VMware authorization conflicts / is incompatible with the GINA-DLL brough/installed by the Utimaco Software.

Are there any logs, written by the player, that might give me some clue?

Best regards, Sarge

Hi continuum,

your hint (disabling both checkboxes: 1. player update and 2. tools update) led to a startup time of 15 to 20 min (vs about 30 min before) but led me into the right direction.
(There must be some other connection tries than those mentioned above)

The problem is with dns lookup on the host in the lan environment (host to lan1 via firewall to lan2 via firewall/proxy to internet), which takes "freezingly" long, if an (some) unknown adress(es) is (are) queried. If browsers aren't configured correctly they show a similar phenomenon (dns-lookup blocking application).

(Re-)testing on another network site (direct connection to the internet) everything works fine. Same if the host isn't connected to anything at all.
This leads to a quite simple workaround:
1. Unplug network cable before starting the VMware Player.
2. A frozen Player GUi can be woken up by plugging the network cable.

Even if the root cause of the problem is (I bet) WinXP name resolution, it's very annoying, that the entire application is affected (frozen) by this presumed windows bug. The internet connections of vm player should be non blocking!

Anyway, thanx a lot.

Best regards, Sarge

Hi,

here you go.

starting the Player today, it worked fine again.
It seems it likes cloudy Monday noons! Or 3rd-floor north windows better than 2nd-floor south?
No idea what has changed over the last 1,5 weeks! (Host is online)

However, i zipped the entire direcory.

the most current logfile (pid=3884) is the running instance. there's quite a history of logfiles resulting from the player was/had to be killed.
The DownloadJobMgr is (or thinks to be) DISCONNECTED, this at least fits into the picture. The host is in fact online and connected to the internet in the manner described above.

Hope you can find something.

Best regards,
Sarge