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

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, alors j'ai emprunté un PC à un ami.

Lorsque je construis mon application et que j'essaie de l'exécuter ou de la déboguer (que ce soit dans L'IDE Delphi ou à partir du gestionnaire de fichiers Windows), il y a des erreurs "L'application n'a pas pu démarrer correctement (0xc000007b)".

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

  • Les deux PC sont Windows 7, 64 bits
  • les deux ont Delphi XE2 starter edition qui ne peut gérer que 32 bits
  • L'application fonctionne bien sur mon PC, mais pas sur 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 traquer cela?

138
demandé sur Mawg 2012-05-08 07:08:20

16 réponses

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

120
répondu mox 2012-05-08 05:38:54

Une dépendance de temps de chargement n'a pas pu être résolue. Le moyen le plus simple de déboguer ceci est d'utiliser Dependency Walker. Utilisez L'option Profil pour obtenir la sortie de diagnostic du processus de charge. Cela permettra d'identifier le point de défaillance et devrait vous orienter vers une solution.

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

50
répondu David Heffernan 2012-05-08 08:06:29

C'est une dll manquante. Peut-être que votre dll qui fonctionne avec les ports com a une dépendance dll non résolue. Vous pouvez utiliser dependency walker et Windows debugger. 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
répondu Alex.kononov 2012-05-08 11:58:14

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 mon PATH était défini sur des bibliothèques 64 bits. Après avoir recompilé mon application (avec un certain nombre de changements dans mon code), 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 PATH pour avoir les DLL 32 bits avant les DLL 64 bits (elles ont les mêmes noms). Et cela a fonctionné. Je l'ajoute simplement ici pour être complet.

11
répondu unxnut 2014-07-29 17:23:48

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 continue à échouer 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 va exécuter l'application et s'arrêter à la dll exacte qui cause le problème! J'ai découvert qu'une dll 32 bits a été choisie à cause du chemin et l'a corrigée.

entrez la description de l'image ici

6
répondu pktCoder 2016-07-25 20:10:59

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 obtenaient 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é mises à jour.

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

5
répondu mitchfish36 2013-11-05 21:26:35

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

Raisons Possibles:

  • Microsoft Visual C++
  • besoin de redémarrer
  • DirectX
  • . NET Framework
  • besoin de Re-Installer
  • Nécessaire pour 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/

3
répondu Solve101 2015-09-01 15:33:39

J'ai rencontré le même problème en développant une application client-serveur en utilisant 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é) possède le Package redistribuable Microsoft Visual C++ approprié. Par approprié, vous avez besoin de la bonne année et de la bonne version (c'est-à-dire x86 pour 32 bits et x64 pour 64 bits) du Package redistribuable Visual C++.

Le Visual C++ Les Packages redistribuables installent les composants d'exécution requis pour exécuter des applications c++ créé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 en utilisant Visual Studio 2012 sur mon ordinateur. Nous allons appeler mon ordinateur Ordinateura.

2) j'ai installé le .exe et les fichiers connexes sur un autre ordinateur, nous appellerons ComputerB.

3) sur ComputerB, j'ai couru le .exe et a obtenu 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 redistribuable (x64).

5) sur ComputerB, j'ai googlé pour Visual C++ 2012 redistribuable et sélectionné et installé la version x64.

6) sur ComputerB, j'ai couru le .exe sur ComputerB et n'a pas recevez le message d'erreur.

3
répondu user3731622 2015-10-12 23:15:23

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 un votre application dans un, vous pouvez parfois attraper des erreurs que vous manquez autrement. Sa vaut la peine d'essayer.

2
répondu Toby Allen 2012-05-08 07:30:12

J'ai vu l'erreur en essayant d'exécuter l'exécutable de débogage VC++ sur une machine qui N'avait pas Visual C++ installé. Construire une version de version et l'utiliser A CORRIGÉ.

2
répondu Bill Greer 2013-12-16 21:12:26

Dans mon cas, l'erreur s'est produite lorsque j'ai renommé une DLL après l'avoir construite (en utilisant Visual Studio 2015), de sorte 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és par Dependency Walker était vide et le message d'erreur "L'application n'a pas pu démarrer correctement" s'affichait.

Donc, il pourrait être corrigé en changeant le nom du fichier de sortie dans les options de l'éditeur de liens Visual Studio.

2
répondu nucleon 2016-08-10 12:27:08

Vient de résoudre ce problème pour mon projet personnel (merci à Dries pour ça). Pour moi, c'était parce que le chemin du projet était trop long. Après l'enregistrement de l' .sln à un chemin plus court (C:/MyProjects) et en compilant à partir de là, il a couru sans l'erreur.

1
répondu user1539405 2014-03-31 13:50:18

Téléchargez et décompressez également "dépendances" dans le même dossier où vous mettez le wget.exe de

Http://gnuwin32.sourceforge.net/packages/wget.htm

Vous aurez alors un peu de lib*.fichiers dll ainsi que wget.exe dans le même dossier et cela devrait fonctionner correctement.

(j'ai aussi répondu ici https://superuser.com/a/873531/146668 que j'ai trouvé à l'origine.)

1
répondu Andreas Reiff 2017-03-20 10:18:14

Je viens de rencontrer ce problème. J'ai cherché "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 avant et installé VC++ Redistributable 2012-2017. L'application qui s'exécutait dans le message d'erreur ne nécessitait que VC++ 2010. Je les ai tous désinstallés, puis réinstallés juste 2010 x86/x64, et l'erreur est partie et l'application a fonctionné comme prévu.

1
répondu Chris Putnam 2017-06-07 11:57:18

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 Windows Common Controls DLL.

#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
répondu Michael Haephrati 2017-09-27 18:37:56

Vous pouvez l'avoir si vous essayez de manifester votre application qu'elle dépend du Microsoft.Windows.Common Controls assemblée. Vous le faites 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 les jours 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. Dans l'intervalle 17 années Microsoft a mis à jour leur documentation ; maintenant il est 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 contrôles communs:

1
répondu Ian Boyd 2018-06-26 21:03:52