Posts Tagged ‘Debug’

In the past I publish an article about “An unhandled exception (‘<System.StackOverflowException>’) occurred in BTSNTSvc.exe with the promise that I would explain in detail how I was able to debug the .NET stack using the Microsoft Symbol Server to obtain debug symbol files, and now is the time Sorriso.

Step 1: Prepare the environment for debug (set up the Symbol Server):

First one note: if you are using a Lab environment with Visual Studio, like me, skip step 1 and 2.

  1. Download the Debug Tools:
  2. Install this Debug Tools in: “c:\tools\debug”
  3. Download Sysinternals:
  4. Unzip the tools to: “c:\tools\bin”
  5. Go to “Control Panel -> System -> Advanced -> Environment Variables”control-panel-Environment-Variables
  6. In “System Variables” section, press “New” and add the following variable:
    1. Variable name: “_NT_SYMBOL_PATH
    2. Variable value: “SRV*c:\websymbols*


  1. In the “User variables for user” section, press “New” and add the following variable:
    1. Variable name: “PATH
    2. Variable value: “C:\tools\bin


  1. Press the OK button twice.


Step 2: Prepare theProcess Monitor":
  1. Run procmon.exe
  2. Go to the menu option “Options -> Configure Symbols”
  3. Ensure that the “DBGHELP.DLL” path is equal to “C:\TOOLS\DEBUG\dbghelp.dll” or is one path of the version used in Visual Studio
  4. Ensure that the “Symbol Path” is equal to “SRV*c:\websymbols*
  5. Press OK button


Step 3: Prepare theProcess Explorer":
  1. Run “procexp.exe
  1. Go to the menu option “Options -> Configure Symbols”
  1. Ensure that the “DBGHELP.DLL” path is equal to “C:\TOOLS\DEBUG\dbghelp.dll” or is one path of the version used in Visual Studio
  2. Ensure that the “Symbol Path” is equal to “SRV*c:\websymbols*
  1. Press OK button


Now when the exception occurs, the system will automatically instantiates one Visual Studio instance with the trace .NET stack, giving me the exact point of the problem.



Once again I want to thank Jorge Lourenço for help!

Tags: BizTalk | Debug | .NET

Normally we can debug almost all pipeline components in run-time mode by attaching Visual Studio to “BTSNTSvc.exe” process (see: Debugging External assembly’s or pipeline components – Attach to Process – which BizTalk process to use?)

This is true for components that is running on In-Process Host, the exception is: Custom Pipeline Components that are running on Isolated Host.

One of the differences between Isolated Host and In-Process Host is that an Isolated Host must run under another process, in most case IIS, and an In-Process host is a complete BizTalk service alone.

So, if you are using custom pipelines that are associated, for example with HTTP, SOAP or WCF Adapter, then you need to attach to the proper isolated host process, in this case “w3wp.exe” process.


The application pool process (w3wp.exe) is typically not started until the first request is received.

You can use a browser to access the receive location URL, this should return a WSDL and should cause the “w3wp.exe” process to initiate.

Related articles:

Special thanks

One of the pleasures of trying to help other people’s is that sometimes you learn some things, and this is one of these cases , thanks Ritesh.

Tags: BizTalk | Pipeline | Components | Debug

While trying to debug custom pipeline component using “Pipeline.exe” utility, I keep getting the following error message:

Pipeline file name is already specified
Error 80131600

First of all, to use Pipeline utility to debug custom components you have to edit the properties of you pipeline component project:

  • Select you pipeline component project
  • Right click, and select the option “Properties”.
  • Select the tag Debug
    • In “Start Action”, select the option “Start external program” and select the Pipeline.exe utility
      • Common path: C:\Program Files\Microsoft BizTalk Server 2006\SDK\Utilities\PipelineToolsPipeline.exe
    • In “Start Options” you have to set the “Command line arguments” option:
      • “path to your pipeline.btp” –d “path to your message” –c


  • The path I was specifying to my.btp file wasn’t in quotes and spaces in the path were causing the problem
  • This apply also to the path of my message.


  • Put the path with quotes, my sample:
    • “C:\Development\MyProject\MyPipelines\MyReceivePipeline.btp” -d “C:\Development\MyProjec\Samples\MY_Message.txt” -c

Tags: BizTalk | Pipeline | Components | Debug | Errors and Warnings, Causes and Solutions

