I got the same error as the one in this blog:

System.Configuration.ConfigurationErrorsException: Unrecognized attribute 'ApplicationName'. Note that attribute names are case-sensitive.

The difference is that I got it run-time, where in the blog above, he got it at the time of importing the bindings.

I was afraid that maybe the Cumulative Updates (CUs) were out of sync; and I have a project underway to make sure that both systems are on the latest CU6.

I tried removing the “ApplicationName = ”” out of the binding file and re-importing, but when I went to BizTalk Admin in my Production environment, the Application Name was there in the properties on the WCF-Custom (SQL) send port (and still had a blank value).

I looked for other differences between test and production, and discovered that I had switched it to a 64-bit Host Instance in Prod. When I switched it back to 32-bit Host Instance, it got past this issue.

Back to the basics of BizTalk. Even with years of experiences, sometimes you do something “stupid” and can’t figure out the error:

The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure. 

For example, today I dropped my message into a file pickup folder, then Receive Location consumed it. I was expecting my orchestration to start, but instead I got the error above.

Here is a basic checklist:
1) Make sure you are using the right pipeline in your Receive Location, such as XmlReceive Pipeline or EDIReceive, so that it promotes the MessageType (as opposed to PassThruReceive).

2) Make sure you dropped the file in the correct folder, associated with the correct Receive Location

3) Make sure you dropped the correct file (it’s easy to copy/paste the wrong one). To make sure:

3a) The suspend will create a resumeable and not-resumable error. open the not-resumeable one, go the the “Messages” tab, double click the message, then go to the “Context” tab/link on the left, and find the the “Message Type” in the “Name” column, for example:

Remember that the message type is SchemaNamespace#SchemaRootElementName (the two values separated by a pound sign). Verify that there is a MessageType and that it is correct? Did you drop the wrong file?

3) Make sure that your orchestration bindings are correct. This was my issue today. I bound the orchestration to the wrong Receive Port.

Double-click the orchestration, then click “Bindings” on the left. Check the “Receive Ports” are properly matching the “Inbound Logical Ports”.

4) Use the “BizTalk Admin Subscription Viewer“.
See the link for sample of how this works. Basically, make sure that your orchestration is set to Activate on the correct MessageType (see explanation of MessageType above).

If you’ve been around BizTalk for a while, like me, you most certainly have gotten this error many times.

The normal solutions are:
1) Make sure you schema is deployed
2) Make sure your schema is not deployed more than once
3) Set “AllowUnrecognizedMessage” to True in the XML Disassembler.
4) Make sure the file you dropped has the proper namespace and root element.

To review, in BizTalk MessageType is the TargetNamespace#RootElement.

Here was the exact message I got when I dropped my test file:

The Messaging Engine failed while executing the inbound map
 for the message coming from source URL:"e:\Integration\Inbound\CPChemNew\204\*.xml" 
 with the Message Type "http://abc.com/X12/204/CPChem2#X12_00401_204". 
Details:"Finding the document specification by message type "ST" failed. Verify the schema deployed properly. " 

The message type looked okay.

But what was this "ST" in the second message?


I was converting a regular schema to an envelope schema in order to accomplish debaching. "Body XPath" is a parm you set so that the receive XML pipeline will automatically split the message into multiple messages).

I put the "Body XPath" one element too low. It should have split on X12_00401_204, but actually split the message into an ST, and other similar segments.


Here's what I didn't understand. I'm not sure why, but after debatching, the XML Disasembler on the Receive Pipelines, decides that it needs to verify that the target schema exists as well. Thus, the error on "ST".

How I Solved It

