In September, my employer Tier 3 rented a house in St. George, Utah so that the Engineering team could cohabitate and collaborate. The house could accommodate 25 people, and we had anywhere from 8-12 folks there on a given week. This was the first time we’ve done this, and the concept seems to be gaining […]
Blog Post by: Richard Seroter
While on holidays full of fishing, camping and swimming I thought I’d give my Telstra
4G box a crack on a speed test.
Results are MUCH BETTER than I get at home! Maybe I’ll just have to be deserted for
a long while’WilsonWilsonwhere are you Wilson?’
Blog Post by: Mick Badran
This post is the nineteenth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013. This week I wanted to highlight something about the integration of the ESB Toolkit 2.2 within the installation media of BizTalk Server 2013, but I didn’t want the […]
Blog Post by: Nick Hauenstein
View the session of Sam Vanhoutte on CloudBurst, available on the Channel9 platform. The sessions handles topics around Azure, Service Bus, SQL Data Sync & AD integration.
This post builds on part 1 of this series looking at BizTalk and WCF. The previous post gave an overview of the RandomPresentWCF service, discussing design considerations, hosting and testing using SOAPUI. In this post, we will examine how to consume the web service using the BizTalk WCF Service Consuming Wizard. The next post will […]
Blog Post by: James Corbould
Tips and tricks for BizTalk monitoring with PowerShell. In this blog post I explain how you can use PowerShell to monitor a frequently failing receive location in BizTalk 2006.
Way back in June i started on a journey to teach myself about Azure BizTalk services whichwas is in preview. At that time i started rolling my own following the first tutorial here. I decided to document my journey because it may help someone else or help me understand where I went wrong. I got […]
Blog Post by: mbrimble
I thought it would be wise to create a post that can serve as a continually updated index of the articles that I have written within the BizTalk Server 2013 New Features Series here on the QuickLearn Team Blog. This post is that listing, and it also includes links to the code developed for each […]
Blog Post by: Nick Hauenstein
All VS developper meet this problem, when you check-in on a work item, by default it resolve it. To clear this issue, go to regedit and update this specific key in VS 2010 [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior] "ResolveAsDefaultCheckinAction"="False" In VS 2012 [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior] "ResolveAsDefaultCheckinAction"="False"
Blog Post by: Jeremy Ronk
I’ve seen some posts on some discussion boards and blogs and support cases opened on this BTS2013 issue so I just wanted to let everyone know that Microsoft is aware of the problem and working on a permanent solution.
I also wanted to provide some general information about the problem and what your workaround options are in the short-term.
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 2013\BTSNTSvc64.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.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.
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.
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:\ProgramData\Microsoft\Windows\WER\ReportQueue. 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:
Microsoft is working on a permanent solution and I’ll update this page once it is available.
Blog Post by: ShaheerA