Dépannage d'applications isolées C/C++ et d'assemblys côte à côte

Article
06/07/2013

Une application C/C++ /C ++ de charge peut échouer si les bibliothèques dépendantes ne peuvent pas être détectées.Cet article décrit quelques raisons courantes pour lesquelles l'application C/C++ /C c++ ne charge pas, et suggère des étapes pour résoudre les problèmes.

Si une application ne charge pas car elle possède un manifeste qui spécifie une dépendance sur un assembly côte à côte, et l'assembly n'est pas installée comme un assembly privé dans le même dossier que le fichier exécutable ni dans le cache d'assembly natif dans le dossier de %WINDIR%\WinSxS\, l'un des messages d'erreur suivant peut s'afficher, selon la version de Windows sur lesquels vous essayez d'exécuter l'application.

L'application pour initialiser correctement (0xc0000135).
Cette application n'a pas démarré, car la configuration de l'application est incorrecte.Réinstaller l'application pourrait résoudre ce problème.
Le système ne peut pas exécuter le programme spécifié.

Si votre application n'a pas de manifeste et dépend d'une DLL que les windows ne peut pas trouver dans les emplacements suivants de recherche, un message d'erreur qui ressemble celui-ci peut s'afficher :

Cette application n'a pas été démarré car une DLL requis est introuvable.La réinstallation de cette application peut corriger ce problème.

Si votre application est déployée sur un ordinateur sur lequel n'est pas Visual Studio, et il se bloque avec les messages d'erreur qui ressemblent les précédents, vérifiez ces éléments :

Suivez les étapes décrites dans Understanding Dependencies of a Visual C++ Application.Le dependency walker peut afficher la plupart des dépendances pour une application ou une DLL.Si vous observez que certaines DLL sont manquants, installez-les sur l'ordinateur sur lequel vous essayez d'exécuter votre application.
Le chargeur du système d'exploitation utilise le manifeste d'application pour charger les assemblys dont l'application dépend.Le manifeste peut être incorporé dans le fichier binaire en tant que ressource, ou être installé comme un fichier séparé dans le dossier application.Pour vérifier si le manifeste est incorporé dans le fichier binaire, ouvrez le fichier binaire dans Visual Studio et recherchez RT_MANIFEST dans sa liste des ressources.Si vous ne pouvez pas trouver un manifeste incorporé, recherchez dans le dossier d'application pour un fichier nommé présenter comme dans <binary_name>.<extension>.manifest.
Si votre application dépend d'assemblys côte à côte et un manifeste n'est pas présent, vous devez vérifier que l'éditeur de liens génère un manifeste pour votre projet.Examinez l'option de l'éditeur de liens Génération d'un manifeste dans la boîte de dialogue Propriétés du projet pour rechercher le projet.
Si le manifeste est incorporé dans le fichier binaire, vérifiez que l'ID de RT_MANIFEST est correct pour ce type de fichier binaire.Pour plus d'informations sur lequel ID de ressource à utiliser, consultez Utilisation d'assemblys côte à côte en tant que ressource (windows).Si le manifeste est dans un fichier séparé, ouvrez-le dans un éditeur XML ou un éditeur de texte.Pour plus d'informations sur les manifestes et les règles du déploiement, consultez l' Manifestes.

[!REMARQUE]

