Votre navigateur n’est pas pris en charge

Vous devez mettre à jour votre navigateur pour utiliser le site.

Mettre à jour vers la dernière version d’Internet Explorer

STOP 0xEFFFFFFF exception dans les serveurs OLE à plusieurs clients

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

La version anglaise de cet article est la suivante: 195469
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Symptômes
Lorsque plusieurs clients accèdent simultanément à une absence du serveur COM de processus, les appels de client peuvent échouer inopinément. Débogage du serveur au cours de ce type de défaillance montre que le serveur est levée d'exception 0xEFFFFFFF.

Reconnaissant ce problème peut être difficile car le client et les applications serveur peuvent continuer à s'exécuter. En particulier, cette exception n'entraîne pas directement de à l'origine du serveur ou au client de taquet de répondre (se bloquer) ou un incident.

Au lieu de cela, le serveur renvoie simplement une défaillance au client. Si le client continue fonctionne correctement après une telle défaillance dépend entièrement de la façon dont le logiciel client est écrit. Applications clientes bien comporté peuvent silencieusement recommencer l'opération ou une erreur de journal sans ne soit détérioré dans le cas contraire. Clients qui ne sont pas veiller à vérifier l'état de retour de leurs appels de fonction peuvent rencontrer des violations d'accès ou autres erreurs irrécupérables.

Pour confirmer que se ce problème est la cause de défaillance spécifique, il est nécessaire déboguer l'application serveur, définissez le débogueur s'arrête sur cette exception et comparer la pile qui en résulte pour celui qui suit :
   RPCRT4! RpcRaiseException@4 + 49 bytes   OLE32! ThreadInvoke(struct _RPC_MESSAGE *) + 524 bytes   RPCRT4! DispatchToStubInC@12 + 52 bytes   RPCRT4! RPC_INTERFACE::DispatchToStubWorker(struct _RPC_MESSAGE *,                unsigned int,long *) + 292 bytes   RPCRT4! RPC_INTERFACE::DispatchToStub(struct _RPC_MESSAGE *,                unsigned int,long *) + 93 bytes   RPCRT4! RPC_INTERFACE::DispatchToStubWithObject(struct _RPC_MESSAGE *,                class RPC_UUID *,unsigned int,long *) + 176 bytes   RPCRT4! WMSG_SASSOCIATION::DealWithRequestMessage(union _WMSG_MESSAGE *,                union _WMSG_MESSAGE *,struct _RPC_MESSAGE *,                class WMSG_SBINDING * *,unsigned int,int,int,int) + 826                bytes   RPCRT4! WMSG_ADDRESS::HandleRequest(union _WMSG_MESSAGE *,                class WMSG_SASSOCIATION *,struct _RPC_MESSAGE *,                class WMSG_ENDPOINT *,int,int) + 146 bytes   RPCRT4! WMSG_ADDRESS::DealWithWMSGRequest(union _WMSG_MESSAGE *,                class WMSG_ENDPOINT * *,struct HWND__ * *,                class WMSG_ASSOCIATION *,union _WMSG_MESSAGE * *) + 734                bytes   RPCRT4! WMSG_ADDRESS::ReceiveLotsaCalls(void) + 837 bytes   RPCRT4! RecvLotsaCallsWrapper(class WMSG_ADDRESS *) + 9 bytes   RPCRT4! BaseCachedThreadRoutine(class CACHED_THREAD *) + 156 bytes   RPCRT4! ThreadStartRoutine(class THREAD *) + 23 bytes   KERNEL32! 77f04f44()				
Cause
Les fonctions OLE gère le marshaling de bibliothèque de types ne sont pas complètement multithread-safe, ce qui entraîne une étroite fenêtre d'opportunité pour que l'exception à avoir lieu que si deux ou plusieurs clients effectuez des appels simultanés au serveur.
Résolution
Pour résoudre ce problème, procurez-vous le dernier service pack pour Windows NT 4.0 ou la mise à jour logicielle individuelle. Pour plus d'informations sur l'obtention du dernier service pack, rendezvous sur :
Pour plus d'informations sur l'obtention de la mise à jour logicielle individuelle, contactez les services de support technique Microsoft. Pour obtenir une liste complète des numéros de téléphone des services de support technique Microsoft et des informations sur les coûts de support, accédez à l'adresse suivante sur le site Web :
Statut
Microsoft a confirmé l'existence de ce problème dans Windows NT version 4.0. Ce problème a été corrigé dans Service Pack 5 Windows NT 4.0.
objet 4.00 liaison incorporation dcom de com distribué

Avertissement : cet article a été traduit automatiquement

Propriétés

ID d'article : 195469 - Dernière mise à jour : 02/08/2014 03:53:58 - Révision : 1.5

  • Microsoft Windows NT Workstation 4.0 Édition Développeur
  • Microsoft Windows NT Server 4.0 Standard Edition
  • kbnosurvey kbarchive kbmt kbhotfixserver kbqfe kbbug kbfix kbqfe KB195469 KbMtfr
Commentaires