SMS: Remote Control of Windows 95 and Windows 98 Clients Is Unsuccessful with Winsock 2.0, Using IP (193269)
The information in this article applies to:
- Microsoft Systems Management Server 1.2
This article was previously published under Q193269 SYMPTOMS
When you attempt to remotely control a Microsoft Windows 95 or Microsoft Windows 98 client using Winsock2 and having Internet Protocol (IP) as the default protocol, Remote Control is unsuccessful. The client may experience a general protection (GP) fault in Idisp16.dll.
CAUSE
In versions earlier than Winsock 2.0, WUSER (actually Idisp16.dll) is able
to call Winsock from the 16-bit display driver code and the packets are
sent without executing any 32-bit code. In Winsock 2.0, the work is done in
32-bit code. If the display driver wants to send a packet, its Winsock call
is called through a thunk to the 32-bit code. Calling through the thunk
releases the "Win16 Mutex," which enables multiple threads to enter the Graphics Device Interface (GDI) and USER at the same time. The results can
include problems at the viewer (scrambled screens or program halts), and
even screen corruption on the client.
Windows 95 or Windows 98 with Winsock 1.1 (that is, the release version of Windows 95, or Windows 98 with Winsock 2.0 support removed) has the following architecture as interpreted by 16-bit applications and DLLs:
16-bit application or DLL
|
Winsock.dll (16-bit winsock interface, pure 16-bit code)
| user
------------------------
| kernel
Wsock.vxd
In Windows 95 or Windows 98 with Winsock 2.0 (with only Microsoft TCP/IP
provider installed, the shipping configuration) it has changed to the following:
16-bit application or DLL
|
Winsock.dll (16-bit winsock interface, pure 16-bit code)
|
Ws2thl.dll (thunking layer between 16-bit and 32-bit code)
|
Ws2_32.dll (Winsock2 broker library, 32-bit code)
|
Msafd.dll (TCP/IP service provider, 32-bit code)
| user
---------------------------
| kernel
Wsock2.vxd
Wuser.exe (Idisp16.dll) is a 16-bit DLL being called inside a 32-bit
process. It makes 16-bit Winsock calls and relies on the Winsock 1.1
behavior of going straight to kernel without thunking into 32-bit code.
With Winsock 2.0, when Winsock.dll thunks to 32-bit code, the 32-bit
scheduler can (and very often does) preempt a currently executing thread
and then executes another 32-bit thread in the same or different 32-bit
process. When this occurs, the 16-bit DLL code can get reentered and halt
the program, because a 16-bit environment assumes that no reentrancy will
occur when it makes a Winsock call.
RESOLUTIONA supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next Systems Management Server service pack that contains this hotfix. To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site: NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
The English version of this fix should have the following file attributes or later:
Date Time Version Size File name Platform
-------------------------------------------------------------------
4/14/99 6:24pm 202,476 Cli_Dos.exe x86
12/18/98 1:12am 12,288 CoExst9x.dll x86
4/22/99 5:05pm 98,777 IDisp9x.dll x86
4/22/99 5:05pm 2.00.1239.0029 8,464 IDispThk.dll x86
4/22/99 5:05pm 2.00.1239.0029 46,512 Imp9x.dll x86
12/18/98 1:12am 75,968 Loc16VC0.dll x86
4/22/99 5:05pm 2.00.1239.0014 84,112 MultPr9x.dll x86
4/22/99 5:05pm 2.00.1239.0029 38,320 Queue9x.dll x86
4/22/99 1:22pm 8,024 VUser9x.vxd x86
4/22/99 5:05pm 2.00.1239.0029 27,424 WouDat9x.dll x86
4/22/99 1:21pm 2.00.1239.0029 287,744 Wuser9x.exe x86
4/28/99 1:50pm 3,525 CL_W95.mod x86
4/22/99 5:06pm 2.00.1239.0029 36,800 WUMsg9x.dll x86
4/22/99 5:05pm 2.00.1239.0029 4,720 _IDisp9x.dll x86
4/22/99 5:05pm 2.00.1239.0029 91,584 _Wuser9x.dll x86
4/27/99 5:54pm 2,451 System.ma_
5/3/99 3:01pm 935,197 Hf33216.exe
NOTE: Due to file dependencies, the most recent hotfix or feature that contains the above files may also contain additional files. WORKAROUND
To work around this problem, use either NetBIOS or IPX as the default
protocol for Systems Management Server Remote Control.
STATUS
Microsoft has confirmed this to be a problem in Systems Management Server version 1.2.
Modification Type: | Major | Last Reviewed: | 4/7/2006 |
---|
Keywords: | kbQFE KBHotfixServer kbBug kbfix kbRemoteProg kbtshoot KB193269 |
---|
|