This Windows error code, 10106, has the symbolic name WSAEPROVIDERFAILEDINIT (see winsock2.h). We have seen these sorts of mysterious Windows socket failures before, and they have typically been the result of certain Windows environment variables not being set property when the test is run. I don't remember the details offhand, but from the following JDC forum thread:
It appears that the "SystemRoot" environment variable needs to be set to the Windows installation directory (like "C:\WINDOWS"). This variable is normally set that way, of course, but some execution environments (like test harnesses) can cause it to be unintentionally removed when executing subprocesses.
The fact that the same exception occurs when attempting a network operation through a different (non-RMI) library (see 6256847)-- not to mention the nature of the exception-- would seem to suggest that there is not an RMI bug here.
Did all other RMI regression tests pass in this same environment?
###@###.### 2005-04-27 17:22:24 GMT
It's the only rmi case we run for i18n regression.
###@###.### 2005-04-27 17:50:05 GMT
Submitter has confirmed that the failure was due to an issue with environment variable settings for test execution on the Windows XP Home machine:
> Good news, I check the script running env which is MKS, using setenv found
> the varible is set as SYSTEMROOT, so set a new varible $SystemRoot and run
> the script again, now both cases are passed.
> The cause is due to the varible set wrongly as SYSTEMROOT on winXP home,
> Where on other platform, like winXP pro and etc, the varible set correctly
> on MKS as SystemRoot.
###@###.### 2005-05-03 01:03:25 GMT