The information in this article applies to:
SUMMARY
Infrequently Windows NT may halt with a STOP screen, commonly called a
"blue screen", or it may hard hang, where the console is completely frozen
and non-responsive. This may sometimes happen on a computer where SQL
Server is running, or may coincide with a particular SQL Server operation
such as a DUMP or LOAD, BCP, a long-running query, and so on.
Q101272 Memory Parity Errors: Causes and Suggestions MORE INFORMATION
Processes exist on Windows NT in either user mode or kernel mode (sometimes
called supervisor or privileged mode). In the Intel i386 architecture, user
mode maps to ring 3 and kernel mode to ring 0 of the 4-ring protection
system. The i386 architecture has been carried forward with little change
in all Intel and compatible processors to date, including the Pentium Pro
and Pentium II. RISC processors such as the Alpha AXP likewise typically
have unprivileged and privileged modes.
A Winlogon Problem Caused by SQL Extensible Performance CountersCurrent Windows NT architecture stipulates that any extensible performance counters added by a service will run in the process context of the Windows NT Winlogon process. Because Winlogon is a vital component of the operating system, a bug or resource leak in any performance counter DLL may disrupt Winlogon, and hence the operating system. The SQL Server extensible performance counter DLL is called Sqlctr60.dll, and it exports several SQL Server-specific objects from SQL Server to the operating system. You can use Performance Monitor to monitor these objects. For more details on extensible performance counters, see volume 4 of the Windows NT Resource Kit, titled "Optimizing Windows NT," by Russ Blake.Although it is very rare for Sqlctr60.dll to cause a Winlogon problem, you can expedite problem identification when pursuing a Windows NT failure or blue screen problem on a computer running SQL Server by renaming this DLL. Doing this eliminates use of SQL Server performance counters, but you can still use Performance Monitor to monitor SQL Server by using regular Windows NT performance counters (such as threads, process, memory, and so on). If renaming Sqlctr60.dll fixes the problem, and if this is confirmed by reinstating and removing the DLL several times, the problem should be pursued as a SQL Server issue. Otherwise, it should be pursued as a system- layer issue. A Resource LeakIf a resource leak continues for a period of time, the operating system should return the appropriate return code to the application, which should log this. For example, if you receive operating system error 8 "not enough storage," the operating system should handle the situation gracefully by not granting further resource requests. However a continued application resource leak may not be handled gracefully by the operating system under all conditions, resulting in a blue screen or operating system or application failure.Almost all resource leaks will manifest themselves as a gradual increase in consumption of some resource, such as handles, virtual memory, private bytes, and so on. Therefore, the easiest way to rule in or out a resource leak is to run Performance Monitor and log all objects to a file. When the problem occurs, examine the logged performance data for signs of a leak. Some good counters to examine are: handle count, page file bytes, pool paged bytes, pool nonpaged bytes, private bytes, thread count, virtual bytes, and working set for each process running on the computer. It is not necessary to classify certain values as normal or abnormal. Focus on identifying leaks by the continuous nature of the increase, not by the absolute value at a given time. Remember it's normal for the perfmon "private bytes" counter for SQL Server to start well below the configured sp_conigure "memory" value, then increase with activity until it roughly approaches, but doesn't significantly exceed, that value. If one of the logged Performance Monitor counters continuously increases for the Sqlservr.exe process, and if reaching a certain value repeatedly coincides with a Windows NT blue screen or operating system failure, it should be pursued temporarily as a SQL Server issue until the cause of the continuous SQL Server resource leak is understood. Otherwise, it should be pursued as a system layer problem. CPU MonopolizationIf a process spawns high priority threads that are continuously in a runnable state, this process can dominate the computer and prevent the operating system from running. A properly configured SQL Server will not cause this problem. However if SQL Server "SMP concurrency" is set to -1, and if a number of long-duration CPU intensive queries is run equal to or greater than the number of processors, under some conditions the operating system may appear to stop responding. In general, you should leave SQL Server the "SMP concurrency" option at the default setting of 0. Likewise, leave the "priority boost" setting at the default. For more information, see the following articles in the Microsoft Knowledge Base:Q111405 SQL Server and Windows NT Thread Scheduling When pursuing an operating system hang problem, first ensure that the SQL Server configuration settings mentioned above are at their default values. After making this check, if the operating system or application failure recurs, it should be pursued as a system layer problem. REFERENCESFor more information, see the following documents:
Additional query words: hang hung bulk copy program crash app winnt perfmon
Keywords : kbenv kbinterop SSrvGen |
Last Reviewed: October 7, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |