locked
MSDTC problems

    Question

  • Hi everyone,
    I am having some trouble with the DTC on a client machine and need help to get it working.  The problem started while doing some experimenting with the new WCF stuff, but has evolved into a simple client side dtc problem.  In a nutshell, I can't get dtctester utility to work. 

    Some interesting points:
    * I am running winxp sp2 on both client and server
    * server is running SqlServer 2000
    * both computers are in same domain
    * several other computers in the same domain can run both my wcf transaction code and the dtctester util without problem
    * my local firewall is turned off
    * server firewall is turned off
    * security config for dtc on both machines set to allow everything (all check boxes are checked) with No Authentication Required
    * Based on an old blog post from Florin Lazar, I have checked the RestrictRemoteClient registry key and it is set to 0
    * I have rebooted all machines in question after changing dtc security settings
    * wcf transaction code runs fine on my machine if I point it at a local database.

    Now, the question is, what else is there?  The dtctester fails every time with very ambiguous error information.  There is the bit about WINS/DNS entries or "Misconfigured network" but I don't really know how to go about checking those.  The failure returned from dtctester is the standard "Invalid cursor state" that I've seen on a variety of MSDN pages:

    Error:
    SQLSTATE=24000,Native error=0,msg=[Microsoft][ODBC SQL Server Driver]Invalid cursor state

    Any ideas what to do next? 

    Regards,
    Brett Hardman

    Tuesday, June 6, 2006 5:28 PM

Answers

