L'application n'a pas pu démarrer correctement (0xc000007b)


159

J'ai une application client / serveur que j'ai développée sur un seul PC. Maintenant, il a besoin de deux ports série, j'ai donc emprunté un PC à un ami.

Lorsque je crée mon application et que je tente de l'exécuter ou de la déboguer (que ce soit dans l'EDI Delphi ou à partir du gestionnaire de fichiers Windows), le message d'erreur «L'application n'a pas pu démarrer correctement (0xc000007b)» s'affiche.

Googler n'apporte pas grand-chose, mais semble indiquer que ce n'est rien de spécifique à Delphi et que cela se produit avec d'autres applications. Cela semble être causé par l'appel à une DLL 32 bits à partir d'une application 64 bits ou vice versa.

  • les deux PC sont Windows 7, 64 bits
  • les deux ont une édition de démarrage Delphi Xe2 qui ne peut gérer que 32 bits
  • L'application fonctionne bien sur mon PC, mais pas sur celui de mon ami
  • D'autres applications Delphi fonctionnent très bien sur les deux PC

Quelqu'un peut-il me donner un indice sur la façon de retracer cela?


6
Par ailleurs, vous pouvez utiliser com0com pour installer des ports série virtuels sur un seul PC. Idéal pour le débogage et les tests, créez simplement 2 ports virtuels et reliez-les ensemble dans la configuration, puis exécutez vos applications sur chaque port afin qu'ils puissent se parler.
Remy Lebeau

1
Avez-vous vérifié le journal des événements Windows? Parfois, Windows fournit plus d'informations sur la DLL qui a entraîné l'échec de l'application.
Luis Carrasco

1
Ce sera une DLL manquante que je soupçonne, généralement un utilitaire, ou même le gestionnaire de mémoire.
mj2008

4
@ mj2008 Missing DLL donne une erreur différente: Le programme ne peut pas démarrer car XXXX.dll est absent de votre ordinateur. Essayez de réinstaller le programme pour résoudre ce problème.
David Heffernan

3
@snd Cette erreur est STATUS_INVALID_IMAGE_FORMAT. Vous n'obtenez pas cela lorsque le système ne peut pas trouver une DLL de ce nom. Vous obtenez STATUS_INVALID_IMAGE_FORMATquand une DLL peut être trouvée, mais elle est corrompue ou a le mauvais bitness.
David Heffernan

Réponses:


133

Pour commencer, je suggérerais de tester s'il y a un problème entre votre application et ses dépendances en utilisant le walker de dépendance


31
basé sur les codes d'erreur Windows ( google.de / ... ), ce code d'erreur signifie: 0xC000007B STATUS_INVALID_IMAGE_FORMAT.
mox

95
Ce qui est une bonne indication que l'application 32 bits a essayé de charger une DLL 64 bits.
Remy Lebeau

4
En fait, ce fichier Pdf de code d'erreur est une excellente source.
mox

4
+1 et l'aswer. Merci, le marcheur de dépendance a sauvé la mise. J'ai remplacé une DLL 64 bits par une version 32 bits et cela fonctionne maintenant.
Mawg dit de réintégrer Monica

6
Assurez-vous d'avoir la bonne version de Dependency Walker. Les dépendances x86 afficheront des résultats incorrects pour les binaires x64.
Andreas Haferburg

53

Une dépendance de temps de chargement n'a pas pu être résolue. La manière la plus simple de déboguer ceci est d'utiliser Dependency Walker . Utilisez l'option Profil pour obtenir la sortie de diagnostic du processus de chargement. Cela identifiera le point de défaillance et devrait vous guider vers une solution.

La cause la plus courante de cette erreur est d'essayer de charger une DLL 64 bits dans un processus 32 bits, ou vice versa.


2
+1. Notez également que vous devez exécuter la version 32 bits de l'outil de recherche de dépendances et vous assurer que toutes les DLL chargées sont 32 bits. Si vous essayez d'exécuter le marcheur de dépendance de version 64 bits, il chargera volontiers les DLL 64 bits, telles que VCRedist, même si vous avez également leurs versions 32 bits.
liorda le

12

C'est une DLL manquante. Il est possible que votre dll qui fonctionne avec les ports com ait une dépendance dll non résolue. Vous pouvez utiliser le marcheur de dépendances et le débogueur Windows. Vérifiez toute la bibliothèque mfc, par exemple. En outre, vous pouvez utiliser nrCommlib - ce sont d'excellents composants pour travailler avec les ports com.


12

