Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

PRB : Calling LoadLibrary() pour charger une DLL That Has Static TLS

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: 118816
Symptômes
Une bibliothèque (DLL) dynamic-link utilise __declspec (thread) pour allouer un stockage local des threads statique (TLS). Il n'existe aucun problème associé à l'exécution d'une application qui est liée avec la bibliothèque statique correspondant. Toutefois, lorsqu'une application utilise la fonction LoadLibrary pour charger la DLL au lieu d'utiliser la version statique, LoadLibrary échoue sur Win32s avec un code d'erreur 87 : paramètre non valide.

LoadLibrary réussit sur un ordinateur qui exécute Windows 98, Windows NT ou Windows 2000 dans cette situation. Toutefois, le comportement de l'appel de fonctions de la DLL qui font référence à des variables statiques TLS n'est pas défini. Sur Microsoft Windows 95, LoadLibrary échoue et le GetLastError fonction renvoie 1114 - ERROR_DLL_INIT_FAILED (un lien dynamique bibliothèque routine d'initialisation a échoué). Sur Windows 2000, la fonction LoadLibrary réussit. Toutefois, toute tentative d'accéder aux données TLS provoque une violation d'accès (AV).
Cause
Il s'agit d'une limitation de LoadLibrary et __declspec. L'espace des variables globales pour un thread est alloué au moment de l'exécution. La taille est basée sur un calcul des exigences de l'application plus les besoins de toutes les bibliothèques liées de façon statique. Si une DLL utilise TLS statique et est lié dynamiques dans une application, lorsque la fonction LoadLibrary ou FreeLibrary est appelée, le système doit trouver tous les threads qui existent dans le processus et d'agrandissent ou de compacter leur mémoire TLS conformément à la taille de TLS statique dans la DLL qui vient d'être chargée. Ce processus est trop importante pour les systèmes d'exploitation gérer, ce qui peut provoquer une exception lorsque la DLL est chargée dynamiquement ou références les données de code.
Résolution
DLL utiliser __declspec (thread) ne doit pas être chargées à l'aide de la fonction LoadLibrary.

Le code de la DLL doit être modifié pour utiliser TLS telles que TlsAlloc et allouer si la DLL peut être chargée par le biais de LoadLibrary. Ou bien, la DLL à l'aide de __declspec (thread) doit uniquement être chargée implicitement dans l'application.
Plus d'informations
Pour déterminer si une DLL utilise TLS statique, l'outil DUMPBIN.exe peut être utilisé pour vider les informations d'en-tête. Une DLL a TLS statique si OPTIONAL HEADER VALUES contient une taille est supérieure à 0 (zéro) dans le répertoire de stockage de thread, comme suit :
517B20 RVA [taille] [18] de répertoire de stockage de thread
1.10 1,20 3.50

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 118816 - Dernière mise à jour : 11/21/2006 15:29:52 - Révision : 3.2

Microsoft Win32 Application Programming Interface

  • kbmt kbdll kbkernbase kbprb kbthread KB118816 KbMtfr
Commentaires
/html>