1. I did a test map in Visual Studio and got the results of the test map.
2. And then dropped that into the appropriate Receive Location (different from the one above).
3. Since I had tracking turned on, I check the "Tracked Message Events", and saw multiple "Transmission Failed" and looking at the body of each, I see one file has as the root, one has as the root, and so on.
4. The other thing I should have noticed was that in the error, the message type should have been: "http://abc.com/X12/204/CPChem2#X12_00401_204Looping" instead of "http://abc.com/X12/204/CPChem2#X12_00401_204". That should have hinted to me that maybe the debatching was happening. X12_00401_204Looping and X12_00401_204 were so similar I didn't notice, so lesson learned here is don't assume and be exact.

The file I'm trying to build looks like this:

<ns0:X12_00401_204_LOOPING xmlns:ns0="http://abc.com/X12/204/CPChem2">

In EDI, a customer can send multiple 204s, but we wanted a single file with multiple 204s in it (too complex to explain here).

The next thing I need to do is make sure I have a scheme that matches , and I need to add a namespace to that as well. So more work to be done, but now I'm back on track. What I need is two schemas, and the Envelope schema can import and reference the other one.

Full Error

System.InvalidCastException: Failed to convert parameter value from a String to a IEnumerable`1.
—> System.InvalidCastException: Invalid cast from ‘System.String’ to ‘System.Collections.Generic.IEnumerable`1
[[System.Data.Common.DbDataRecord, System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]]’.
at System.Convert.DefaultToType(IConvertible value, Type targetType, IFormatProvider provider)
at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
at System.Data.SqlClient.SqlParameter.CoerceValue(Object value, MetaType destinationType, Boolean& coercedToDataFeed, Boolean& typeChanged, Boolean allowStreaming)
— End of inner exception stack trace —


We use SQL User-Defined-Types to pass XML data from BizTalk to SQL stored procs.
I had to build a custom EDI schema to change the inbound validation for a field.

In this particular project, the EDI pipeline had “Preserve Interchange” set to true.
I knew there was a map in my project on this data, but the map itself used a special little schema that supported the “Preserve Interchange” format.
So I think I might get lucky, and just be able to deploy the schema.

Well – the map used XSLT, and the XSLT had the namespace of the schema.
So although the map ran, it was generating a call to the stored proc that had no data, i.e. the User-Defined-Type didn’t get mapped under the root element.
That caused the odd validation error above!

In Summary – the namespace in the XSLT did not match the namespace specified in the Party/Agreement configuration.  Thus the output of the map had a root element, but none of the User-Defined-Type elements.

BTDF deploy on local machine in Visual Studio by using “Tools”, “Deployment Framework for BizTalk”, “Deploy BizTalk Solution” failed with the following error in XmlPreprocess.exe

/s:: Argument expects a parameter

What caused the error for me was that I in the SettingsFileGenerator.xml spreadsheet, I had renamed all the “Settings File Names” for each environment.  I switched the “Local Development” back to Exported_LocalSettings.xml and this got around the issue.

Perhaps there is a setting in the .btdfproj file that allows you to specify (override) the local settings name, but I couldn’t find it today.




Error text:

A message sent to adapter “FILE” on send port “spGwCustomers_Caterpillar_EDI210” with URI “C:\Integrations\EDI1\Customers\xxxx\outbound\210\Test_210_%datetime_bts2000%.TXT” is suspended.
Error details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)


The file not found can refer to the map .dll. The error to me is quite misleading, because it implies the directory/filename path listed in the error is the problem.
This can happen to me when I don’t run the MSI (or other deploy process) for a map on one of the BizTalk servers (when you have multiple BizTalk servers in the same group).

It sure would be nice if the error would give the actual missing filename (i.e. the map .dll name).


Got the following error when posting to a BizTalk receive location from SOAP-UI, but could have happened with any type of receive location:

HTTP/1.1 500 Internal Server Error
Content-Type: application/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Thu, 05 Jul 2018 14:07:37 GMT
Content-Length: 2384

