Posted on

Debug a process on a remote machine not having Visual Studio installed

This article will explain how to do remote debugging with Visual Studio.

I had to debug a BizTalk application that is running on a remote integration server on which Visual Studio is not installed. Actually, the remote server was a Virtual Machine but that does not change anything.
I took the following steps to be able to debug the remote BizTalk process from my development machine on which Visual Studio is installed:

  1. Copy the Remote Debugger folder from the development machine (having Visual Studio installed) to the remote machine. If you don’t find it, its location can be found from Visual Studio’s start menu. For VS 2005, VS 2008, VS 2010 it respectively is:
    1. <Program Files>\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\
    2. <Program Files>\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\
    3. <Program Files>\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\

    The <Program Files> token is Visual Studio installation folder which is by default C:\Program Files (x86)\ on 64 bit machines and C:\Program Files\ on 32 bit machines. Note that on 64 bit machines, VS 2005 has the 64 bit remote debugger in C:\Program Files\ and the 32 bit debugger in C:\Program Files (x86)\. VS2010 has all the debugger versions under C:\Program Files (x86)\.

  2. Start Visual Studio Remote Debugging Monitor on the remote machine. The process is called msvsmon.exe. I executed it with the “Run as” option using the domain user name that I use on my development machine to avoid credential issues and to give unrestricted access to the debugger process.
    msvsmon.exe run as
  3. After the remote debugging monitor process is started, copy the Server Name in the clipboard or in notepad. The Server Name is found by clicking Tools -> Options. The remote debugging monitor server name has the following format: DomainName\UserName@MachineName.
    msvsmon.exe Visual Studio Remote Debugging Monitor
  4. Copy the necessary libraries and symbol files (.dll and .pdb) in a directory on the remote machine. For the sake of this example let’s put them in C:\Code\Debug
  5. Configure Visual Studio on the local development machine so that it can instructs the remote debugging monitor on where to find the symbol files (.pdb). To do that, open Visual Studio and go to Tools -> Options -> Debugging -> Symbols and set the path where msvsmon.exe can find the pdb files on the remote machine. It is C:\Code\Debug in our example.
    Visual Studio Options Debugging Symbols Location
  6. Attach the remote process to debug by Visual Studio’s debugger. When the project is loaded in Visual Studio and breakpoints are set, go to Debug -> Attach to Process. In the Qualifier field, put the Server Name published by the remote debugging monitor that we took note of in step 3. Click refresh so that the processes of the remote server are displayed.
    Visual Studio Debugger Attach To Remote Process
  7. Select the process that you want to debug and click Attach. In our case we want to debug a BizTalk application so the BizTalk process (BTSNTSvc.exe) was chosen. Confirm “Attach” on the security warning dialog.
    Visual Studio Debugger Attach To Remote Process Warning

That’s it, it is now possible to debug on the remote server! For BizTalk scenarios this can prove very powerful to debug orchestrations when the Orchestration debugger is not enough or when we want to debug a .Net library that is loaded as part of some BizTalk processing (pipelines, orchestrations, maps …).

Posted on

How to run the BizTalk WCF Service Publishing Wizard on remote BizTalk Server

I have a peculiar development environment where Visual Studio and the BizTalk SDK is on my development machine but the actual BizTalk Server instance is on a remote machine (it is actually a Virtual Machine).

As the  BizTalk WCF Service Publishing Wizard is available only where the BizTalk SDK is installed (the development machine) and as it needs access to the BizTalk hive of the registry which only exists where the BizTalk Server instance is installed; we need to export that hive from the remote BizTalk machine and import it in the registry of the development machine (where the wizard runs).

With that registry hive imported on the development computer, the BizTalk WCF Service Publishing wizard will be able to find the SQL Server on which the Management Database runs and thus find the various application installed. It will hence be able to create the various ports generated by the wizard.

The registry hive is the following: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration.
At the time of writing, this was valid from BizTalk 2006 R2 to BizTalk 2010.

BizTalk Administration Registry Hive

Posted on

How to script data – generate insert T-SQL statements from existing data

I found this script that is able to generate insert T-SQL statements for data already existing in a database table. The script is packaged into a stored procedure and is thus very convenient to use.
It can reveal very useful when creating scripts for database initialization when packaging the release of a database driven application or moving some data to a new environment.

Developers do not always have access to all the different environments but sometimes still need to package data deployment scripts for those environments. Most often this will apply to lookup tables such as a lookup tables containing configuration values of an application which can potentially change with every release of an application. It could also apply to simpler cases such as a country code lookup table. Anyways, with this script, it will just take you seconds to generate all the insert statements into an SQL script that you can release with other deliverables (libraries, stored procedures…) to the release manager in charge of updating the application on the live environments.

The strong points of this script are that it handles identity column as well as computed columns and can script data for both views and tables. As this script is so useful for me, I backed-up the stored procedure scripts would the original link be one day broken:

I do not have SQL 2008 yet so I could check if the script works for SQL 2008. I guess that it might as SQL Server didn’t change as dramatically between the 2005 and 2008 version as it did between the 2000 and 2005 version. Anyway if someone tries it, please feel welcome to let me know about it in a comment 🙂

Note that commercial products are available would you need fancier data scripting features.

Posted on

Regular expressions tool designer

Regular expressions are very useful but as I do not have to use them a lot, I often forget the exact syntax required for my particular need.
So today I would like to share a tool to build regular expressions which I have been using many times over, the Regular Expression Designer of Rad Software.

The tool is free, easy to use but yet powerful and intuitive. The contextual help is very short but just perfect and straight to the point for someone who already has previous regex experience. If you are a total newbie in regular expressions, you should read some short introductory material beforehand.

