Article ID: 926940 - View products that this article applies to.
This article has been archived. It is offered "as is" and will no longer be updated.
Microsoft SQL Server 2000 Service Pack 4 (SP4) stops responding (hangs) after you close a SQL Server connection. This problem occurs on a computer that is running Microsoft Windows Server 2003 Service Pack 1 (SP1). Additionally, SQL Server does not accept any connection requests. When this problem occurs, the following error message may be logged in the SQL Server error log:
Date Time server Error: 17883, Severity: 1, State: 0
Date Time server Process 2:0 (b58) UMS Context 0x21D17050 appears to be non-yielding on Scheduler 1.
This problem occurs because a Dbnetlib.dll file transfers an invalid socket handle to the closesocket function when you close a SQL Server connection. This invalid socket handle blocks TCP/IP activity. Therefore, SQL Server stops responding and does not accept any connection requests.
Service pack informationTo resolve this problem, obtain the latest service pack for Windows Server 2003. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/889100/ )How to obtain the latest service pack for Windows Server 2003
Software update informationThis update has been superseded by another update. For more information about the replacement update, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/931303/ )SQL Server 2000 Service Pack 4 stops responding after you close a SQL Server connection on a computer that is running Windows Server 2003 Service Pack 1
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. This problem was first corrected in Windows Server 2003 Service Pack 2.
To reproduce this problem in SQL Server 2000 SP4, load the Dbnetlib.dll file into the SQL Server process space.
Call stack informationThe blocking thread may have a call stack that resembles the following:
The threads that are blocked when they are waiting for the critical section may have a call stack that resembles the following:
mswsock!SockImportHandle+0x1f0 mswsock!SockFindAndReferenceSocket+0x140 mswsock!WSPGetSockOpt+0xe0 ws2_32!DSOCKET::FindIFSSocket+0x210 ws2_32!DSOCKET::GetCountedDSocketFromSocket+0x70 ws2_32!closesocket+0xc0 dbnetlib!CloseEnumServers+0x60 sqlsrv32!BrowseNetworkEx+0x2d0 sqlsrv32!SQLBrowseConnectW+0xd50 odbc32!SQLBrowseConnectW+0xe30 odbc32!SQLBrowseConnect+0x560 w95scm!EnumServer+0x540 w95scm!IsSQLSvrClustered+0x210 w95scm!SQLSCMGetServiceStateNT+0xc90 w95scm!SQLSCMGetServiceStateW+0x190 xpstar!xp_servicecontrol+0x16c0 sqlservr!FCallRpcDLL+0xb10 sqlservr!CXProc::Execute+0x3b0 sqlservr!CSQLSource::Execute+0xb80 sqlservr!CStmtExec::XretLocalExec+0x270
ntdll!RtlpWaitOnCriticalSection+0x430 ntdll!RtlEnterCriticalSection+0x1f0 mswsock!SockAcquireRwLockShared+0x80 mswsock!SockCloseSocket+0x6f0 mswsock!WSPCloseSocket+0x100 ws2_32!closesocket+0x110 SSnetlib!ConnectionClose+0x160 sqlservr!close_server_side+0x100 sqlservr!release_srvproc+0x110 sqlservr!process_commands+0xc10 sqlservr!ProcessWorkRequests+0xa40 sqlservr!ThreadStartRoutine+0x150 msvcrt!_threadstart+0x210 kernel32!BaseThreadStart+0xc0