<Fault xmlns="http://schemas.microsoft.com/ws/2005/05/envelope/none"><Code><Value>Receiver</Value><Subcode>
<Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">
a:InternalServiceFault</Value></Subcode></Code><Reason><Text xml:lang="en-US">
There was a failure executing the receive pipeline: 
"MyPipeline, etc... Version=, Culture=neutral, PublicKeyToken=1234123412341234"
 Source: "XML disassembler" Receive Port: "rpFrontEnd_TLRGLoadTenderOut_Web" 
 URI: "/TLRG/Shipment/DirectTender.svc" 
 Reason: Finding the document specification by message type 
 "http://myNamespace#MyRootNode" failed. 
 Verify the schema deployed properly.  </Text></Reason><Detail><ExceptionDetail 


This was a conversion from old 2010 system to 2013. On the first pass, I had forgotten a map that trimmed all the fields and removed empty nodes. The map used XSLT, and in the XSLT source, it had the wrong namespace from the old system.

Other Hints

Remember MessageType = NameSpace#Root

  1. Make sure the schema is really deployed (BizTalk Admin console)
  2. Check your spelling carefully, look for typos.
  3. If you have a map in the receive location, make sure the map is really running. I.e. does the messageType of the incoming message match the map. If the map doesn’t match, the incoming message will be passed on and could get this error.
  4. If you have a map, make sure the map has been tested and outputs the correct messageType.
  5. If you are doing JSON to xml (or any other file format to XML, make sure the pipeline is creating the correct messageType.
  6. Of course, make sure you restarted your Host Instances
  7. Check your values in BizTalk Admin before and after each deploy. If you are doing some kind of automated deploy, make sure your bindings for that deploy are current; they maybe resetting some value each time you deploy. In my case, I had a script to export the bindings, but I was actually running a similar script for another project. So everytime I reset the namespace value for the RootNodeNamespace in the JSON pipeline, it was getting reset on each re-deploy.


Microsoft.ServiceModel.Channels.Common.ConnectionException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
—> System.Data.SqlClient.SqlException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

The user was correct, and that was driving me crazy. I had just built the database from a script, and I set and double-checked the security in SSMS for that database.
I’m running on my own VM on my desktop; and the userid is my VM-Name/bts_host_ins (and that’s the user that all the host instances run with).


There could be other reasons for this error, but here was my reason…

My SendPort was pointing to our development system which is on the “DEV” domain, and my VM where I’m testing is on the primary domain.
The fix was just to repoint the SendPort to my local VM which is what I wanted anyway. If I really did want to go to the DEV domain, then I would have to use a user on that domain to run my host instance.


The adapter failed to transmit message going to send port “sp_Test_SFTP” with URL “sftp://sftp.mycompany.com:22/%MessageID%.xml”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.IO.FileLoadException: Could not load file or assembly ‘WinSCPnet, Version=, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ or one of its dependencies. General Exception (Exception from HRESULT: 0x80131500)
File name: ‘WinSCPnet, Version=, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ —> System.Exception: SFTP adapter requires WinSCP to be installed. Please refer http://go.microsoft.com/fwlink/?LinkID=730458&clcid=0x409 . —> System.IO.FileNotFoundException: Could not load file or assembly ‘file:///C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.BizTalk.Adapter.Sftp\v4.0_3.0.1.0__31bf3856ad364e35\WinSCPnet.dll’ or one of its dependencies. The system cannot find the file specified.


I think BizTalk requires a specific older version of WinSCP and you can’t just download the latest one.
This error could also occur if you didn’t copy the file to the proper directly.

I found Michael Stephenson’s BizTalk 2016 SFTP blog, and it had a nice PowerShell script.

I just had to
1) Change directory names (I had a Software directory similar to him, but I had to create a WinSCP subdirectory under it)
2) Then PowerShell with the “Run as Admin” option.

Then the script ran fine, I restarted BizTalk Host Instance, and it got past this error, on to other errors that I’ll blog about in the near future.

By the way, I was able to run in a 64-bit host with no problem.  I remember that in older version of BizTalk the FTP adapter ran only in 32-bit hosts.