All replies

  • Here is the entire list of errors from dtctester:


    Error:
    SQLSTATE=25S12,Native error=-2147168242,msg='[Microsoft][ODBC SQL Server Driver] Distributed transaction error'
    Error:
    SQLSTATE=24000,Native error=0,msg=[Microsoft][ODBC SQL Server Driver]Invalid cursor state

    Tuesday, June 6, 2006 5:38 PM
  • Hi,

    Can you also try running the DtcPing tool: http://blogs.msdn.com/florinlazar/archive/2005/09/16/469064.aspx and post back the output from it?

    Can you ping the two machines using the machine name (instead of using the IP address)? Back and forth?

    Cheers!

    Tuesday, June 6, 2006 11:48 PM
  • Hi Florin,
    As far as I understand, the ping is useful mostly in firewall situations, which is not the case here.  We have an open internal environment.  Nevertheless, I used the following batch script:

    echo off
    REM Usage pingtest OtherMachineName
    REM Must use a machine name and NOT an IP address
    ping -n 1 %computername%
    ping -n 1 %1
    ipconfig /all
    echo on

    to try pinging both from my machine to the server and the other way around.  Results were successful on both counts (I can post the output if it helps), so communication between boxes looks ok.  Anyway, I'll try the DtcPing tool just in case and post back shortly.

    Also, I did an sql trace on the server to see what I could find out about the transactions.  They look as if they are opened and closed.  Its just that nothing happens in the meantime.

    Anything else to check?

    Regards,
    Brett
    Wednesday, June 7, 2006 8:28 AM
  • Ok so the RPC call from my machine to the test server was sucessful.  The RPC call back from the test server to my machine was NOT successful.  Here is the DTCPing error output from the log:

    Problem:fail to invoke remote RPC method
    Error(0x6BA) at dtcping.cpp @303
    -->RPC pinging exception
    -->1722(The RPC server is unavailable.)
    RPC test failed

    I've checked the results on another machine (where the dtctester works fine) and they are the same, so I assume no real news here.

    Wednesday, June 7, 2006 12:05 PM
  • Well, the error seems to be at RPC level, before MSDTC gets into the picture.

    If you are sure that network transactions (Allow inbound and Allow outbound are selected) are enabled and the firewall is off, then you have an RPC issue. Try a few articles related to RPC: http://search.msn.com/results.aspx?q=troubleshooting+RPC+errors+site%3Asupport.microsoft.com&FORM=QBRE

    Also, make sure you don't have an antivirus or anti-spyware preventing your computer to receive RPC calls.

    HTH

    Thursday, June 8, 2006 7:49 AM
  • Hello there,

    I am also facing the same problem. The server and Client configuration are also same as mentioned the first post with a small difference...I am using SQL Server 2005.

    Here are my DTCPing results :

    Server:

    ++++++++++++++++++++++++++++++++++++++++++++++
         DTCping 1.9 Report for IS2 
    ++++++++++++++++++++++++++++++++++++++++++++++
    RPC server is ready
    ++++++++++++Validating Remote Computer Name++++++++++++
    02-01, 12:18:47.625-->Start DTC connection test
    Name Resolution:
     HP-->192.168.100.10-->HP
    02-01, 12:18:50.281-->Start RPC test (IS2-->HP)
    Problem:fail to invoke remote RPC method
    Error(0x6BA) at dtcping.cpp @303
    -->RPC pinging exception
    -->1722(The RPC server is unavailable.)
    RPC test failed
    02-01, 12:19:07.250-->RPC server:IS2 received following information:
     Network Name: IS2
     Source  Port: 1676
     Partner LOG: HP2252.log
     Partner CID: 241469F8-2970-4CC1-9210-E55DF79F7C9A
    ++++++++++++Start Reverse Bind Test+++++++++++++
    Received Bind call from HP
     Network Name: IS2
     Source  Port: 1676
     Hosting Machine:IS2
    02-01, 12:19:07.437-->Trying to Reverse Bind to HP...
     Test Guid:241469F8-2970-4CC1-9210-E55DF79F7C9A
    Name Resolution:
     HP-->192.168.100.10-->HP
    Error(0x6BA) at ServerManager.cpp @453
    -->RPC reverse BIND failed
    -->1722(The RPC server is unavailable.)
    Reverse Binding to HP Failed
     In  GUID
     Out GUID
    Reverse BIND FAILED
    Session Down

    Client:

    ++++++++++++++++++++++++++++++++++++++++++++++
         DTCping 1.9 Report for HP 
    ++++++++++++++++++++++++++++++++++++++++++++++
    RPC server is ready
    ++++++++++++Validating Remote Computer Name++++++++++++
    02-01, 12:18:43.828-->Start DTC connection test
    Name Resolution:
     IS2-->192.168.100.12-->IS2
    02-01, 12:18:48.343-->Start RPC test (HP-->IS2)
    RPC test is successful
     Partner's CID:20D63F0B-0073-4675-A9C3-22D5E5EED21E
    ++++++++++++RPC test completed+++++++++++++++
    ++++++++++++Start DTC Binding Test +++++++++++++
    Trying Bind to IS2
    02-01, 12:18:48.437-->HP Initiating DTC Binding Test....
     Test Guid:241469F8-2970-4CC1-9210-E55DF79F7C9A
    Binding call to IS2 Failed
     In  GUID
     Out GUID
    Session Down

    Any kind of help will be appreciated.

    Thanks

    Vinay Pugalia

     

     

    Thursday, February 1, 2007 6:56 AM
  • I have got my problem solved.

    Please visit http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1282772&SiteID=1&mode=1 for further details

    Friday, March 30, 2007 5:44 AM
  • i found this page while trying to solve my com+ problem too. to share, this solves the problem

     

    This article Helps:

    http://blogs.msdn.com/b/florinlazar/archive/2005/09/16/469064.aspx

     

    Most common errors that block MSDTC connectivity in a network are:
     1. MSDTC Security settings are not configured properly:
    http://blogs.msdn.com/florinlazar/archive/2004/06/18/159127.aspx

     

     2. MSDTC is not in the exception list in the firewall

     3. The two machines involved in the transaction cannot see each other by the NetBIOS name. Try ping-ing the machines by name. If that fails, MSDTC will fail. You can solve this by updating your system32\drivers\etc\hosts file.

    This was How MY problem was fixed!!
    on the web-server it is able to ping the db server (as host) has the setting, but DB server cannot ping the webserver, so modified the host on DB server, and problem is immediately fixed.

     

     

     4. If the machines were imaged improperly, the CID for MSDTC under HKEY_CLASSES_ROOT\CID may be the same on the two machines, while they need to be unique. The KB 306843 mentioned above gives the instructions to correct this issue.

    Wednesday, June 1, 2011 2:08 AM