• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 324
  • Last Modified:

sql srv 6.5 crashes without comments and error logs

we use sql srv 6.5 in combination with visual basic 5.0
clients. after roughly 3 days online sql server won't react anymore so every client gets a time out. at this point sql srv won't react at all anymore. you can't shut it down nor pause. it always results in physically rebooting the machine. the error log won't give a hint. the last entry in the error log is "won't accept new connections because of 'pause'". 3 secs later it says "will accept new connections because of 'continue'". However, nobody ever touched the machine. the number of connections is still low (according to sys-monitor) and well below the limit set. we applied service pack 4.0 for sql srv and 3.0 for win-nt.
0
stocksql
Asked:
stocksql
  • 8
  • 3
  • 3
1 Solution
 
stocksqlAuthor Commented:
Adjusted points to 180
0
 
aliciaamCommented:
See the SQL Server 6.5 "What's New in SQL Server 6.5" documentation section on
SQL Trace discusses how to turn on filters to capture SQL commands coming
into a SQL Server 6.5. Once a filter has been applied to an ODBC client,
the SQL commands being sent to the server by the driver will be visible.
That way you will be able to pinpoint the problem.
0
 
stocksqlAuthor Commented:
thanks, but we had done this already without any result. The last issued sql statements before a crash are just as harmless as the statements before. However, the last chrash left the following info in the error log: "unable to dynamically load imagehelp.dll -- STACK DUMP -- exception adress 77F745BD", other crashes simply left the info that sql server was paused, however, nobody ever paused it manually and why isn't it reacting to the enterprise manager?
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

 
stocksqlAuthor Commented:
Adjusted points to 190
0
 
stocksqlAuthor Commented:
approx. 1 hour before the crashes we get a couple of #17824 errors, however, they disappear, so we assume its some temporary network error, could this be related?
0
 
cognitionCommented:
Could the following article apply Q187278 ?
0
 
stocksqlAuthor Commented:
we already use 'named pipes' as a network library. however, the symptoms are exactly the same. where do we get the mentioned fix?
0
 
cognitionCommented:
To get non regression tested fixes you usually need to contact MS, or look in the backoffice web site.

0
 
cognitionCommented:
Is it something as simple as the transaction log filling up ?
Try checking the "Truncate Log on Checkpoint" for master, tempdb and your database.

Or it could be that when users disconnect there are resources left open and SQL runs out of memory, a tempdb becomes full ?

You can use performance monitor to see what resources are being used, or the amount of memory avaialable.
0
 
stocksqlAuthor Commented:
all our transaction log are half empty. we also use performance monitor to get information on all the vital parameters. the weird thing is that everything is in normal condition and no significant parameter changes are observed around the chrashes
0
 
aliciaamCommented:
Error 17824 does not always indicate a network problem. The following are
the most common situations under which the error 17824 is generated, along
with the corresponding troubleshooting procedures.
 
 - This error may occur if the users are restarting their client computers
   if the application seems have stopped responding, so make sure they
   don't do that. It may be that the server is taking a longer time to
   process a long query. Once the client workstation is restarted, the
   connections are broken ungracefully. Later SQL Server tries to respond
   to the connection that has been dropped, and logs the message 17824.
 
 - The network may be unstable; make sure it is stable. You can check this
   by attempting to copy large files between the computer running Windows
   NT Server and the client computer. If this test fails, then you are
   running into problems with the physical network. Because the above
   errors indicate a potential network issue, it is recommended that you
   update the server, both Windows NT Server and SQL Server, to the latest
   service packs. Please check the knowledge base articles for more
   information on how to obtain the latest service packs for the Windows NT
   Server operating system and SQL Server. It is also recommended that you
   update the client components such as DB-Library, the ODBC driver, and
   network library to the latest DLLs. In case of client computers running
   16-bit Windows 3.1 or Windows for Workgroups on a Novell network, it is
   necessary to obtain and install the latest MS-DOS and Windows drivers
   from Novell.
 
 - Error 17824 "Unable to write to ListenOn connection" may be a
   consequence of other errors that caused the connection to drop. Check
   the error logs for other errors within the same time frame as the 17824
   error. If you find other errors, refer to SQL Server Books Online and
   the Microsoft Knowledge Base for more information on these errors.
 
 - Use sp_configure or the SQL Server Enterprise Manager to check the
   Priority Boost and the SMP Concurrency configuration settings. Make sure
   that these two configuration options are set to the default settings,
   because deviating from the default settings may cause error 17824 under
   some conditions.
 
   For more information on why these settings may generate error 17824,
   please refer to the following article in the Microsoft Knowledge Base:
 
   ARTICLE-ID: Q111405
   Title     : INF: SQL Server and Windows NT Thread Scheduling.
 
 - The error 17824 may be generated due to application problems. One major
   cause is running into a lock or block situation. In this case, a process
   holds a lock on a page or a table, and that lock is not released right
   away, due to an uncommitted transaction or a long query. This may cause
   all other processes requesting the same table to be blocked, and the
   client application to seem to stop responding. If the user then either
   uses 'End Task' to close the application or restarts the workstation,
   you may receive error 17824 on the server.
 
   To find out if the application is causing a lock or block problem on the
   server, use the sp_who and sp_lock stored procedures when the client
   computers seem to stop responding or when the error 17824 starts to
   appear in the SQL Server error logs. If the client workstation has
   stopped responding, open a command-line ISQL connection on the server
   itself using the local pipe, and use these stored procedures to check
   for a blocking situation.

0
 
stocksqlAuthor Commented:
well, the problem was not fixed with any of the above comments. we applied fix#5 and since then the problem did not reoccur.
0
 
aliciaamCommented:
Thanks, it is good to know that SP5 solved it. It is probably a bug ???
0
 
stocksqlAuthor Commented:
if it is one, we did not find it described before.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 8
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now