Just when I thought I was on a roll, my unit tests stopped working, all of them. At least when they all fail, and fail in the same way, you know it's not your code that's causing the issue. Switching to running the unit tests in debug showed that they were failing when I was trying to leave the service domain as part of my "database rollback" functionality (idea and code I based my work off of was from a 2004 MSDN article), which uses Enterprise Transactions.
I had a previous issue with MS DTC and my unit tests, but this is different. No helpful messages in the event log (first place I looked this time) on my development server. My laptop, where I am running the unit tests from, have a couple of entries for DistributedCOM but they are kind of vague. I decided to jump over to dtctester and see what that showed.
It hung on "Enlisting Connection in Transaction" for at least 1 minute (I left to get a soda) before finishing. The most recent changes I've made to my development server are:
- Upgrade to BizTalk 2006 R2
- Install .Net Framework 3.5 RTM
- Install Windows Server 2003 SP2
My bet is on a fix in SP2, or the SP2 installer resetting the MS DTC configuration. I found an excellent MSDN article on trouble shooting MS DTC in an effort to verify how I should have MSDTC configured, specifically the security settings. I noticed that mutual authentication was required, and from previous issues with DTC and the fact that my machines are not on a domain, I set this to no authentication and tried again, no go. I did find a new entry in the application event log on the dev server which seems to point with an issue on the dev server itself.
MS DTC is unable to communicate with MS DTC on a remote system. MS DTC on the primary system established an RPC binding with MS DTC on the secondary system. However, the secondary system did not create the reverse RPC binding to the primary MS DTC system before the timeout period expired. Please ensure that there is network connectivity between the two systems. Error Specifics:d:\nt\com\complus\dtc\dtc\cm\src\iomgrsrv.cpp:1318, Pid: 2728
No Callstack,
CmdLine: C:\WINDOWS\system32\msdtc.exe
Nope, it wasn't the dev server. I decided to run dtctester on 2 other computers and they both passed. The first time I ran the tool on one of the computers, I got an error that was very similar. The only difference was the native error. On my laptop (Vista) the native error is -2147168242 and on the other computer it was -2147168220. The issue on the other computer was that I had not setup DTC for network communication.
So now I knew it was an issue with my laptop, which is running Vista. A couple of things I've done recently were:
- Remove VS 2008 Beta 2 and all related components and install RTM
- Install various updates from Windows Update
- Installed VPN software
- Was playing around with network settings trying to get wireless working at my parents over the holidays
- Uninstalled and reinstalled newer version of VMWare
I know I had problems with the firewall before, so I turned off the Vista firewall, and success, dtctester passed. En-enabling the firewall caused the dtctester to fail again. In the simple firewall UI, distributed transaction coordinator was selected. I went back and looked at a post I wrote on our internal network, and I had mentioned that the VMWare network adapters change the zone that the firewall thinks you are in.
Well, I was in the public zone, and couldn't change it. There should have been a Customize option on the Network and Sharing center. I remembered that I had gone into Services, and disabled some that I "thought" I could do without. One of them was Network Location Awareness, which caused Network List Service to fail to start. Once those 2 were running, the firewall knew I was on the private network, and DTC worked again. My firewall exception was for the private network only.
Wow, that was a trip.
Download MS DTC Tester: http://support.microsoft.com/default.aspx?scid=kb;en-us;293799