KB 899599: 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

June 28, 2010

I thought I might post an entry aimed at anyone else who may be experiencing the following issue.

I experienced a performance related issue recently where errors were being posted to the Windows application event log when BizTalk server was processing a high volume of documents.

In this particular environment the BizTalkMgmtDB was hosted on a server different to that of the BizTalk server instance.

To resolve this issue, turn off this new functionality by adding the SynAttackProtect entry to the following registry key on the computer that is running Microsoft SQL Server that houses your BizTalk Server databases.
Set the SynAttackProtect entry to a DWORD value of 00000000. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry key:
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type SynAttackProtect, and then press ENTER.
5. On the Edit menu, click Modify.
6. In the Value data box, type 00000000. Click OK.
7. Quit Registry Editor.

Note: To complete this registry change, you must restart the computer that is running SQL Server.

More detailed information can be found by following the link: http://support.microsoft.com/kb/899599/en-us


BizTalk transformation operations: Inline C# is bad

April 28, 2010

When BizTalk Server performs XML transform operations on fairly large messages in a receive port, in a send port, or in XLANG, XSL transforms load the whole message in memory..

To resolve this issue, use one of the following methods:

  • Decrease the number of messages that BizTalk Server processes at the same time.
  • Reduce the size of the XML message that is being transformed.

The System.Policy.Security.Evidence object is often used in transforms and can consume much memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.

Most of the default BizTalk functoids are implemented as inline script. These items can cause System.Byte[] objects to collect in memory. To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly. Use the following chart to determine which functoids use inline script and which functoids do not use inline script.

In the second column, “Yes” means that this functoid is implemented as inline script, and that it will cause System.Byte[] objects to collect in memory. “No” means that this functoid is not implemented as inline script, and that it will not cause System.Byte[] objects to collect in memory.Collapse this tableExpand this tableFunctoids Inline script?

Functoids Inline script?
All String Functoids Yes
All Mathematical Functoids Yes
All Logical Functoids except IsNil Yes
Logical IsNil Functoid No
All Date/Time Functoids Yes
All Conversion Functoids Yes
All Scientific Functoids Yes
All Cumulative Functoids Yes
All Database Functoids No
Advanced Functoids Inline script?
Looping Functoid No
Value Mapping Flattening Functoid No
Assert Functoid No
Table Extractor Functoid No
Table Looping Functoid No
Scripting Functoid with Inline C# Yes
Scripting Functoid with Inline JScript.NET Yes
Scripting Functoid with Inline Visual Basic .NET Yes
Scripting Functoid with Inline XSLT No
Scripting Functoid with Inline XSLT Call Template No
Scripting Functoid calling External Assembly No
Nil Value Functoid No
Value Mapping Functoid No
Mass Copy Functoid No
Iteration Functoid No
Index Functoid No
Record Count Functoid No

This is an excerpt from Microsoft KB article 918643. For further information follow this link.

Limiting the maximum memory used by SQL Server 2005

September 14, 2009

A great tip for limiting the maximum memory used by SQL Server 2005 when you are hard pressed for resources is to limit the maximum memory threshold of SQL server of your SQL server instance.

This can be acheived easily by setting the “Maximum Server Memory” setting in your SQL Server instances properties.


This improved performance for me within my development virtual machine.