BizTalk debugging with DebugView

First of all, happy new year 2008 :D

It's been a while since i did the the last blog.
But now since the current project is in the user testing phase, i guess i can post some articles about the interest things i found lately ;)

Since I moved to the new company, I have been working with BizTalk 2006, Oracle9i. So you will find more things about these 2 in my following posts ;)

Let's start with BizTalk debugging. One thing about developing biztalk application is that we will likely to spend more time in the testing rather than creating the orchestration. And the tricky part of it is that the debugging part is not as easy as we have in other .net application types.

Previously, I worked before with BizTalk 2004 about 1+ year ago, we used the file or event log to dump all the debugging output.
But now, life is much easier since i found DebugView. It will output all the trace and debug into the output window of the tool, which makes easier to debug/trace compared to the other methods (file - have to refresh/reopen the file, eventlog - have to move up and down to see each trace/debug item). And please note that this tool can be used for any type of applications, not only for BizTalk.

Below is the sample flow :
I put several debug / trace in the web application, BizTalk orchestration and the web services.
For example :

System.Diagnostics.Debug.WriteLine(varXMLSOAPHeader.OuterXml, "ConsumeWSOrchestration");

System.Diagnostics.Trace.WriteLine("Finish constructing WS message", "ConsumeWSOrchestration");

As you can see in the debugview screen shot below, it will output each debugging / tracing in the output window when the application is running.

How to decide whether using Debug or Trace?

• Debug : dump everything and as many as you want in the orchestration , such as message content, variables, etc.
• Trace : to monitor the orchestration flow, put the information as simple as possible. For example, we have a decide shape with 3 branches, i will use trace to inform me which branch the instance is actually going into.

Do we have to remove all the debug & tracing manually when deploying the orchestration to production? NO :

1. By default debug & trace will be enabled in the Debug compilation mode, and only trace will be enabled in the Release compilation mode. (you should be able to change this in the project build properties).
2. Make sure that you compile the DLLs with Release mode for production (so the debug symbols will not be included).

Design Consideration :
It will be better if instead of calling the System.Diagnostic class directly, you encapsulate the debug / tracing method with a helper class.

The benefit :

1. Maintainability
2. You can control the behaviour of debug / trace. E.g : add output to other channels such as file, event log

I have a helper class with a static method below which will handle the debug / trace logic

public static void Log(string appName, string orchestrationName, string body, LogType lt)
{
//LogToDebugView(appName, orchestrationName, body, lt);
//LogToEventLog(appName, orchestrationName, body, lt);
LogToFile(appName, orchestrationName, body, lt);
}

So i just need to call the method to debug / trace like this :

Logger.Log("appName", "orchestrationName", "This is a debug", Logger.LogType.Debug);

Normally, in production, we will use file / event log output not the debugview for administrative purposes.

Direct Link to download the DebugView :
http://download.sysinternals.com/Files/DebugView.zip

Overview of DebugView :
http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx

No installation needed, just unzip the file and you are ready to go ;)

Note : Some of my friends got often hang issue with their PC when starting the debugview v4.73, after downloaded and using the newer version v4.74, they haven't encountered any hang issue since then and they are "attached" to the tool like I am :P

**Update : A nice feature of DebugView is Remote Monitoring. This is quite useful to monitor the applications when deployed in the DEV, SIT, UAT servers, so you don't even have to login to the server itself to see the dumps.

Find application with debug set to true using WinDbg

Actually I just found out about this about always set the debug configuration to false several months ago.
At that time we were having memory problems with our servers, asp.net worker process (aspnet_wp.exe) recycles very frequently (several times / day). Because our servers have a lots of applications, probably around 100+ applications (asp legacy + asp.net), and from our team, we only manage 2 applications at the servers (and very little information about who's the owner of the other applications), we decided to ask for M... (you know who) Support Team (MST) for help.
So we collected several dump files and sent them to the MST. The first advice we received from them was to set all the debug switch to false in the web.config for all applications, and they sent the list to us. Actually at that time, I was thinking, hhhmmm... is this possible? how can this relate to the memory problem? but in the end we followed the suggestion and we modified several hundreds of web.config files in the servers :P

For more information about this debug=true setting will cause, you can find in the Scott Guthrie's Blog : http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx

When i received the list of the applications which have debug set to true, i was kind of interested how they can get this information from the dump files, whether there's a command line for this, or they already have a script to run with the dump files. So i browsed and browsed the internet about this, and gradually i know a little bit about how to get process the dump files. But very unfortunate, i was not able to find out how to get the information about debug=true at that time, until several days ago where we got another server memory problem, so i have a chance a play around with the windbg again hehehe :P

So the steps are quite easy :
1. Load the dump files with windbg
2. Load the sos.dll (.load clr10\sos.dll)
3. Execute !FindDebugTrue
Hopla, it will list all the applications with debug set to true, quite simple rite :P
you can find more help information with !help command

Note : For a memory leak problem, there's a useful tool named Debug Diagnostic Tool from Microsoft, you can find more information in here : http://blogs.msdn.com/debugdiag/

Addition at 20071010 : You can find very good information regarding to the .Net memory debugging in Tess's Blog site (http://blogs.msdn.com/tess/default.aspx)