Avoiding DBNETLIB Exceptions

Avoiding DBNETLIB Exceptions

Database Network Library (DBNetLib) errors occur when the BizTalk Server runtime is unable to communicate with the MessageBox or BizTalk Management databases. When this occurs, the BizTalk Server runtime instance that catches the exception shuts down and then cycles every minute to check if the database is available.

The most common cause of a DBNetLib error is when one of the MessageBox database servers becomes extremely busy. Attempts to communicate with the busy MessageBox database server result in a timeout, which causes a DBNetLib exception.

The other known conditions under which a DBNetLib error can occur in a production environment include:

  • Errors that occur when BizTalk Server is processing a high volume of messages AND Windows Server 2003 Service Pack 1 is installed.

  • Errors that occur when BizTalk database servers hosting one or more MessageBox databases become I/O (Input/Output) bound.

This topic describes conditions that can lead to DBNetLib errors and recommendations for avoiding these errors.

A BizTalk Server host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents.

To fix this type of DBNetLib error, you have to modify the registry. Before you do this, always back up the registry, and verify that you know how to restore the backup if a problem occurs. For more information about how to back up, restore, and modify the registry, see the Microsoft Knowledge Base article "Description of the Microsoft Windows registry" available at http://go.microsoft.com/fwlink/?LinkId=62729.

Symptoms of a DBNetLib Error Caused by a High Volume of Documents

When a host instance terminates and then restarts itself, errors that are similar to the following are written to the BizTalk Server Application log:

Event Type:Warning
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006 
Event ID:5410
An error occurred that requires the BizTalk service to terminate. The most common causes are the following:
 1) An unexpected out of memory error.
 2) An inability to connect or a loss of connectivity to one of the BizTalk databases. 
 The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.
 Error message: [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.
 Error source:  
 BizTalk host name: BizTalkHost
 Windows service name: BTSSvc$BizTalkHost 

Event Type:Error
Event Source:BizTalk Server 2006
Event Category:BizTalk Server 2006 
Event ID:6913
An attempt to connect to "BizTalkMsgBoxDb" SQL Server database on server "SQLSERVER " failed.
 Error: "[DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation."


This issue occurs because Microsoft Windows Server 2003 Service Pack 1 implements a security feature that reduces the size of the queue for concurrent TCP/IP connections to the server. This feature helps prevent denial of service attacks.

When BizTalk Server processes a large number of messages, the TCP/IP protocol in Windows Server 2003 SP1 may incorrectly identify valid TCP/IP connections as a denial of service attack. This behavior could lead to a DBNetLib error.


Modifying your registry is very risky. Serious problems might occur if you modify the registry incorrectly. To fix a corrupt registry, you might have to reinstall your operating system, and even then Microsoft cannot guarantee that these problems will be solved. Modify the registry at your own risk.

To resolve this DBNetLib error, you must turn off this new functionality in Windows Server 2003 Service Pack 1 by adding the SynAttackProtect entry to the following registry key on the computer that is running the Microsoft SQL Server that houses your BizTalk Server databases.


Set the SynAttackProtect entry to a DWORD value of 00000000. To do this, perform the following steps:

  1. Click Start, click Run, type regedit, and then click OK.

  2. Locate and then click the following registry key:

  3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  4. On the Edit menu, point to New, and then click DWORD Value.

  5. Type SynAttackProtect, and then press ENTER.

  6. On the Edit menu, click Modify.

  7. In the Value data box, type 00000000. Click OK.

  8. Quit Registry Editor.

  9. Restart the computer that is running SQL Server.

BizTalk Database Servers Hosting MessageBox Databases Becoming I/O Bound

BizTalk Servers communicate and act directly with the database servers hosting the MessageBox database(s). If a database server hosting a MessageBox database gets too consumed and becomes I/O bound, then it might become unresponsive. One of the BizTalk Servers might lose connectivity with the database server, and a DBNetLib error will occur.

A highly consumed database server becomes I/O bound when its physical disk’s "%Idle time" continues to drop and goes below 10%. If the “%Idle time” falls below that level, then your database server is likely to become unresponsive.


There are several reasons that can cause the database servers to become I/O bound. The reasons include:

  • If the database computer hosting the MessageBox database is bound by low hardware specifications, such as, low memory number and speed of processors, and so on.

  • If the physical disk on the database computer hosting a MessageBox database is shared by other highly consumed databases. When several databases (including the MessageBox) are highly consumed at the same time, the physical disk can become I/O bound.

    For example:

    A database server hosting the BizTalk Tracking and/or BAM databases can sometimes consume a high percentage of a physical disk’s %Disk Read and Write Times. When the database server disk that hosts a MessageBox database is shared by another highly consumed database, such as BizTalk Tracking or BAM, and if the databases are highly consumed simultaneously, they might cause the database server physical disk to become I/O bound and then unresponsive.

  • If the BizTalk Tracking and one or more of the MessageBox databases share the same physical disk on the database server, and if archiving and purging is not run frequently, the disk might become I/O bound.


Ensure the database server(s) hosting the BizTalk MessageBox database(s) do not get into a situation where they become highly consumed and possibly unresponsive.

Some of the primary causes of a server disk becoming highly consumed and recommendations on how to mitigate this problem are listed in the following topics.

Low Hardware Specs

Server consumption can increase when its hardware specifications cannot keep up with the amount of load it’s trying to process. With lower hardware specifications, the system gets overwhelmed quickly by the amount of activity happening on the databases. This might cause the server’s %Disk Read and Write Times to increase without stabilizing and the disk’s %Idle time to decrease to less than 10%. This can cause your database server to become unresponsive.

If your database servers become unresponsive during to high loads, you can upgrade the following parts in your database servers: number of CPUs, memory, and connecting to a SAN. It is recommended that you properly diagnosis the bottleneck and whether upgrading your hardware will fix the bottleneck. For more information about identifying bottlenecks, see Identifying and Mitigating Performance Issues.

Sharing One Server or Disk for More Than One Group of BizTalk Databases

Databases, such as the BizTalk Tracking (BizTalkDTADb) database and BAM databases, might consume high cycles on a server’s physical disk. If those databases share the same physical disk with one or more MessageBox databases, then they might cause the disk to become unresponsive. This can cause BizTalk Server to lose connectivity with one or more MessageBox databases and cause a DBNetLib error.

It is highly recommended that you separate databases that are expected to have high consumption of the server’s physical disk from the BizTalk MessageBox database(s). Ensure that they share different physical disks or separate them on different servers. It is also recommended that you separate the BizTalk Tracking and BAM databases on their own separate drives/servers from the MessageBox database(s). Additionally, if there is more than one MessageBox database, it is recommended to have each MessageBox database on its own disk.

Archiving and Purging

When your BizTalk Tracking and MessageBox databases share the same disk on the same server, you must archive and purge your BizTalk Tracking database regularly, It is good practice to archive and purge periodically. However, if you run under higher loads than normal, then consider archiving and purging more frequently. If the BizTalk Tracking database growth is not maintained regularly, it can take considerable time to complete archive and purge jobs. Further most of the available database server resources are consumed while the jobs are running.

© 2016 Microsoft