J'ai essayé toutes les choses spécifiées ici et j'ai trouvé une autre réponse. J'ai dû compiler mon application avec des DLL 32 bits. J'avais construit les bibliothèques à la fois en 32 bits et 64 bits, mais j'avais mon PATHensemble de bibliothèques 64 bits. Après avoir recompilé mon application (avec un certain nombre de changements dans mon code également), j'ai eu cette erreur redoutée et j'ai lutté pendant deux jours. Enfin, après avoir essayé un certain nombre d'autres choses, j'ai changé mon PATHpour avoir les DLL 32 bits avant les DLL 64 bits (elles ont les mêmes noms). Et ça a marché. Je l'ajoute simplement ici par souci d'exhaustivité.


9

Il a été mentionné dans les réponses précédentes que l'utilisation de dependency walker est la voie à suivre, dans mon cas (mon application échoue toujours avec le code d'erreur), dependency walker a montré quelques dll qui ne sont PAS pertinentes!

Enfin compris que je peux exécuter le profilage en allant dans le menu "profil" et il exécutera l'application et s'arrêtera à la DLL exacte qui est à l'origine du problème! J'ai découvert qu'une dll 32 bits avait été choisie à cause du chemin et je l'ai corrigée.

entrez la description de l'image ici


5

J'ai récemment eu un problème où je développais une application (qui utilisait un port série) et cela fonctionnait sur toutes les machines sur lesquelles je l'ai testé, mais quelques personnes recevaient cette erreur.

Il s'avère que toutes les machines sur lesquelles l'erreur s'est produite exécutaient Win7 x64 et n'avaient JAMAIS été mis à jour.

L'exécution d'une mise à jour Windows a corrigé toutes les machines dans mon cas particulier.


5

J'ai rencontré le même problème lors du développement d'une application client-serveur à l'aide de Microsoft Visual Studio 2012.

Si vous avez utilisé Visual Studio pour développer l'application, vous devez vous assurer que le nouveau (c'est-à-dire l'ordinateur sur lequel le logiciel n'a pas été développé) dispose du package redistribuable Microsoft Visual C ++ approprié. Le cas échéant, vous avez besoin de la bonne année et de la bonne version binaire (c'est-à-dire x86 pour 32 bits et x64 pour 64 bits) du package redistribuable Visual C ++.

Les packages redistribuables Visual C ++ installent les composants d'exécution requis pour exécuter les applications C ++ générées à l'aide de Visual Studio.

Voici un lien vers le redistribuable Visual C ++ pour Visual Studio 2015 .

Vous pouvez vérifier quelles versions sont installées en allant dans Panneau de configuration -> Programmes -> Programmes et fonctionnalités.

Voici comment j'ai eu cette erreur et l'ai corrigée:

1) J'ai développé une application 32 bits à l'aide de Visual Studio 2012 sur mon ordinateur. Appelons mon ordinateur ComputerA.

2) J'ai installé le .exe et les fichiers associés sur un autre ordinateur que nous appellerons ComputerB.

3) Sur ComputerB, j'ai exécuté le .exe et j'ai reçu le message d'erreur.

4) Sur ComputerB, j'ai regardé les programmes et les fonctionnalités et je n'ai pas vu Visual C ++ 2012 Redistributable (x64).

5) Sur ComputerB, j'ai cherché sur Google Visual C ++ 2012 Redistributable et sélectionné et installé la version x64.

6) Sur ComputerB, j'ai exécuté le .exe sur ComputerB et je n'ai pas reçu le message d'erreur.


3

En fait, cette erreur indique un format d'image non valide. Cependant, pourquoi cela se produit-il et que signifie généralement le code d'erreur? En fait, cela peut apparaître lorsque vous essayez d'exécuter un programme conçu pour ou destiné à fonctionner avec un système d'exploitation Windows 64 bits, mais que votre ordinateur fonctionne sur un système d'exploitation 32 bits.

Raisons possibles:

  • Microsoft Visual C ++
  • Besoin de redémarrer
  • DirectX
  • Framework .NET
  • Besoin de réinstaller
  • Besoin d'exécuter l'application en tant qu'administrateur

Source: http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/


2

Cela peut être un cas où le débogage du débogueur peut être utile. Essentiellement, si vous suivez les instructions ici, vous pouvez exécuter deux ide et l'un déboguera dans l'autre. Si vous désignez votre application en une seule, vous pouvez parfois détecter des erreurs que vous auriez autrement manquées. Ça vaut la peine d'essayer.


2
Il s'agit presque certainement d'une erreur signalée par le chargeur et qui se produit donc avant le démarrage du processus. Par conséquent, le débogage ne serait pas une option. Bien sûr, je peux me tromper dans mon diagnostic que l'erreur est soulevée par le chargeur.
David Heffernan

2

