Partager via


La nouvelle transaction ne peut pas s’inscrire dans le coordinateur de transactions spécifié lorsque vous essayez de démarrer une transaction dans MS DTC

Cet article vous aide à résoudre un problème lorsque vous démarrez une transaction dans Microsoft Distributed Transaction Coordinator (MS DTC).

              Version d’origine du produit : Windows
Numéro de la base de connaissances d’origine : 922430

Importante

Cet article contient des informations sur la modification du Registre. Avant de modifier le Registre, pensez à le sauvegarder et assurez-vous que vous savez le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde, la restauration et la modification du Registre, consultez Informations du Registre Windows pour les utilisateurs avancés.

Symptômes

Prenons l’exemple du scénario suivant :

  • Vous disposez d’un ordinateur client qui communique avec un ordinateur serveur.
  • MS DTC est installé sur les deux ordinateurs.
  • Une ou plusieurs des conditions suivantes sont remplies :
    • Vous redémarrez l’un des ordinateurs.
    • Vous redémarrez MS DTC sur l’un des ordinateurs.
    • Les ordinateurs se trouvent dans des domaines différents.

Dans ce scénario, le message d’erreur suivant s’affiche lorsque vous essayez de démarrer une transaction dans MS DTC :

La nouvelle transaction ne peut pas s’inscrire dans le coordinateur de transactions spécifié (0x8004d00a)

En outre, la première transaction échoue. Les transactions suivantes réussissent pendant un certain temps. Toutefois, les transactions suivantes peuvent échouer à nouveau. Si les transactions suivantes échouent, vous recevez le message d’erreur suivant :

La nouvelle transaction ne peut pas s’inscrire dans le coordinateur de transactions spécifié (0x8004d00e)

Cause

Ce problème peut se produire lorsque la connexion MS DTC entre l’ordinateur client et l’ordinateur serveur est fermée. Par exemple, un délai d’inactivité, un appel de procédure distante (RPC) ou le pare-feu peut fermer la connexion MS DTC entre l’ordinateur client et l’ordinateur serveur. Lorsqu’une nouvelle demande de transaction se produit, l’ordinateur client doit rétablir la connexion MS DTC avec l’ordinateur serveur.

Lorsque l’ordinateur client tente de rétablir la connexion MS DTC avec l’ordinateur serveur, l’ordinateur client envoie un paquet. Ensuite, l’ordinateur client attend une réponse de paquet de liaison de l’ordinateur serveur. Par défaut, l’ordinateur client arrête la transaction si l’ordinateur client ne reçoit pas de réponse de l’ordinateur serveur en 4 secondes. La réponse de l’ordinateur serveur peut être retardée en raison de problèmes de latence réseau ou de retards d’authentification. Lorsque la réponse de l’ordinateur serveur atteint enfin l’ordinateur client, les transactions suivantes réussissent.

La première transaction peut prendre beaucoup de temps, puis une demande ultérieure pour effectuer une transaction distribuée peut se terminer immédiatement. Ce problème peut se produire lorsque le côté client de MS DTC rencontre un problème de communication avec le serveur Kerberos (KDC). En règle générale, ce problème se produit si le client et le serveur se trouvent dans des domaines différents qui ont un pare-feu entre eux.

Par exemple, ce problème se produit dans le scénario suivant :

  • Le service web se trouve dans le réseau de périmètre dans un domaine. Le service web doit utiliser des transactions avec un serveur de base de données dans un autre domaine dans un intranet.
  • Un pare-feu se trouve entre le réseau de périmètre et l’intranet. Le délai excessif sur la première transaction se produit car le port UDP (User Datagram Protocol) 88 (Kerberos) est bloqué.
  • La nouvelle tentative et l’intervalle de nouvelle tentative pour la requête Kerberos sont égaux à un délai excessif (plus de 100 secondes).

Résolution

Avertissement

De graves problèmes peuvent se produire si vous vous trompez en modifiant le Registre à l’aide de l’Éditeur du Registre ou toute autre méthode. Ces problèmes peuvent nécessiter la réinstallation du système d’exploitation. Microsoft ne peut pas garantir que ces problèmes puissent être résolus. Vous assumez l’ensemble des risques liés à la modification du Registre.

Pour vous assurer que vous rencontrez le problème décrit dans cet article, vérifiez que le fichier journal de suivi des transactions MS DTC contient les données suivantes :

; eventid=TRANSACTION_PROPOGATION_FAILED_CONNECTION_DOWN_FROM_REMOTE_TM ; tx_guid=f11cd9c9-7b8a-41e3-a904-4840123bacf7 ; » échec de la propogate de la transaction vers le nœud enfant ' ComputerName', car la connexion avec le gestionnaire de transactions distant a été interrompue »

Remarque

Dans ces données, la propogation du mot est une faute d’orthographe pour la propagation du mot. Le mot propogate est une faute d’orthographe pour le mot propagé.

Si le fichier journal de suivi des transactions MS DTC contient ces données, procédez comme suit :

  1. Sélectionnez Démarrer, Exécuter, tapez regedit, puis sélectionnez OK.

  2. Trouvez la sous-clé de Registre suivante :
    HKEY_LOCAL_MACHINE\Software\Microsoft\MSDTC

  3. Cliquez avec le bouton droit sur MSDTC, pointez sur Nouveau, puis sélectionnez Valeur DWORD.

  4. Tapez CmMaxNumberBindRetries, puis appuyez sur Entrée.

  5. Cliquez avec le bouton droit sur CmMaxNumberBindRetries, puis sélectionnez Modifier.

  6. Sélectionnez Décimal.

  7. Dans la zone Données de la valeur, tapez 60.

    Cette valeur augmente la durée pendant laquelle l’ordinateur client attend la réponse de paquet de liaison de l’ordinateur serveur. Cette valeur est le double du nombre de secondes avant que l’ordinateur client arrête la transaction si l’ordinateur client ne reçoit pas la réponse de paquet de liaison. Par exemple, une valeur de 60 est égale à 30 secondes. La valeur 60 est uniquement une valeur recommandée. Des tests supplémentaires sur votre configuration peuvent être nécessaires.

  8. Sélectionnez OK.

  9. Redémarrez MS DTC.

Remarque

Pour le scénario de réponse lente, assurez-vous que les ports requis par l’authentification Kerberos (UDP 88 et TCP 88) sont ouverts lorsqu’un pare-feu est impliqué dans le réseau de périmètre. Les ports UDP 389 et TCP 389 (pour le protocole LDAP (Lightweight Directory Access Protocol) pour rechercher le centre de distribution de clés (KDC) doivent également être ouverts.