We can debug for example, external assembly’s that are called from within a BizTalk process or debugging pipeline components in run-time mode. In Visual Studio set breakpoints in your code. To debug you must attach to the BizTalk process that is running the .Net code.

  • Click on the Debug menu is Visual Studio and select the Process menu item.
  • When the Available Processes dialog opens find and select the BTSNTSvc.exe process.
  • Click on the Attach button.


If we have more than one host instance configured, when we open the debug menu and choose attach to process, it appears all host instance with the same process name (“BTSNTSvc.exe”), like this:

Determining which process to attach to

Now you need to choose the right BTSNTSvc.exe process by determining the process ID.

You can do this by two ways:

  • You can use the TASKLIST command to query the processes. Execute the following command in a command prompt on the remote box:

Tags: BizTalk | Debug | Visual Studio

In my previous post (“BizTalk Orchestration – Orchestration debugging inside Visual Studio”) I explain how to debug BizTalk 2004, 2006 or R2 orchestration in Visual Studio.

So how can I do this in BizTalk 2009 version?

When compiling a BizTalk Server 2009 project in Visual Studio classes (.cs) files are generated for the BizTalk artifacts. Those files are not part of the project and have the extension ‘.cs’, e.g.: .btp.cs, .xsd.cs, .btm.cs

I was expecting also a .odx.cs file, but that is not the case. The CS file for the Orchestration is placed in “objDebugBizTalkXLang” and is called File0.cs. If you open this file you can attach this file to your BizTalk process (where the Orchestration is hosted in) and of course place a breakpoint.

Another difference is that if we have more than one orchestration, when we compile the solution, Visual Studio DON’T generate two CS files (File0.cs and File1.cs), he only generate one, and the two (or more) orchestrations code are inside the file: File0.cs

Inside this file he creates different class according to the orchestration Typename property, sample:

  • sealed internal class BizTalk_Orchestration1 : Microsoft.BizTalk.XLANGs.BTXEngine.BTXService …
  • sealed internal class BizTalk_Orchestration2 : Microsoft.BizTalk.XLANGs.BTXEngine.BTXService…


Tags: BizTalk | Orchestration | Debug | Visual Studio

HAT it’s great for visual debug orchestration and see the track of the workflow, but there are some situations that we wish to could step through orchestration shapes in Visual Studio and see what’s real appends inside the shapes, special in expression shapes and message assign shapes, why this is so difficult to do with BizTalk projects?

So how can I do this?

  1. Go to regedit;
  2. Add a registry key named BizTalkProject at [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0]
    (if you are using BizTalk 2004 and Visual Studio .NET 2003 is HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1)
  3. Next, create a DWORD value named “GenerateCSFile” and set it to 1
  4. Setting the Generate Debugging Information = True property by right-clicking on the project in Visual Studio and selecting Properties → Configuration Properties → Build will ensure that the C# files are created for debug builds in BizTalk 2006.
  5. If you rebuild your project, you will see C# files in your project directory (Click show hidden files and you should see a file named <OrchestrationName>.odx..cs);

Now we can add breakpoints in code inside expression shapes or message assign shapes, to get into debug mode simply attach Visual Studio to the BTSNTSVC.exe process.

Surprisingly not too many people are familiar with it.

I hope this feature come more easily to do in next generations of the product, in other words, with special highlight.

References: Pro BizTalk 2006 and Professional BizTalk Server 2006

Tags: BizTalk | Orchestration | Debug | Visual Studio

This is a great feature, in most case overlooked, because maps can become very large, to the point that is difficult to read, very difficult to maintain and detect some problems.

For many, the ability to debug maps is a new feature in BizTalk 2009, because finally it has particular emphasis in Menu, but is not true, BizTalk 2006 and R2 have the same feature.

Debugging maps in BizTalk 2009

  • Right-click in map file, and now you have a new Item “Debug Map”, next to “test Map” and “Validate Map” items

You will get the possibility to debug the actual XSLT that BizTalk generates and also possible to debug scripts, functoids and other custom code.

Debugging maps in BizTalk 2006/2006 R2

Visual Studio 2005 has a great feature that enables you to debug BizTalk Map:

  • Right click the BizTalk map and select “Validate Map”
  • In the output window you’ll see a link to the .xsl, click on the link to bring it up in VS
  • Right click the .xsl and select “View Source”
  • At that point you can set break points in your .xsl
  • Then select”XML / Debug XSLT” – at which point you’ll be able to step thru the XSLT

Tags: BizTalk | Map | Debug