October 3, 2003 at 7:08 am
Has anyone got any further info on Error 17883? (I have already read Q319892)
I got the following two entries in the log, and no mini-dump file.
Process 0:0 (5fc) UMS Context 0x121D58D8 appears to be non-yielding on Scheduler 0.
Error: 17883, Severity: 1, State: 0
Steven
October 3, 2003 at 10:59 am
Hi Steven,
What kind of information are you looking for? As the article explains, the message is new to service pack 3a for SQL Server 2000 to help troubleshoot issues such as server hang. However the message itself is not the cause of the problem.
In order to troubleshoot, it will be necessary to review errorlogs, mini-dumps in the \log folder (*.mdmp) if you have build 780 or later.
The only known issue is documented in Q810885. I would suggest calling Microsoft PSS if this is a problem for you.
Yih-Yoon Lee
lee@yihyoon.com
October 3, 2003 at 2:09 pm
This was the first time I had seen this error, hence I was just after any extra info on it. As it was a first time, and due to the lack of logs I can't really do a lot more.
The cause could have been a database data file extending (as per the related article mentioned in the Q article). (One did extent this morning)
All I got the was two lines in the log file.
The server is running SP3a + MS03-031 hence is build 818, but I didn't get the mini log mentioned in Q319892.
After it happened the server itself responded to a ping, but that was it. No login prompt on the console, and sql was not listening on tcp-ip or named pipes. Hence the server was power cycled 10 mins later so I could regain control.
Thanks anyway.
Steven
October 3, 2003 at 10:02 pm
It happens to one of my SQL Server when scheduled job tries to load large amount of data from text file into a partitioned table. We found out that "SCSI Resets" and "SCSI Timeouts" Logged in the ADU (Hardware utility from HP) match Event ID 9's as seen in system/application log. Hardware verdor is looking into it for us.
October 4, 2003 at 2:57 am
Thanks Allen
I'll recheck the system/application event log to make sure I didn't miss any events.
Steven
October 6, 2003 at 12:54 am
I've the same problem. The cause, in my scenario, is due to 2 server cloned with the same disc image that share transactions. In such scenario, is possible that a transaction opened by a server, is passed and closed by the other server, so the first server hangs. The solution, in my case, is to reinstall MSDTC how explains the MSDN article Q279786.
Bye
October 6, 2003 at 8:50 am
That error occurred here once too following the install of sp3. The log file to look for has a .mdmp extension but you can't read it in notepad. Other than KB article 810885 there is also KB 319892 that might help. Ours happened during a database backup so I rescheduled it and am waiting to see if the error happens again.
Linda
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply