Document:
Recognizing and Resolving nl_read_defer, nl_write_defer, and invalid tds length Errors

The Problem:

For releases prior to 11.0.3.x, SQL Server sometimes crashes with a stack trace on multiprocessor boxes due to corruption of the winsock stack.  The pivotal error messages in the stack trace are nl__read_defer, nl__write_defer, and invalid tds length.  

Below is a typical stack trace for this type of error:

<date> <time> kernel pc: <hex> kisignal: unknown signal (5).
<date> <time> kernel pc: <hex> ucbacktrace + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> kiexception + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> nast_writepost + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> nl__write_defer + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> kadodeferred + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> kpstartsched + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> servermain + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> scm_main + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> \177libctl_NULL_THUNK_DATA + <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> (<hex>, <hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex> end of stack trace, kernel service process: kpid <int>).
<date> <time> kernel pc: <hex> engine 0, os pid <int> exited
<date> <time> kernel pc: <hex> kisignal: unknown signal (5).
<date> <time> kernel pc: <hex> kisignal: unknown signal (5).
<date> <time> kernel pc: <hex> kisignal: unknown signal (5).

Another error message that can be in the mix is invalid tds length:

<date> <time> kernel pc: <hex> nast-readpost:invalid tds link (8224),socket 4 listener 0

Note that network problems can also result in nl__write_defer, nl__read_defer, and invalid tds length errors, but the stack trace will be dramatically different.  Some cases have been corrected by using fully qualified IPX/SPX connection entries in SQL.INI, thus resolving port conflicts.  If the customer is running Adaptive Server Enterprise 11.5.x, or SQL Server 11.0.3 or later, look for a network problem as the likely cause of nl__write_defer,  nl__read_defer, or invalid tds length errors.

The Resolution:

Upgrade to Adaptive Server Enterprise 11.5.x, or SQL Server 11.0.3 or later. Bugs 125610, 129211 and 131195, which together comprise the problem, were corrected starting with SQL Server 11.0.3.   (These corrections were also backported to a release of 11.0.2.2 as a stopgap prior to the release of 11.0.3, but it is recommended that customers upgrade to ASE 11.5.x or SQL Server 11.0.3.x instead).

Workaround:

Sometimes customers do not have an immediate window of opportunity to upgrade.  To minimize the probability of a crash in the meantime, set max online engines to 1 so that only one processor is used, and stop using any other software on the server that makes use of the winsock stack (e.g. the SAP service, FTP server software).

To set max online engines from Sybase (SQL) Central, connect to the server and use the File > Configure menu option, or right click on the server icon and select Properties from the context menu.

To set max online engies from isql, issue the command command sp_configure "max online engines", 1 .  

This is a static configuration option, so you will have to shutdown and restart the server before  the change takes effect.