Error: Root Element is Missing

InstanceId: d1c2f87c-825b-4c6e-b01c-c93e50d63502
Shape name: msgABCDetail
ShapeId: 33d0d3ac-ae45-408c-8224-f42725877a2b
Exception thrown from: segment 4, progress 22
Inner exception: Root element is missing.

Explanation 1

This error occurs in an orchestration, typically after you have run a map, and the map doesn’t create any output. It basically means your message or map output is empty, and you are trying to convert it to load it into a variable of System.Xml.XmlDocument.

You can simulate the same error in PowerShell like this:

$xmlcontent = $null 
$xml = New-Object -TypeName System.Xml.XmlDocument

Sadly, instead of saying null or empty xml string, it tells you “Root element is missing”.

Now back to my BizTalk scenario. The map is in a construct statement, and presumably the message created in the construct statement should not be empty.

The way to test or fix this is as follows:

1) Obtain a copy of a the message that goes into the map (might have to add debug or write message to disk or trace), and save to disk.

2) Test that message in Visual Studio using the right click “Test Map” option on the map (first set the “TestMap Input Instance” property to the filename you saved from the step above.

3) Typically the issue is a namespace or higher level node is missing. This causes none of the xpaths in the XSLT to match, and thus nothing is generating on the “right side” of the map. When you test the map, the Output window will show something like this: “The output is stored in the following file: xxx.xml”. If you cntl-click on that file, that file will open. In all likelihood it will be empty (blank). [If it has data in it, there is a chance the code you are running doesn’t match the current version of the source code/map you are testing, indicating you might need to redeploy.]

4) To check further, you can also check the file against the schema, to make sure it is valid. This may help indicate an element name or namespace that is wrong that could cause the map to result in empty output. Set the schema property “Input Instance Filename”, then right click on the schema and select “Validate Instance”. If it fails, you might try generating an instance, then use a file compare or your own eyeballs to compare the generated instance to the instance you were validating (experience teaches you what to look for).

Here’s a specific case I dealt with today. My data file had a root element named eisresultset. It was built by xpathing to a node of the data data returned to us by a vendor. Due to the way the vendor packs the data in a generic XmlDoc packet, the WSDL did not build the schemas for us, and I had to do it manually. When I built the schema for esiresultset, I misspelled the root element name and had esiresultset. The reversal of those two letters make a huge difference!

When I validated the data instance against the schema, the output window told me clearly:
e:\MyDir\MySubDir\map_EsiResultSet_To_DBTableMotoDetails_TestIn1.xml: error BEC2004: The ‘eisresultset’ element is not declared.

The second mistake I made, was in my map, I had mapped eisrecord, a separate schema with that repeats inside of eisresultset. So mapping a schema that starts with a higher level element than what I mapped would never result in a good map output.

Explanation 2

If you set an XmlDoc to your message, and then load that XmlDoc with something else, you may be wiping out your message with that next text.

For example, on another date then the original blog post with Explanation 1 above, I was using my own trace to SQL C# routine. I frequently do this:

xmlDoc = msgIn; 
#and then call # that writes to Database Trace 

Then I was testing getting ISA/GS Headers and to test the results I did this:

xmlDoc.LoadXml("<Wrapper><ISASegment>" + strISASegment + "</ISASegment>" + 
               "<GSSegment>" + strGSSegment + "</GSSegment></Wrapper>"); 
#and then call # that writes to Database Trace 

Of course, xmlDoc is an orchestration variable of type System.Xml.XmlDocument.

I lost 2 or 3 hours of work chasing this down, do all the steps I outline in “Explanation 1” above, as those steps showed no problem whatsoever.

So basically, xmlDoc was pointing to the same memory as the message, and loading a new doc on top of it, with a different root element and totally different fields. Thus the map would not match the root elements, and would not create any output.

The solution was to use a separate variable, XmlDoc2 for debugging the ISA/GS headers.