When I treid to start a project, several SendPorts would not start.  When I tried to start each one manually, some of them were giving this misleading error in the EventLog.

Unable to communicate with MessageBox BizTalkMsgBoxDb on SQL Instance DAL-BIZ-APP01. Error Code: 0x8004d00e. Possible reasons include:
1) The MessageBox is unavailable.
2) The network link from this machine to the MessageBox is down.
3) The DTC Configuration on either this local machine or the machine hosting this MessageBox is incorrect.

We use BizTalk Deployment Framework (BTDF).  I had copied my binding file and updated in Visual Studio.  This is the second or third time that the XML editor of Visual Studio has bit me; it re-arranges the XML in the binding file, and the binding file import is apparently very picky about the layout.  Not sure why it cannot use standard XML conventions.

The moral of the story is to use NotePad++, NotePad or some other safe editor that doesn’t take any liberties with reformatting the XML. I rebuilt my MSI, redeployed, and it worked fine.

What helped me figure it out was this blog:  http://kundankarma.blogspot.com/2012/12/problem-enlisting-send-port.html.
Sure enough I looked at the SendPorts and they had no filters; i.e. the filters had been lost somehow by the editor issue.  Now why it causes the error “unable to communicate with the Messagebox” is entirely a mystery.


The BizTalk roundingfunctoid uses “Banker’s rounding” by default. That means if you have odd numbers round away from zero, and even numbers round towards zero.
For example, 1.5 rounds to 2, and 2.5 rounds to 2. This is the a “fair” way of rounding, so that neither party in a business transaction benefits. I’m currently working in the aviation fuel industry, and they always wanted to round “up”. In Microsoft terminology, this is called “away from zero”, because for negative numbers you are rounding up- or away from zero, to a bigger negative number.

First I implemented the first function below. It worked great when the data was clean. But if I had a field with a NULL value (i.e. the XML element was missing), the routine blew up with a nasty error.

I came up with the idea of the second routine, called “RoundAwayFromZeroSafe”. I have to pass more parameters to it, in order to get a useful error message written to the application event log.
If I wanted my code to be re-usable, these parms are needed to identify 1) Which map (I include the project name/map name here), 2) Field Name (for example, Net vs Gross, which field being rounded caused the problem), and 3) some identification number (in my case it was called TicketNum, although I should have gone with a more generic name for the parm). The first parm is the number to round, that comes from the left side of the map. Likewise, the TicketNum comes from the left side of the map. The other two fields are entered as constants into the Scripting Functoid (see picture below the code).

Why do I want to pass the ID/TicketNum?  Suppose you have a map of 1000 tickets/records.  How do you know which one has the bad data in it, unless you include the ID in the error?  It certainly saves a lot of time guessing or searching for the bad data to have it clearly labeled which “row” it is on.

        public static decimal RoundAwayFromZero(decimal numberToRound)
            // BizTalk functoid uses MidpointRounding.ToEven (also called Banker's Rounding)
            // http://msdn.microsoft.com/en-us/library/system.midpointrounding%28v=vs.110%29.aspx 
            // BUt we want to always "round up", i.e. away from zero. 
            return Math.Round(numberToRound, 0, MidpointRounding.AwayFromZero);

        public static decimal RoundAwayFromZeroSafe(string strNumberToRound, string strTicketNum, string strMapName, string strFieldName)

            decimal decNumberToRound = 0; 
            if (decimal.TryParse(strNumberToRound, out decNumberToRound)) 

                // BizTalk functoid uses MidpointRounding.ToEven (also called Banker's Rounding)
                // http://msdn.microsoft.com/en-us/library/system.midpointrounding%28v=vs.110%29.aspx 
                // BUt we want to always "round up", i.e. away from zero. 
                return Math.Round(decNumberToRound, 0, MidpointRounding.AwayFromZero);
            else if (strNumberToRound == null) 
                // same as below, but no need to write error message to EventLog 
                return 0;
                string errorMsg = "Non-Decimal passed to RoundAwayFromZeroSafe Ticket=" + strTicketNum +
                                    " MapName=" + strMapName + 
                                    " FieldName=" + strFieldName + 
                                    " Value Passed='" + strNumberToRound + "'";
                System.Diagnostics.EventLog.WriteEntry("Logger", errorMsg, System.Diagnostics.EventLogEntryType.Error);
                return 0;

This shows how I pass the constants to the above routine: RoundAwayFromZeroSafe


Here’s an example of the error written the log (before I started checking for nulls). One might debate whether a map should ever write to the log. In theory, these type of errors should be worked out during development and QA, so it should never happen in Production. We use “Logger” for our common Event-Log-Source, so any of our programs that write to the EventLog will be tagged with the source as “Logger”. NOTE: There are a few extra steps (documented elsewhere) to establish a new event log source on each system.


The actual message reads:

Non-Decimal passed to RoundAwayFromZeroSafe Ticket=QT.Epic.Export:EFSRExtractsGrouped_v1_0_To_EPIC_csv.btm MapName=SPMSP476723 FieldName=Gross Value Passed=”

(Oops – I just noticed that I have Ticket and Mapname backwards in the error message).


Microsoft References:
1) BizTalk Rounding Functoid
2) Microsoft Rounding AwayFromZero vs ToEven (Banker’s Rounding)


A message sent to adapter "BiztalkMessagingEngine" on send port "XX.FMA.Extract_1.0.0.0_XX.FMA.Extract.SendExtract_DynamicFTP_f136abb33540170c" with URI "" is suspended. 
 Error details: Unknown Error Description  
 MessageId:  {28F29FA5-18EF-4FE7-B6CC-E03F4E2AA26F}
 InstanceID: {C09E16A5-11AB-46AF-980A-7826772EEF0B}


We moved code to a new target environment, where the Host-Instances didn’t match the source environment. We reconfigured some of the HostInstances to allow for a default 32-bit host instance, then restarted the Host Instances.

Orchestration is being used to send files to a dynamic FTP. We store the FTP site, user, password in a SQL table to allow us send to many different FTP trading partners.


Unenlist and re-start the dynamic send port. Apparently restarting the Host Instances was not enough.

This is the site that helped me resolved it: