Debugging External assembly’s or pipeline components – Attach to Process – which BizTalk process to use?

Posted: March 29, 2010 in BizTalk
Tags: ,

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

  1. Ritesh says:

    How do you debug a pipeline component running on WCF-CustomIsolated host on IIS7 on a Win 2008 64bit env? What is process name to attach on VS debugger?

  2. Hi Ritesh,
    You need to attach to “BTSNTSvc.exe” process, if you have more than one and you don´t know which to choose, select all “BTSNTSvc.exe” process’s
    Another way to debug pipelines is using pipeline.exe utility:

  3. Will says:

    Thanks for the tip – I was also having another pipeline debugging problem that I thought I may share the results of:

    One issue that I ran into was that even when I attached to the correct process (I used sysinternals procexp.exe; not as clean as TASKLIST, but offers much more info, and I tend to gravitate to information overload) I kept getting the following warning upon attaching and no breakpoints were hit:
    “Breakpoint will not currently be hit. No symbols loaded for this document.”

    My build output target (which I had set to the \Pipeline Components folder) had the .dll and corresponding .pdb (“symbols”) file, but apparently it was pulling the code from the GAC (it had previously been GAC’ed) instead of my output folder (check the Modules window during debugging to see where the .dll is loaded from).

    Of course pipeline components don’t usually need to be GAC’ed, but if it had previously been GAC’ed then you can either 1) un-GAC and load from \Pipeline Components and make sure you also have the matching .pdb file or 2) add the matching .pdb file into the GAC

    Just something to look out for.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s