Si un manifeste incorporé et un fichier manifeste séparé sont présents, le chargeur du système d'exploitation utilise le manifeste incorporé et ignore le fichier séparé.Toutefois, dans Windows XP, l'inverse est True (le manifeste que le fichier séparé est utilisé et le manifeste incorporé est ignoré.
Nous recommandons que vous incorporez un manifeste dans chaque DLL car les manifestes externes sont ignorés lorsque une DLL est chargé toutefois un appel d' LoadLibrary .Pour plus d'informations, consultez Manifestes d'assembly.
Vérifiez que tous les assemblys qui sont énumérés dans le manifeste sont correctement installés sur l'ordinateur.Chaque assembly est spécifié dans le manifeste par son nom, son numéro de version, et l'architecture de processeur.Si votre application dépend d'assemblys côte à côte, vérifiez que ces assemblys sont correctement installés sur l'ordinateur afin que le chargeur du système d'exploitation puisse les rechercher, comme décrit dans Assembly recherche la séquence.N'oubliez pas que les assemblys 64 bits ne peuvent pas être chargés dans les processus 32 bits ni exécutés sur les systèmes d'exploitation 32 bits.

Exemple

Supposons que nous avons une application, appl.exe, qui est générée à l'aide de Visual C++.Le manifeste de l'application soit est incorporé dans appl.exe comme ressource binaire RT_MANIFEST, qui a un ID égal à 1, ou est stocké comme un fichier séparé appl.exe.manifest.Le contenu de ce manifeste ressemble à ceci :

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Fabrikam.SxS.Library" version="2.0.20121.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3e"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Le chargeur du système d'exploitation, ce manifeste indique qu'appl.exe dépend d'un assembly nommé Fabrikam.SxS.Library, la version 2.0.20121.0, qui est créée pour une architecture de 32 bits de processeur x86.L'assembly côte à côte dépendant peut être installé en tant qu'assembly partagé ou comme un assembly privé.

Le manifeste d'assembly pour un assembly partagé est installé dans le dossier de %WINDIR%\WinSxS\Manifests\.Il identifie l'assembly et répertorie le son contenu, c'est-à-dire les DLL qui font partie de l'assembly :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <noInheritable/>
   <assemblyIdentity type="win32" name="Fabrikam.SxS.Library" version="2.0.20121.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3e"/>
   <file name="Fabrikam.Main.dll" hash="3ca5156e8212449db6c622c3d10f37d9adb1ab12" hashalg="SHA1"/>
   <file name="Fabrikam.Helper.dll" hash="92cf8a9bb066aea821d324ca4695c69e55b2d1c2" hashalg="SHA1"/>
</assembly>

Les assemblys côte à côte peuvent également utiliser fichiers de configuration de l'éditeur(également appelé la stratégie fichier- à rediriger globalement des applications et des assemblys d'utiliser une version d'un assembly côte à côte et non une autre version du même assembly.Vous pouvez examiner les stratégies pour rechercher un assembly partagé dans le dossier de %WINDIR%\WinSxS\Policies\.Voici un fichier de stratégie d'exemple :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

   <assemblyIdentity type="win32-policy" name="policy.2.0.Fabrikam.SxS.Library" version="2.0.20121.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3e"/>
   <dependency>
      <dependentAssembly>
         <assemblyIdentity type="win32" name="Fabrikam.SxS.Library" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3e"/>
         <bindingRedirect oldVersion="2.0.10000.0-2.0.20120.99" newVersion="2.0.20121.0"/>
      </dependentAssembly>
   </dependency>
</assembly>

Ce fichier de stratégie spécifie qu'une application ou un assembly qui demandent la version 2.0.10000.0 de cet assembly doit utiliser à la place la version 2.0.20121.0, qui est la version actuelle qui est installée sur le système.Si une version de l'assembly qui est indiqué dans le manifeste de l'application est spécifiée dans le fichier de stratégie, le chargeur recherche une version de cet assembly spécifié dans le manifeste dans le dossier de %WINDIR%\WinSxS\, et si cette version n'est pas installée, le chargement échoue.Et si la version 2.0.20121.0 d'assembly n'est pas installée, le chargement échoue pour les applications qui demandent la version 2.0.10000.0 d'assembly.

Toutefois, l'assembly peut également être installé en tant qu'assembly côte à côte privé dans le dossier d'application installé.En cas de échec du système d'exploitation pour rechercher l'assembly comme assembly partagé, il recherche comme un assembly privé, dans l'ordre suivant :

Examinez le dossier d'application pour rechercher un fichier manifeste portant le nom <assemblyName>.manifest.Dans cet exemple, les tests du chargeur pour rechercher Fabrikam.SxS.Library.manifest dans le dossier qui contient appl.exe.S'il trouve le manifeste, le chargeur charge l'assembly du dossier d'application.Si l'assembly est introuvable, le chargement échoue.
Essayez d'ouvrir<assemblyName>\\dans le dossier qui contient appl.exe, et si\\<assemblyName>existe, essayez de charger un fichier manifeste portant le nom <assemblyName>.manifest de ce dossier.Si le manifeste est trouvé, le chargeur charge l'assembly du\d'<assemblyName>\ dossier.Si l'assembly est introuvable, le chargement échoue.

Pour plus d'informations sur le fonctionnement des recherches de chargeur pour les assemblys dépendants, consultez Assembly recherche la séquence.En cas de échec du chargeur pour rechercher un assembly dépendant comme un assembly privé, le chargement échoue et le message « que le système ne peut pas exécuter le programme spécifié » s'affiche.Pour résoudre cette erreur, assurez-vous que le dépendant assemblys et les DLL qui font partie les- sont installés sur l'ordinateur en tant qu'assemblys privés ou partagés.

Partager via

Dépannage d'applications isolées C/C++ et d'assemblys côte à côte

Exemple

Voir aussi

Concepts

Autres ressources

Ressources supplémentaires