This is a “back to the basics” post with a list of reasons BizTalk might not be processing (consuming) your file that you have placed (dropped) in a directory associated with a Receive Location.

1. Are the Host Instances started? (Specifically the Host Instance associated with the Receive Location).  Be sure and refresh (F5 or right-click refresh) to make sure you are not looking at old statuses.

Each receive location has a “Receive Handler”. See Figure 1 below.

See Figure 2 below to check if the Host Instances are started. Be sure and refresh (F5 or right-click refresh) to make sure you are not looking at old statuses.

Figure 1 - Receive Location - Receive Handler (Host Instance)

Figure 1 – Receive Location – Receive Handler (Host Instance)

In the case above, the Receive Location Hander is BizTalkServeApplication. So it doesn’t matter that the Rosetta Host Instance is not started.

Figure 2 - Status of Host Instances

Figure 2 – Status of Host Instances

2. Make sure the Receive Location itself is “Enabled”. The figure below doesn’t show, but I opened BizTalk Admin console, navigated to the Application on the left menu, then expanded the “Receive Locations”

Figure 3 - Receive Location Status

Figure 3 – Receive Location Status

3. Check Windows Application Event Viewer for Errors:

For example, here is an error I had today:
The FILE receive adapter cannot process file e:\Messages\Charter\Inbox\StarterParams\StartParams_Prod.xml because of one of the following reasons:
1) The file is read-only.
2) The file is a system file.
3) The FILE receive adapter does not have write permissions on the file.

To see if the file is read only, right click on the file and make sure the checkbox next to “read-only” attribute is NOT checked. Also make sure the file you are copying/dropping into the pickup directory is not “read-only”, because that attribute sticks when you copy it. NOTE: You might have a sample file in your Visual Studio Project, then when you check that project in to TFS (or some other source control system), the read-only attribute of that file is turned on. You might want to have a copy of your file for testing that is not part of TFS check-in so that the read-only attribute will stay off.

To check security, from Windows Explorer, right click the directory (not the file), click on the Security tab, and make sure that the userid that runs the Receive Handler Host Instance (see Figures 1 and 2 above) have Full Control. If in doubt, you could always add the user “Everyone” and give it full access. Then once you get it working, go back and tighten-up the security. If you are working on your own laptop or development computer, the security probably doesn’t matter. But on a shared development, QA, or production environment, security can be very important.

4. Consider checking the CPU performance on the machine.

I’ve seen cases where there is a task using 100% of the CPU, and that is preventing the BizTalk host instance to do its work.

The short cut to open Windows Task Manager is Cntl-Shift-Escape.  I like to check the “Performance tab” to see what CPU Usage is, if it is high, and how long it has been high. If it is really high, like 90-100%, you can click Processes (then sort by CPU) and find out which task is taking all the CPU.

Figure 4 - Windows Task Manager

Figure 4 – Windows Task Manager


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:
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.



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:

Exception type: InvalidOperationException
Source: System.Xml
Target Site: System.Object Deserialize(System.Xml.XmlReader,
System.String, System.Xml.Serialization.XmlDeserializationEvents)
The following is a stack trace that identifies the location where the
exception occurred

I was using the BizTalk orchestration xpath command, like this:

myString = xpath(myMessage,myXpath);

The problem was, that I forgot to wrap the xpath with the string() function, like this:

myString = xpath(myMessage,”string(” + myXpath + “)”);

I got this error today, and it was very difficult to figure out. I wasted about two hours on it.

There was a failure executing the receive pipeline: “pipeline name” Source: “Pipeline ” Receive Port: “SQLPollingWire” URI: “SQL://Server/ECData_SharedDev/4” Reason: Input string was not in a correct format.

I was using the polling of the built-in SQL adapter, and add a new element to my SQL query, and thus manually added the same element to the schema.

In the schem a, the new field w as defined as a string, not a number, so why would this blow-up in the pipeline?

The error is the same error that is thrown when you would get if you tried this: System.Convert.ToInt32(“test”).

The answer is that I did a quick-promote on it, and accidentally associated it with field in the property schema that was an “int”. Thus, when the pipeline was doing the promotion of the field, that’s when it died.

Another error solved, and more time wasted. Hope this helps if you get this error.

This week, we finally agreed on our TFS structure, and I checked in all our BizTalk code. It compiled okay before check-in, but after check-in it was giving the following strange error:

Error Error
Build failed. Assembly builder could not generate final assembly
ll’. Access to the path
zTalk.ArtifactsOrchestrationsProcessWireTransfer.odx.cs’ is denied.

At first, I went off on a red herring. I thought this was related to the “obj’ directory needing to be deleted, or that some other file was accessing it.

Then it dawned on me, the problem was really with the xxx.odx.cs file. Why this file? The compiler generates this file, so it never really needed to be checked-in to TFS in the first place. Since I did a mass-checkin from disk (by doing “Add-Files”), these files ended up in TFS as well. Thus, when they were brought down to a new disk structure, they had the “read-only” attribute set.

So I had two solutions, either check-them-out, or delete them. I went with the concept of deleting them on TFS, then deleting them on disk, then the compile worked.

NOTE: When testing with this on TFS, it’s useful to do a test with two developers. Just because it works on one developers machine, doesn’t 100% guarantee that when the second developer checks it out that it will work.

