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 faut deux ports série, alors j'ai 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 Delphi IDE ou à partir du gestionnaire de fichiers Windows), le message d'erreur "L'application n'a pas pu démarrer correctement (0xc000007b)".
Googler n'apporte pas grand chose, mais semble indiquer que ce n'est pas spécifique à Delphi et se produit avec d'autres applications. Cela semble être dû à l'appel d'une DLL 32 bits à partir d'une application 64 bits ou vice versa.
- les deux ordinateurs sont Windows 7, 64 bits
- les deux ont Delphi Xe2 Starter Edition qui ne peut gérer que 32 bits
- L'application fonctionne correctement sur mon PC, mais pas sur celle de mon ami
- D'autres applications Delphi fonctionnent parfaitement sur les deux PC
Quelqu'un peut-il me donner un indice sur la façon de le localiser?
Pour commencer, je suggérerais de vérifier s’il existe un problème entre votre application et ses dépendances à l’aide de dependency walker
Une dépendance au temps de chargement n'a pas pu être résolue. Le moyen le plus simple de déboguer cela consiste à utiliser Dependency Walker . Utilisez l'option Profil pour obtenir une sortie de diagnostic du processus de chargement. Cela identifiera le point d'échec et devrait vous guider vers une solution.
La cause la plus fréquente de cette erreur est la tentative de charger un DLL 64 bits dans un processus 32 bits, ou inversement.
C'est une dll manquante. Peut-être que votre dll fonctionnant avec les ports de communication aura une dépendance non résolue avec la dll. Vous pouvez utiliser le gestionnaire de dépendance et le débogueur Windows. Vérifiez toutes les bibliothèques de la MFC, par exemple. En outre, vous pouvez utiliser nrCommlib - ce sont d'excellents composants pour travailler avec les ports de communication.
J'ai essayé toutes les choses spécifiées ici et trouvé encore 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 en 64 bits, mais mon PATH était réglé sur des bibliothèques 64 bits. Après avoir recompilé mon application (avec un certain nombre de modifications dans mon code également), j'ai eu cette erreur redoutée et j'ai lutté pendant deux jours. Enfin, après avoir essayé plusieurs autres choses, j’ai modifié mon PATH afin d’avoir les DLL 32 bits avant les DLL 64 bits (elles portent le même nom). Et ça a marché. Je ne fais que l'ajouter ici par souci d'exhaustivité.
Il a été mentionné dans des réponses précédentes que l'utilisation de Dependency Walker était la solution, dans mon cas (mon application échouait toujours avec le code d'erreur), Dependency Walker montrait quelques dll non pertinentes!
J'ai enfin compris que je pouvais lancer le profilage en allant dans le menu "Profil" et que l'application serait exécutée et arrêtée à la DLL exacte qui cause le problème! J'ai découvert qu'une DLL de 32 bits avait été choisie à cause d'un chemin et 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'avais testée, 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.
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 package (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 version d'année et de version du bit (par exemple, 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 nécessaires à l'exécution d'applications C++ construites à l'aide de Visual Studio.
Voici un lien vers = Visual C++ redistribuable 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 fichier .exe et les fichiers associés sur un autre ordinateur que nous appellerons ComputerB.
3) Sur ComputerB, j'ai exécuté le fichier .exe et j'ai reçu le message d'erreur.
4) Sur ComputerB, j'ai consulté les programmes et fonctionnalités et je n'ai pas vu Visual C++ 2012 redistribuable (x64).
5) Sur ComputerB, j'ai cherché sur Google pour Visual C++ 2012 redistribuable et sélectionné et installé la version x64.
6) Sur ComputerB, j'ai exécuté le fichier .exe sur ComputerB et je n'ai pas reçu le message d'erreur.
En réalité, 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 pourrait 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, alors que votre ordinateur fonctionne sous un système d'exploitation 32 bits.
Raisons possibles:
- Microsoft Visual C++
- Besoin de redémarrer
- DirectX
- .NET Framework
- Besoin de ré-installer
- Besoin d'exécuter l'application en tant qu'administrateur
Dans mon cas, l'erreur s'est produite lorsque j'ai renommé DLL après l'avoir construit (à l'aide de Visual Studio 2015), de sorte qu'il corresponde au nom attendu par un exécutable, qui dépend de la DLL. Après avoir renommé la liste des symboles exportés affichée par Dependency Walker, celle-ci était vide et le message d'erreur "L'application ne parvenait pas à démarrer correctement" était affiché.
Cela pourrait donc être corrigé en modifiant le nom du fichier de sortie dans les options de l'éditeur de liens Visual Studio.
Vous pouvez avoir ceci si vous essayez de dé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 Windows XP jours et ajouté les éléments suivants 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 les 17 années qui ont suivi Microsoft a mis à jour sa documentation ; Il est maintenant temps 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:
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 et l’utiliser a corrigé le problème.
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 idées et l’une déboguera dans l’autre. Si vous désignez votre application en une seule fois, vous pouvez parfois détecter les erreurs que vous auriez manquées. Ça vaut la peine d'essayer.
Téléchargez également et décompressez "Dépendances" dans le même dossier où vous avez placé le wget.exe à partir de
http://gnuwin32.sourceforge.net/packages/wget.htm
Vous aurez alors des fichiers lib * .dll ainsi que wget.exe dans le même dossier et cela devrait fonctionner correctement.
(J'ai également répondu ici https://superuser.com/a/873531/146668 que j'ai trouvé à l'origine.)
Il est possible que vous disposiez de plusieurs versions des dll sur votre système. Vous pouvez rechercher votre système pour le savoir. Le problème peut être résolu en modifiant simplement l'ordre des répertoires dans votre chemin. C'était mon problème. ( Impossible d'exécuter l'interface graphique de Qt Creator en dehors de Qt. "Impossible de démarrer l'application correctement (erreur 0xc000007b)" )
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 fichier .sln sur un chemin plus court (C:/MyProjects) et compilé à partir de là, il s’est exécuté sans erreur.
Je viens de rencontrer ce problème. J'ai cherché "C++" dans mes "Applications et fonctionnalités" dans le panneau de configuration de Windows 10 et j'ai constaté qu'une sorte de mise à jour venait juste d'être exécutée et avait 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 toutes désinstallées, puis réinstallées uniquement en 2010 x86/x64. L'erreur a disparu et l'application a fonctionné comme prévu.
Cela peut arriver si, pour une raison quelconque, une ressource x86 est chargée à partir d'un ordinateur 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 de contrôles communs Windows).
#if defined(_WIN64)
#pragma comment(linker, "\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='AMD64' publicKeyToken='6595b64144ccf1df'\"")
#endif