J'ai vu l'erreur en essayant d'exécuter l'exécutable de débogage VC ++ sur une machine sur laquelle Visual C ++ n'était pas installé. Construire une version finale et l'utiliser corrigé.


2

Dans mon cas, l'erreur s'est produite lorsque j'ai renommé une DLL après sa création (à l'aide de Visual Studio 2015), afin qu'elle corresponde au nom attendu par un exécutable, qui dépendait de la DLL. Après le changement de nom, la liste des symboles exportés affichée par Dependency Walker était vide et le message d'erreur "L'application n'a pas pu démarrer correctement" était affiché.

Il peut donc être résolu en modifiant le nom du fichier de sortie dans les options de l'éditeur de liens Visual Studio.


2

Vous pouvez avoir cela si vous essayez de montrer à votre application qu'elle a une dépendance sur l' assembly Microsoft.Windows.Common-Controls . Vous effectuez cette opération lorsque vous souhaitez charger la version 6 de la bibliothèque de contrôles communs afin que les styles visuels soient appliqués aux contrôles communs.

Vous avez probablement suivi la documentation originale de Microsoft depuis l'époque de Windows XP et ajouté ce qui suit au manifeste de votre application:

<!-- Dependancy on Common Controls version 6 -->
<dependency>
    <dependentAssembly>
        <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Common-Controls"
                version="6.0.0.0"
                processorArchitecture="X86"
                publicKeyToken="6595b64144ccf1df"
                language="*"/>
    </dependentAssembly>
</dependency>

Windows XP n'est plus le système d'exploitation et vous n'êtes plus une application 32 bits. Au cours des 17 années écoulées, Microsoft a mis à jour sa documentation ; il est maintenant temps pour vous de mettre à jour votre manifeste:

<!-- Dependancy on Common Controls version 6 -->
<dependency>
    <dependentAssembly>
        <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Common-Controls"
                version="6.0.0.0"
                processorArchitecture="*"
                publicKeyToken="6595b64144ccf1df"
                language="*"/>
    </dependentAssembly>
</dependency>

Raymond Chen a une belle histoire des commandes communes:


3
"Windows XP n'est plus le système d'exploitation" a fait ma journée: D
Victoria

Mais j'ai posé cette question en 2012 - les applications Windows avaient-elles alors des manifestes?
Mawg dit de réintégrer Monica le

1
@Mawg Cela peut être lié ou non à votre problème. Mais avec Stackoverflow étant une combinaison de wiki et de reddit pour la connaissance; c'est une bonne information à connaître pour l'erreur exacte que vous avez signalée. Cela dit, les applications Windows ont eu des manifestes d'assemblage remontant à Windows 2000; et à partir de Windows XP, vous n'obtiendrez plus la dernière version de comctl32.dll à moins que votre manifeste d'assembly n'en ait déclaré une dépendance.
Ian Boyd

1

Je viens de résoudre ce problème pour mon projet personnel (merci à Dries pour cela). Pour moi, c'était parce que le chemin du projet était trop long. Après avoir enregistré le .sln dans un chemin plus court (C: / MyProjects) et compilé à partir de là, il s'est exécuté sans l'erreur.


1
@jojodmo: en fait, "Pour moi c'était parce que le chemin du projet était trop long" me semble être une contribution valable à la chasse aux bogues ...
Christian Severin


1

Je viens de rencontrer ce problème. J'ai recherché "C ++" sous mes "Applications et fonctionnalités" dans le panneau de configuration de Windows 10 et j'ai remarqué qu'une sorte de mise à jour venait de s'exécuter quelques jours auparavant et avait installé VC ++ Redistributable 2012-2017. L'application qui fonctionnait dans le message d'erreur ne nécessitait que VC ++ 2010. Je les ai tous désinstallés, puis réinstallé juste 2010 x86 / x64, et l'erreur a disparu et l'application a fonctionné comme prévu.


1

Cela peut arriver si, pour une raison quelconque, une ressource x86 est chargée à partir d'une machine x64. Pour éviter cela explicitement, ajoutez cette directive de préprocesseur à stdafx.h (bien sûr, dans mon exemple, la ressource problématique est la DLL Windows Common Controls.

#if defined(_WIN64)
#pragma comment(linker, "\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'\"")
#endif

1
Les contrôles communs font partie du système d'exploitation. Le système d'exploitation sait d'où charger la version correcte. Cela ne résout en rien le problème du PO. Il n'installe même pas de dépendance. Tout ce qu'il fait est de compiler une ressource manifeste dans l'application pour utiliser la version 6 des contrôles communs. Le conditionnel du préprocesseur n'est pas non plus nécessaire. Simplement réglé processorArchitecture='*', et c'est tout ce qu'il y a à faire.
IInspectable

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.