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

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.

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.

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.

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.

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.

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/

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.

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.

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É.

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.

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.

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.)

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.

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

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:

• l'historique des contrôles communs de Windows XP (archive )