BizTalk and WCF: Consuming a WCF Service, Part 1 – A Look at the Service to be Consumed

BizTalk and WCF: Consuming a WCF Service, Part 1 – A Look at the Service to be Consumed

I thought I would do a series of posts on BizTalk and Windows Communication Foundation (WCF). The main aim of this post is to cement my experiences so far exposing and consuming WCF services using BizTalk. First up (and the focus of this post) is a look at a (very simple) WCF service that will […]
Blog Post by: James Corbould

BizTalk 2013 or 2010 Hosts Crashing

I’ve seen some posts on some discussion boards and blogs and support cases opened on this BTS2013 issue so I just wanted to provide some general information about the problem, what your workaround options are, and details on the fix. 

Problem

Periodically, your BizTalk host process crashes with the following errors in the eventlogs.  Note the error code is 80131544.  If you see the same error with a different code, you’re likely running into a different issue.

Also, notice none of the errors come from event source BizTalk Server.  The ones in the Application event logs come from .NET Runtime and Application Error and the one in the System event logs comes from Service Control Manager.

Log Name:      Application
Source:        .NET Runtime
Date:          9/20/2013 3:47:42 PM
Event ID:      1023
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      servername
Description:
Application: BTSNTSvc64.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FDED170BC1 (000007FDECE00000) with exit code 80131544.

Log Name:      Application
Source:        Application Error
Date:          9/20/2013 3:47:42 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      servername
Description:
Faulting application name: BTSNTSvc64.exe, version: 3.10.229.0, time stamp: 0x50fe567a
Faulting module name: clr.dll, version: 4.0.30319.19106, time stamp: 0x51a512d4
Exception code: 0x80131544
Fault offset: 0x0000000000370bc1
Faulting process id: 0xca8
Faulting application start time: 0x01ceb6394f1dd32a
Faulting application path: C:Program Files (x86)Microsoft BizTalk Server 2013BTSNTSvc64.exe
Faulting module path: C:WindowsMicrosoft.NETFramework64v4.0.30319clr.dll
Report Id: 830374f6-222d-11e3-93f8-00155d4683a2
Faulting package full name:
Faulting package-relative application ID:  

Log Name:      System
Source:        Service Control Manager
Date:          9/20/2013 3:47:43 PM
Event ID:      7031
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      servername
Description:
The BizTalk Service BizTalk Group : BTSOrchHost service terminated unexpectedly.  It has done this 2 time(s).  The following corrective action will be taken in 60000 milliseconds: Restart the service.

Root Cause

There is a change in the .NET 4.5 CLR that results in the BizTalk process crashing during XLANG AppDomain shutdown.  XLANG AppDomain Shutdown is when the .NET AppDomain that contains the Orchestration Engine tears itself down during periods of inactivity or idleness. 

The Orchestration engine’s AppDomain shuts down by default after 20 minutes of idleness (all orchestration instances are dehydrateable) or 30 minutes of inactivity (no orchestration instances exist).

BTW, if you see this same issue in BizTalk 2010, it’s because you installed .NET 4.5 in your BizTalk 2010 environment – which is not tested or supported.  You need to be on .NET 4.0 if you’re running BTS2010.

Update:  BizTalk 2010 CU7 added support for .NET 4.5 so you should not see this issue once you are on CU7 – see Permanent Solution section for details.

Workarounds

The first and easiest workaround is to do nothing.  Note that this crash happens during periods of idleness/inactivity so your orchestrations aren’t doing anything anyway.  Also, Service Control Manager is configured to bring a BTS process up a minute after a crash so the process will come back up just fine and continue to process fine.  The crash won’t happen again until after there is orchestration activity and another period of idleness/inactivity occurs.

Note that if there are other things going on in the same host (like receive or send ports) then I wouldn’t be comfortable letting the host crash since non-orchestration work within the same host could be impacted.  In that case, you can separate out non-orchestration work into other hosts (that’s generally recommended anyway) or you can go with the below workaround. 

Another thing to consider is that, depending on the Windows Error Reporting (Dr. Watson) settings on the machine, these crashes can build up dump files on the drive.  The default location for these would be C:ProgramDataMicrosoftWindowsWERReportQueue.  Check for any subfolders starting with “AppCrash_BTSNTSvc” – you can delete them if you don’t need them.  So if you have limited disk space on the system drive, that might also be a reason to go with the below workaround. 