An example of this point is our “add references”. We reference a common binaries folder to allow for more flexibility of each developer building his own solutions. In other words, we typically don’t do references with the solution, and instead reference the a special folder we created called “binaries”. It’s a little bit of a pain to keep it in sync.

Anyway, when we checked in the disk structure, the .DLLs in the Binaries by default were excluded. I had to go back and check them again manually, without the exclude of the .DLL suffix.

Hope this helps…
Neal Walters

Here is one cause of the error below. In this case, a fellow developer GAC’ed the .DLL in the Deployment/bin instead of the Development/bin. There was a .DLL in the Deployment/bin, but it was much older, and didn’t have the specific orchestration being called for.

Failed while creating a Your.ProjectName.YourOrchestrationName service.

Exception type: ServiceCreationException
The following is a stack trace that identifies the location where the exception occured

at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._serviceCreator(Guid& instanceId, Object objCurrMsg)
at Microsoft.XLANGs.Core.ResourceContainer._allocateResource(Guid& key, UInt32 hashKey, ResourceCreator resCreator, Object creationContext)
at Microsoft.XLANGs.Core.ResourceContainer.Dispense(Guid& key, ResourceCreator resCreator, Object creationContext)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._dispenseService(Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._tryReceiveOneMessage(Boolean& loggedError, Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._receiveOneMessage(Guid& instanceId, Guid& serviceId, IBTMessage currentMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession.ReceiveMessages(IBTMessage[] messages, Int32 firstIdx, Int32 count)
at Microsoft.BizTalk.XLANGs.BTXEngine.AppDomains.AppDomainRoot.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object objMsg)
at Microsoft.XLANGs.BizTalk.CrossProcess.AppDomainStubProxy.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object msgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)


Exception: System.ServiceModel.CommunicationException: There was an error while trying to serialize parameter The InnerException message was ‘Type ‘TFBIC.RCT.WCFWebServices.ExpressLync.MainStreetValuation’ with data contract name ‘MainStreetValuation:’ is not expected. Add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.’. Please see InnerException for more details. —> System.Runtime.Serialization.SerializationException: Type ‘TFBIC.RCT.WCFWebServices.ExpressLync.MainStreetValuation’ with data contract name ‘MainStreetValuation:’ is not expected. Add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.


1. Manually create a proxy to the WCF Service from the command line like so:
svcutil /serializer:XmlSerializer http://localhost:46122/ValuationService.svc

2. Add the [XmlSerializerFormat] to your ServiceContract on the WCF Service

By doing this, we force our WCF Service to use the XmlSerializer rather than the default DataContractSerializer. Note: you?ll need to call the WCF service from you new proxy in your sample code.

When using HIP (CICS Host-Initiated-Processing) [part of Host Integration Services – or HIS] – you might get the error “Select Error Occurred”. This seemed to happen to me when I was trying to pass a null value back to the HIP (and therefore CICS). It seems to want to have all the fields set to some value other than null. Unfortunately, it doesn’t tell you the field that is causing the problem.

With other errors, sometimes you will get an Event Log message that is more helpful. For example, if CICS tries to send a number that is too large for the .NET type, you will get a message like this:

Event Type: Error
Event Source: HIP Service
Event Category: (7)
Event ID: 815
Date: 2/2/2010
Time: 1:00:29 PM
User: BUILTINAdministrators
(815) A Transaction Integrator flow control module is reporting a failure when converting client user data.
HIP Application: RCTGetReplacementCost

Error Description: (1507) The magnitude of a sending field exceeds that allowed for a receiving field in RqstEstimateNumber in GetReplacementCost.
The size of the number is too large to be placed into the resulting data type. Check for a client application error and correct. If the client application is correct consider modifying the data conversion mapping so that the parameter is converted to a data type capable of accepting the numeric value.

HRESULT: 80020009

An error has occurred when converting input user data.
Verify that the client program is sending the correct data and that the correct HIP mappings have been administered. Make sure that the Transaction Integrator service has been properly deployed and administered and that the HIP runtime environment has been installed on the system on which the failure occurred. If the problem persists contact Microsoft support.

This can happen if COBOL has for example PIC S9(10), and .NET has an integer. Entering 1111111111 in the number “fits”, but entering 2222222222 does not.

Of course, check your action first. It could be misspelled or mistyped.

What can happen is that your BizTalk works fine with a WCF web service,
but then you move the WCF service to a different machine and get the error below.
Apparently, this only happens when the different machine is in a different domain.

&lt;s:Fault xmlns:s=""&gt;
&lt;s:Subcode&gt;&lt;s:Value xmlns:a=""&gt;a:BadContextToken&lt;/s:Value&gt;&lt;/s:Subcode&gt;
  &lt;s:Reason&gt;&lt;s:Text xml:lang="en-US"&gt;The message could not be processed.
<br />This is<br />
most likely because the action 'http://YourService/IYourInterface/YourMethod' is incorrect or <br />because the message contains an invalid or expired security context token or because there <br />is a mismatch between bindings. The security context token would be invalid if the service <br />aborted the channel due to inactivity. To prevent the service from aborting idle sessions <br />prematurely increase the Receive timeout on the service endpoint's binding.&lt;/s:Text&gt;

Add the code below to the web.config for your WCF web service.

       &lt;binding name="Binding1"&gt;
            &lt;security mode="None"&gt;
                 &lt;transport clientCredentialType="None" /&gt;
                 &lt;message establishSecurityContext="false" /&gt;