Posted on

Error configuring BizTalk Server 2006

Today I had quite some troubles installing BizTalk Server 2006. As I have previously installed BizTalk many times without being stuck on a problem for so long, I thought I would blog about it. Who knows, it might help some other soul encountering the same issue.

My configuration was the following:

  • 1 Windows Server 2003 64-bit running SQL Server 2005.
  • 1 Windows Server 2003 64-bit with BizTalk Server 2006 installed but not yet configured.

Both machines had MSDTC and COM+ installed and running, a pre-requisite to install BizTalk on a multiple-server environment.
All the BizTalk Users as well as the Windows Account used to install BizTalk had the necessary rights and belonged to the necessary Groups. See a previous post of mine for more information; Biztalk 2006 multi-server installation guide.

So, after having installed BizTalk Server 2006, the BizTalk Server needs to be configured by using the BizTalk Server Configuration tool and there the weirdest thing happened: it failed, but not completely! Enterprise SSO (Enterprise Single Sign-On) and Business Rules Engine (BRE) components were configured successfully while Group and BizTalk Runtime failed.
Thinking I made some human mistake in the configuration, I retried 2 times but the same problem happened. On a side note, before retrying to configure BizTalk, I had to manually delete the BizTalkMgmtDb as it was created even as the configuration step creating that DB failed.

I then read line by line the log file produced by the configuration tool and searched for the source of the problem. I will paste here the relevant parts:

[1:57:09 PM Error ConfigHelper] [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
[1:57:09 PM Error ConfigHelper] SQL error: 08001 Native error code: 17
[1:57:09 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(1176): FAILED hr = 80004005
[1:57:09 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(918): FAILED hr = 80004005
[1:57:09 PM Info ConfigHelper] Did not find existing database: BizTalkMgmtDb on computer:
[1:57:09 PM Info RuleEngineConfig] Management database (server = , database = BizTalkMgmtDb) doesn’t exist

With this information in hand, I suspected something was wrong with the credentials and I checked all the Users and Groups in Active Directory and also checked that I was admin of the SQL Server machine but everything looked ok. I nevertheless re-tried the configuration a few times, being extra careful with every setting but unsuccessfully. I then moved on to next problem in the log file.

[2:08:41 PM Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\service.cpp(729): FAILED hr = 80070421
[2:08:41 PM Warning ConfigHelper] The account name is invalid or does not exist, or the password is invalid for the account name specified.
[2:08:41 PM Warning ConfigHelper] Failed to validate service credentials for account: %1
[2:08:41 PM Info BtsCfg] Check Your NT Account Specification

Here the configuration log complains about Windows Credential issues again. Everything was pointing out to Active Directory, this would reveal to actually point me in the wrong direction. So, as I could still not find any problem in AD, I moved on to the next problem I could find in the log:

2008-09-12 14:13:16:0075 [INFO] WMI Deploying ‘C:\Program Files (x86)\Microsoft BizTalk Server 2006\Microsoft.BizTalk.GlobalPropertySchemas.dll’
2008-09-12 14:13:22:0184 [WARN] AdminLib GetBTSMessage: hrErr=80070002; Msg=The system cannot find the file specified.;
2008-09-12 14:13:22:0184 [WARN] AdminLib GetBTSMessage: hrErr=c0c02560; Msg=Failed to read “KeepDbDebugKey” from the registry.
The system cannot find the file specified.;
2008-09-12 14:13:22:0184 [INFO] WMI Error occurred during database creation; attempt to rollback and delete the partially created database’ny-agbdb-301\BizTalkMsgBoxDb’

Two points here:

  • The file “T:\Program Files (x86)\Microsoft BizTalk Server 2006\Microsoft.BizTalk.GlobalPropertySchemas.dll” was present on the file system so it didn’t seem there was anything I could do about it.
  • The key “KeepDbDebugKey” did not exist in the registry of running healthy BizTalk systems so I supposed this registry key exists only temporarily during the BizTalk configuration procedure.

I then moved on the next potential problem in the log file:

2008-09-12 14:14:02:0465 [ERR] WMI Failed in pAdmInst->Create() in CWMIInstProv::PutInstance(). HR=c0c025b3
2008-09-12 14:14:02:0465 [ERR] WMI WMI error description is generated: Exception of type ‘System.EnterpriseServices.TransactionProxyException’ was thrown.

Here the configuration tool log entry complains about a Transaction from the System.EnterpriseServices library. As this package refers to Distributed Transactions (MS DTC), I doubled checked that MS DTC was running well on both machines, checked firewall configurations but all the necessary ports were open.
I then started to try to troubleshoot DTC following the MSDTC troubleshooting guide from Microsoft and found a utility called dtctester that can be downloaded from the KB 293799.

The dtctester test failed and so I was now sure that the problem was related with DTC. I re-checked the firewall settings, checked the dual network adapter and the DNS as advised by Microsoft and found out that the problem lied with the DNS having some wrong reverse mappings (IP address -> hostname mappings).

As a corollary, notice that the only log information that proved to point me to the actual source of the problem were log entries with the string [ERR] in their header. All others had either [INFO] or [WARN].

To conclude, I would advise to:

  • Use dtctester before operating a BizTalk multi-server installation.
  • When running into problems, look first at the log entries having either the [ERR] or Error string in their header – It indeed seems there are two different formats of log entry header in the log file produced by the Configuration tool. While looking first for the Error type of log entries sounds obvious, it seems that not many people are aware of the log entry header formats and the log entry types generated in the log file.