J'écris un projet en C ++ avec SDL2 sur Windows 64 bits 10 à l'aide de Visual Studio 2015. J'ai récemment acheté un nouvel ordinateur portable Windows 10 et cloné mon projet de GitHub. Mon projet compile correctement, mais je reçois l'erreur suivante lorsque je l'exécute:
L'application n'a pas pu démarrer correctement (0xc000007b). Cliquez sur OK pour fermer l'application.
Sur la base de mes recherches jusqu'à présent, cette erreur est généralement causée par le chargement d'une DLL incompatible, par ex. une version 64 bits au lieu de 32 bits. Les suggestions que j'ai trouvées jusqu'à présent incluent:
- vérifier que j'utilise les versions 32 bits des DLL SDL2
- Installation / Réinstallation de la version X86 de Visual C ++ Redistributable pour Visual Studio 2015
- en utilisant Walker de dépendance pour résoudre le problème de la DLL à défaut
Mon projet est prêt à construire pour Win32 et je suis assuré que j'utilise les versions 32 bits de toutes les DLL que je liens explicitement (libfreetype-6, libpng16-16, sdl2, sdl2_image, sdl2_mixer, et sdl2_ttf). J'ai confirmé que la redistribution X86 VC ++ est installée sur ma machine.
Enfin, j'ai essayé d'utiliser la dépendance Walker pour déterminer ce que la DLL pourrait causer le problème (bien que j'ai lu des réserves que la dépendance Walker a beaucoup de faux positifs). C'étaient les résultats:
Analyse statique de la dépendance de dépendance
Résultats du profil de dépendance de dépendance
Après ce point, le profileur gèle et ne continue jamais. Notez que les composants SDL et le temps d'exécution VC se chargent sans erreur.
Le programme compile et charge correctement sur mes deux machines plus anciennes, une Windows 7 32 bits 7 et une exécutant 64 bits Windows 10.
Maintenant pour la question réelle. Quelles autres étapes puis-je prendre pour déboguer cet accident? Ou quelqu'un voit-il de l'information que j'ai fournis ce que je fais mal?
Questions connexes:
- L'application n'a pas pu démarrer correctement (0xc000007b)
- Gagnez 7, 64 bits, problèmes DLL
- Utiliser Sdl_image in Visual Studio 2010, avec erreur "L'application n'a pas pu démarrer correctement 0xc000007b"
EDIT:
Comme Rflobao suggérait, j'utilisais la version 64 bits de Walker de dépendance sur un EXE 32 bits. Voici la nouvelle sortie de ma course de profilage:
À ce stade, comme avant, Walker de dépendance gèle. Je suis toujours totalement perdu et ne vous sentez pas de plus près de pouvoir déterminer ce qui cause le problème.
3 Réponses :
Notez que la dépendance Walker a une version 32 et 64 bits. Si votre application est 32 bits, vous devez utiliser la version 32 bits. Sinon, le Walker de dépendance verra les libs à System32 et non Siswow64. Vous affichez 32 bits et 64 bits libs mélangés, où 64 a une erreur.
C'était en effet l'un de mes problèmes. J'utilisais le walker de dépendance 64 bits sur mon exécutable 32 bits. Merci! Mise à jour de ma question avec la nouvelle sortie.
Vérifiez dans la dépendance Walker "Sans exécution", si elle existe un peu de Lib 64 bits. Si toutes les libs sont 32 bits, est probablement que la libs64 est chargée de manière dynamique en mode paresseux. Assurez-vous que toutes les libs utilisées par votre projet (libfreetype-6, libpng16-16, sdl2, sdl2_image, sdl2_mixer et sdl2_ttf, ...) sont compilées 32 bits.
Ce n'est en aucun cas complètement fiable, mais vous pouvez essayer d'essayer. Il nécessite BUTHBIN.EXE, qui est incluse avec Visual Studio.
Premièrement, obtenez une liste des DLL à charge pour votre programme, résolu sur votre chemin: P>
C:\Windows\System32\kernel32.dll
8664 machine (x64)
C:\programs\ed23\bin\hydra.dll
14C machine (x86)
C'est vraiment utile! Cette technique montre que Windows recherche les versions 64 bits de msvcp140d.dll, vcruntime140d.dll, ucrtbased.dll et kernel32.dll, dans system32. Existe-t-il un paramètre de projet Visual Studio, je peux changer pour que Windows regarde dans SYSWOW64 pour les versions 32 bits à la place?
Je me sens profondément stupide, mais j'ai finalement compris le vrai problème. J'utilise la bibliothèque de polices SDL SDL2_TTF, et je n'avais tout simplement pas copié zlib.dll à partir du répertoire SDL2_TTF liber dans mon répertoire de construction. Je ne comprends pas pourquoi le message d'erreur était si cryptique; Dans le passé, les dlls manquants m'ont donné un message d'erreur "foo.dll utile".
Quoi qu'il en soit, merci à tous pour votre aide. Au moins, j'ai appris une leçon utile: assurez-vous toujours que toutes les DLL requises sont présentes avant de soupçonner un problème plus complexe.
C'était mon problème aussi! Cela m'ont dérangé depuis plus d'un mois. Apparemment, j'avais une autre copie de zlib1.dll de 64 bits ailleurs sur mon chemin, la construction de mon projet 64 bits a bien fonctionné.
Le système d'exploitation Windows est responsable de rechercher et trouver la première dll qui a un nom correspondant. Ce qui peut se passer, c'est qu'il existe un composant 64 bits que vous ne savez peut-être pas que celui-ci est situé dans un répertoire de votre chemin système, et Windows arrive à trouver cette DLL et tente de le charger.
Ça a du sens. Savez-vous un moyen systématique pour moi de déterminer lequel c'est? Walker de dépendance semble être trop obsolète pour être utile et il y a bien sûr plusieurs centaines de DLL qui peuvent être trouvés sur mon chemin.
Dans le Walker de dépendance, cliquez sur l'icône C: \ - qui vous dira où il s'agit de la prise des fichiers. Avez-vous essayé de l'exécuter à partir d'une invite CMD 64 bits (celle de Windows / System32) et d'une invite CMD 32 bits (celle de Windows / Sswow64).
Est-ce que vous atteignez la fonction principale? Avez-vous installé les redistres de 2015 sur cette machine?
En fait, votre exe 64 bits doit être chargée d'une DLL 32bits, copier toutes les DLL vers le même répertoire que l'EXE et vérifier si cela fonctionne, confirmez également que chaque DLL est en réalité 64 bits.