Indépendance vis-à-vis des autres composants

Les données d’erreur étendues sont utiles même lorsque le serveur ou l’application via lequel la chaîne passée ne reconnaît pas les données d’erreur étendues ou n’en tire pas parti. Les approches recommandées pour de telles situations sont fournies à la fin de cette section.

Les données d’erreur étendues sont plus utiles lorsque des applications ou des serveurs utilisant RPC tirent parti des informations d’erreur étendues. Lorsque vous examinez un code d’erreur RPC_S_* et que les serveurs ou applications impliqués ne rendent pas les données d’erreur étendues disponibles, envisagez les approches suivantes :

• Prenez un sniff.

  Reproduire le scénario tout en prenant le sniff. Le sniff du câble contiendra les données d’erreur étendues.

• Examinez-le à partir du débogueur.

  Si le fait de détecter le problème ne fonctionne pas, car l’appel est local ou parce que l’erreur provient localement, attachez un débogueur au processus qui retourne l’erreur et placez un point d’arrêt immédiatement après l’appel RPC générant l’erreur. RPC indique souvent des erreurs en lisant des exceptions. Par conséquent, si vous recherchez l’erreur 1825 (RPC_S_SEC_PKG_ERROR), activez l’exception 1825 et lorsque le débogueur interrompt cette exception, examinez les informations d’erreur étendues pour le thread.