This article was previously published under Q327815
This article has been archived. It is offered "as is" and will no longer be updated.
If you apply Microsoft Windows 2000 Service Pack 3 (SP3) to a clustered Windows 2000 Server, calls that are made to the MSMQMessage.Send() method or to the MSMQQueue.Receive() method fail. You receive one of the following errors:
Unable to connect to Transaction Controller
Cannot connect to MS DTC
A connection cannot be established with the Distributed Transaction Coordinator
These errors are the result of Microsoft Message Queuing generating the following MQ_ERROR_DTC_CONNECT error:
MQ_ERROR_DTC_CONNECT = -1072824244 (0xC00E004C)
The Send method of the MSMQMessage object sends a message to a destination queue. The Receive method of the MSMQQueue object retrieves the first message in a queue, and then removes the message from the queue when the message is read.
By default, the Send method and the Receive method use a MQ_MTS_TRANSACTION transaction constant. This constant specifies that the call is part of the current Component Services (COM+) or Microsoft Transaction Server (MTS) transaction. Therefore, when these methods are called, the parent Message Queuing COM object tries to enlist in any calling transactions, and then continues under the context of the calling transaction. If these methods are not called from the context of a transaction, then they continue non-transacted.
Before the release of Windows 2000 SP3, if the Send method and the Receive method were called with the MQ_MTS_TRANSACTION parameter under the context of a transaction, the methods succeeded. This occurred even if the methods could not enlist in the available transaction because of a Distributed Transaction Controller (DTC) failure. Generally, this is not a problem, because on a non-clustered Windows 2000 Server, these methods cannot be invoked unless the DTC service starts. Message Queuing depends on the DTC Service.
However, this behavior is problematic if MSMQMessage.Send() or MSMQQueue.Receive() is called from a Message Queuing COM object that is derived from a clustered Message Queuing Resource. A clustered Message Queuing Resource does not depend on the DTC Service running. The DTC Service can be shutdown during cluster failover, or for other reasons.
Transaction semantics fail for the MSMQMessage.Send() method as follows:
If the DTC Service is shutdown, the MSMQMessage.Send() method is called under the context of a transaction. A subsequent attempt to abort the send is made by using the COM+ SetAbort() method. The attempt to abort fails, and the sent message is not removed from the local destination queue or the local outgoing queue. This does not cause data loss, but it does break transaction semantics.
Transaction semantics fail for the MSMQMessage.Receive() method as follows:
If the DTC Service is shutdown, the MSMQQueue.Receive() method is called under the context of a transaction. A subsequent attempt to abort the receive is made by using the COM+ SetAbort() method. Data loss can occur. If a call to MSMQQueue.Receive() is made, the received message is removed from the local queue. If a transacted call to MSMQQueue.Receive() is aborted by using SetAbort(), the message is placed back in the queue from where it was originally removed. If a transacted call to MSMQQueue.Receive() is made and subsequently aborted, and the DTC Service is unavailable, SetAbort() fails, and data loss occurs. The message is not placed back in the queue from where it was originally removed.
In Windows 2000 SP3, if the DTC Service is not available and you call MSMQMessage.Send() and MSMQQueue.Receive(), the methods always fail. This change restores correct transaction semantics, but it also causes any non-transacted calls to these methods to fail if the DTC Service is not available.
Service Pack Information
To resolve this problem, obtain the latest service pack for Microsoft Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
260910 How to Obtain the Latest Windows 2000 Service Pack
A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next that contains this hotfix.
To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:
NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
The English version of this fix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.