If allowing the host to crash during periods of orchestration idleness/inactivity is not an option, the workaround is to turn off XLANG AppDomain shutdown.  This is generally safe to do.  The only concern is if you have an orchestration that calls custom code that pins objects in memory to the appdomain (not good in general), then not tearing it down periodically could lead to excessive memory usage.  Still, any 24×7 environment will never have appdomain shutdown happening anyway and I’ve seen a number of environments that have very low latency requirements turn it off (since reloading XLANG engine after periods of inactivity is a perf hit to that first request). 

So, to prevent the crash from happening altogether, here’s what you do:

  1. Go to your BTS folder (default is C:Program Files (x86)Microsoft BizTalk Server 2013)
  2. First, save a copy of the BTSNTSvc64.exe.config file with a new name since we need to modify the original.  (BTSNTSvc.exe.config if it’s a 32 bit host that is crashing – you can check the error message to see if the crash is happening to BTSNTSvc.exe or BTSNTSvc64.exe)
  3. Open the original file in notepad and directly below the <configuration> node, add the following:
     
        <configSections>
            <section name=”xlangs” type=”Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess” />
        </configSections>
     
  4. Then, directly below the </runtime> node, add the following:
     
        <xlangs>
            <Configuration>
                <AppDomains AssembliesPerDomain=”50″>
                                    <DefaultSpec SecondsIdleBeforeShutdown=”-1″ SecondsEmptyBeforeShutdown=”-1″/>
                </AppDomains>
            </Configuration>
        </xlangs>
     
  5. Recycle the host

Permanent Solution

Microsoft has created fixes for this issue in BizTalk 2013 and 2010.

BizTalk 2013:

BizTalk 2010:

BizTalk 2013: BizTalk Documenter – working

BizTalk 2013: BizTalk Documenter – working

Hi folks, while scratching around late on a Sunday night with an all important demo
tomorrow, I realised that a current up to date version of the BizTalk Documenter was
something I didnt have.

I grabbed the source from – http://biztalk2010autodc.codeplex.com and
recompiled for .NET 4.5 x64.

They are just a bunch of files that you can unzip on your BizTalk box and run the
app.

I reckon you’ll need to be Admin or running this in Admin mode to avoid any querks
that happen when you dont have enough permissions.

Enjoy!

Mick.

http://sdrv.ms/1ezuCRV


Blog Post by: Mick Badran

BizTalk and Windows Azure SQL Database

In past I written posts on interaction between BizTalk and Windows Azure SQL Database (former known under SQL Azure) using the WCF-SQL Adapter. I have revisited one of my posts that dealt with calling a stored procedure. To bring back old memories I tried to do same against using BizTalk Server 2013 (this time through using an orchestration and messaging). I have written my experience down in a

Useful BizTalk Server White Papers

BizTalk Server Assessment and Architecture Review Best practices to make a BizTalk assessment and architecture review, includes how to organize good documentation (for all BizTalk aspects, message flows, transformation, technologies stack, infrastructure, network, adapters, disks, connections, configurations and databases) as well as the correct indicators for the whole BizTalk environment. Author : Nino Crudele BizTalk […]

The post Useful BizTalk Server White Papers appeared first on BizTalk360 Blog.

Blog Post by: Poongodi Ramadoss

BizTalk Server 2013: New Adapters Series: SFTP

In march I promised to do a post on the last new adapter released with BizTalk Server 2013: SFTP. I wanted to discuss all the new adapters and did so for the relays, SB-Messaging and WebHttp. I forgot about SFTP. I got reminded of that fact when I read latest TechNet Wiki article by Suleiman Shakhtour.

Excerpt of the article:

In the BizTalk 2010 release, Microsoft enhanced the existing FTP

A few notes from the Hybrid Organisation Event – London

Last week I attended the Hybrid Organisation Event in London. A story on the event can be found on BizTalk360 blog. I enjoyed it and was good to see some friends and my old colleagues Sander Nefs and Rene Brauwers,

After event Sander wrote to two interesting posts on Windows Azure Services Bus after seeing Sam VanHoutte session:

UK Connected Systems User Group – BizTalk Services questions

Using the Windows Azure Service Bus REST API to Send to Topic from Salesforce.com

Using the Windows Azure Service Bus REST API to Send to Topic from Salesforce.com

In the past, I’ve written and talked about integrating the Windows Azure Service Bus with non-Microsoft platforms like Salesforce.com. I enjoy showing how easy it is to use the Service Bus Relay to connect on-premises services with Salesforce.com. On multiple occasions, I’ve been asked how to do this with Service Bus brokered messaging options (i.e. […]
Blog Post by: Richard Seroter