l'application n'a pas réussi à démarrer correctement (0xc00007b) - visual studio

Bonjour à tous :)

Alors voilà mon nouveau problème:

J'ai un pc windows 7 x64 (non c'est pas ça mon problème, j'ai rien contre windows).

J'ai configuré mon projet visual studio 2010 en x86 (32 bits), car j'utilise une bibliothèque d'OCR qui est en 32 bits (je fais de l'analyse d'images).

Mon programme a donc compilé sans aucune erreur majeure, seulement quelques avertissements.

Seulement lorsque je souhaite lancer mon .exe ainsi généré par la compilation, j'obtiens l'erreur définie dans le titre !

Je suppose que c'est parce que le .exe généré est en 32 bits ? Seulement je n'arrive pas à résoudre ce problème....

Merci de votre aide.

Moi je regarderais du coté des éventuelles DLL de ta librairie d'OCR qui ne serait pas compatible

Ok ça marche, je vais voir ça !

Il s'agit des dll présentes dans ce dossier de téléchargement:

https://code.google.com/p/tesseract-...s.zip&can=2&q=


Il s'agit donc de dll tesseract pour windows 32 (la version tesserract win64 je ne l'ai pas trouvée!)

Pour vérifier tout ça, le mieux serait que j'essaye de lancer mon programme sur un PC win 32....

Sinon il n'y a pas moyen (autre que machine virtuelle j'ai horreur de ça) de lancer un programme win32 sur un pc win64 ?

Citation:

---

Envoyé par wilfryjules

Sinon il n'y a pas moyen (autre que machine virtuelle j'ai horreur de ça) de lancer un programme win32 sur un pc win64 ?

---

Ce ne serait pas un pêu nativement supporté, par hasard ;-)

Normalement un programme Win32 x86 tourne nativement sur un Win64 x86-64 (via WOW64).
Par contre, sur un Win64 Itanium, je ne sais pas.

Et surtout, l'EXE et les DLL doivent tous avoir la même bitness (tu ne peux pas charger une DLL 32 bits dans une application 64 bits ou inversement).

Tu peux utiliser Dependency Walker pour voir si ce genre de problème se produit...

@Medinoc
Tu as raison, un itanium n'est tout bonnement pas capable d'exécuter du code 32 bits. Par contre, pour un PC win64 qui est selon toute probabilité équipé d'un x86_64, c'est bon (par WOW64, comme tu le soulignais).
@wilfryjules: en résumé, sur un PC tu n'as rien à faire pour pouvoir exécuter du code 32 bits, ça marche.
Par contre, effectivement, indépendemment de l'environnement, ton application doit être cohérente (tout en 3 ou tout en 64) sinon ça ne marchera pas.

Oui c'est ce que je pense aussi... normalement les pc 64 supportent les appli 32 bits... donc le soucis doit venir d'ailleurs.

Concernant le répertoire c -> windows -> sysWOW64, j'avais fait l'erreur de changer deux ou trois dll par d'autres dll du même nom (javais suivi un mauvais tuto pour résoudre cette erreur ) ce qui m'a ensuite valu de réinstaller visual studio, car il ne démarrait plus...

Une fois la réinstallation terminée, j'ai vaincu ce problème, sauf que je suis retombé sur mon erreur de départ (titre de ce sujet)....

J'espère que je n'ai pas fait de bêtises avec cette histoire de dll, je n'ai pas la liste pour l'instant je suis au boulot, j'indiquerai de quelles dll il s'agit ce soir. .... en tout cas toutes mes autres applis fonctionnent, y compris mes autres programmes visual studio, que je peux compiler et exécuter sans aucun soucis depuis ma console cmd.

Citation:

---

Envoyé par wilfryjules

Concernant le répertoire c -> windows -> sysWOW64, j'avais fait l'erreur de changer deux ou trois dll par d'autres dll du même nom (javais suivi un mauvais tuto pour résoudre cette erreur ) ce qui m'a ensuite valu de réinstaller visual studio, car il ne démarrait plus...

---

beware avec le remplacement de DLL système ou de DLL de logiciels avec des DLL de pedigree douteux récupérées sur internet, outre casser le système c'est un excellent moyen de se faire contaminer par des virus et autre malwares...

Aussi, lorsque je redémarre mon pc, la même erreur s'affiche pour le programme NBAgent cette fois:

NBAgent.exe

L'application n'a pas réussi à démarrer correctement (0x000007b)
Cliquez sur OK pour fermer l'application.

Voici les dll en question que j'ai touchées dans wow64
mfc100u.dll
msvcp100.dll
mfc100.dll
msvcr100_clr0400.dll

Je les avais remplacées par les même dll suite à ma première erreur 0x000007b, mais ensuite je ne pouvais plus démarrer visual studio, donc je l'ai réinstallé et la tout va bien à nouveau, mais j'ai toujours l'erreur 0x000007b lorsque j'exécute le .exe générée dans mon debug.
De plus, mon autre programme .exe visual studio compilé en x64 s'exécute sans aucune erreur. Il n'y a que celui la, que j'ai paramétré en x86, qui refuse de démarrer...

Enfin, voici l'erreur que j'ai si j'exécute mon programme depuis visual studio (flèche lecture verte) :


'PlaqueOCR.exe'*: Chargé 'C:\Users\julien\Documents\Visual Studio 2010\Projects\PlaqueOCR\Debug\PlaqueOCR.exe', Les symboles ont été chargés.
'PlaqueOCR.exe'*: Chargé 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'PlaqueOCR.exe'*: Chargé 'C:\Program Files\AVAST Software\Avast\snxhk.dll', Cannot find or open the PDB file
'PlaqueOCR.exe'*: Chargé 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'PlaqueOCR.exe'*: Chargé 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
Le programme '[2424] PlaqueOCR.exe: Natif' s'est arrêté avec le code -1073741701 (0xc000007b).


Pourtant toutes ces dll se trouvent bien sans SysWOW64 de mon ordinateur.

Salut,

Les fichiers PDB sont des fichiers créés en mode débug pour profiter de ce que micorsoft appelle la "compilation incrémentale".

Pour faire simple, disons que la compilation prend énormément de temps et que la solution trouvée par microsoft est de garder "l'historique" des compilations dans un fichier particulier (le fichier pdb) de manière à essayer de ne recompiler à chaque fois que ce qui doit réellement l'être et donc essayer de limiter le temps de compilation.

On pourrait le comparer un système de "diff" entre deux versions, adapté à la compilation ;)

Les raisons qui peuvent faire que le fichier pdb ne fonctionne pas sont multiples, mais tu as généralement deux solutions pour essayer de résoudre le problème :

La plus facile (mais celle qui prendra sans doute le plus de temps) consiste à faire un clean complet de ton projet avant de relancer la compilation (qui sera forcément complete).

La deuxième consiste à désactiver la compilation incrémentale, ce qui aura pour résultat de ne plus générer le fichier pdb vu qu'il sera devenu inutile.

Evidemment, cela aura aussi pour résultat de forcer la compilation de tout fichier modifier au lieu de ne nécessiter que la recompilation des seules fonctions qui ont été modifiées (et donc d'augmenter parfois très fort les temps de compilation).

Mais, comme les fichiers pdb que visual studio n'est pas capable de trouver sont des fichiers externes à ton projet, la première solution ne semble pas adaptée, simplement parce que une compilation complète de ton projet ne générera jamais les fichiers pdb pour les différentes dll dont ton projet dépend.

Pour autant que je me souvienne, visual studio 2010 compile par défaut en mode 64 bits.

Il n'est pas interdit de penser qu'il fournisse les fichiers pdb pour les différentes bibliothèques dans leurs version 64 bits mais qu'il ne fournisse pas les fichier pour leur version 32 bits.

Ce qui semble confirmé par le fait que ton projet ne souffre d'aucun problème lorsque tu le compile en mode 64bits ;)

Du coup, la seule solution qu'il te reste, c'est de faire en sorte que les fichiers pdb ne soient pas indispensables lorsque tu compile en mode débug 32bits. Et pour ce faire, ben, la seule solution est de désactiver la compilation incrémentale et de faire un clean du projet ;)

Le but des PDB (program data base) est de permettre de debugger les DLL (ils contiennent par exemple les noms des symboles dans le code source). S'ils ne sont pas présents, ce n'est pas grave, il ne te sera juste pas possible de debugger à l'intérieur des bibliothèques correspondantes. Je ne vois donc rien de vraiment louche dans le bout de log que tu nous donnes.

Reprenons à la base :
- Arrives-tu à compiler et lancer un hello world 32 bits sur ta machine ?
- Si tu mets un affichage tout en tête de ton programme, est-ce qu'il s'affiche ?
- Est-ce que tu arrives à lancer ton programme en debug ?

@Koala01: Je crois que tu confonds avec les .ILK (Incremental LinKing).

Ok merci à tous, au moins j'aurai appris à quoi servent les pdb... Je regarderai tout ça ce soir j'essaierai de désactiver la compilation incrémentale et de compiler un programme tout simple win32. Ce qui m'inquiète c'est qu'au démarrage de mon PC j'ai la même erreur 0xc000007b :roll:

Citation:

---

Envoyé par wilfryjules

Ok merci à tous, au moins j'aurai appris à quoi servent les pdb... Je regarderai tout ça ce soir j'essaierai de désactiver la compilation incrémentale et de compiler un programme tout simple win32. Ce qui m'inquiète c'est qu'au démarrage de mon PC j'ai la même erreur 0xc000007b :roll:

---

Cette erreur est, très certainement embêtante mais n'a sans doute absolument rien à voir...

L'erreur que tu as au démarrage provient d'un service (à déterminer) qui essaye de se lancer lors du démarrage de windows mais qui n'y arrive pas, pour une raison (à déterminer) ou une autre.

0xc000007b est, typiquement, une valeur qui fait penser à une adresse mémoire quelconque que certaines ressources sur le net n'hésitent pas (assez à mon gout) à assimiler à un problème avec directX / dll (j'ai aussi vu passer les noms de dll suivants, par exempe ;): mfc100u.dll, msvcr100.dll, msvcp100.dll and msvcr100_clr0400.dll).

Il semblerait que c'est souvent ( !!! mais pas forcément !!! ) du à une dll manquante. Ce peut être le résultat de la désinstallation un peu trop brutale d'une application.

Maintenant, sans savoir exactement quel programme n'arrive pas à se lancer, il devient difficile d'être plus précis :P

Mais, quoi qu'il en soit, si c'est peut être (surement) une cause commune pour ton problème de démarrage et ton problème d'exécution de ton application, il n'y a vraisemblablement aucun lien direct entre les deux problèmes, à part, bien sur, l'utilisation d'une dll bien particulière ;)

Salut à tous ! Me revoilà ! Merci pour toutes vos réponses !

Alors j'ai appliqué ma méthode bourrin: j'ai reformaté mon PC en état d'usine.

Je n'ai alors plus (heureusement) l'erreur au redémarrage de mon pc.

J'ai réinstallé visual studio 2010 et j'ai rebâti mon projet en x86 !

Encore une fois, la compilation s'est bien passée (hormis quelques avertissements avec ces pdb) mais j'ai toujours cette coriace erreur qui empêche l'application de démarrer, au détail près que ce n'est plus 0xc00007b, mais 0xc0150002:

COMPILATION:
OK aucune erreur à part des avertissements;

LANCEMENT DU .EXE :

"L'application n'a pas réussi à démarrer correctement (0xc0150002).
Cliquez sur OK pour fermer l'application."

J'ai trouvé l'erreur, cela vient de cette déclaration de la classe de la librairie OCR Tesseract:

Code:

---

1 2	tesseract::TessBaseAPI tess; // cette ligne fait tout planter

---

Ce code ne marche pas mieux:

Code:

---

1 2	tesseract::TessBaseAPI *tess = new tesseract::TessBaseAPI();

---

Par contre je ne sais pas à cette heure ci comment la régler,,,, ce code provient d'un exemple basique d'appel de la librairie, que j'ai récupéré sur le net.

Si j'en crois Google, là on retombe dans un terrain "connu": Il y a des gens qui discutent de ce problème.

Merci Médinoc ! Je vais aller fouiller un peu, et je compléterai ma page si je trouve de quoi débloquer cette erreur ! Car des forums sur Tesseract y en a un paquet, mais aucun de clair et rigoureux sur l'installation. Dès que j'ai toutes les données je fais une page claire !

Bonjour.

Citation:

---

Download : VC++ libraries of Tesseract OCR 3.02.02 (32bit)

Static and dynamic versions of tesseract 3.02.02 library including necessary header files. The libraries are built with Microsoft Visual Studio 2008 (C++ Express) 32-bit.

---

A vue de nez, je dirais quil suffit juste d'installer les derniers redistribuables VC-2008. Dans le cas où ils ne sont pas fournis avec le le Tesseract.

Tu veux dire que ça marcherait avec Visual Studio 2008 et pas avec le 2010 ?

Bonjour.

Non. Ce que je veux dire, c'est qu'un programme compilé avec la version de Visual Studio 2008, peut nécessiter l'installation des redistribuables 2008.

http://www.microsoft.com/fr-fr/downl...ils.aspx?id=29

Citation:

---

Le package redistribuable Microsoft Visual C++ 2008 (x86) installe les composants du runtime des bibliothèques Visual C++ nécessaires pour exécuter des applications développées en Visual C++ sur un ordinateur sur lequel Visual C++ 2008 n'est pas installé.

---

Le Tesseract a été développé avec Visual Studio 2008, je soupçonne donc que les redistribuables VC-2008 sont nécessaires. Dans tous les cas c'est la première chose que je vérifierais.

Attention quand même, j'ai pris le premier lien sur google. Il faut savoir que si le projet a été compilé avec Visual Studio 2008 update x, alors il faut le redistribuable vc 2008 version x... Et mon lien concerne la version x86.

PS: il faut avouer que l'histoire des redistribuables Visual Studio de chez Microsoft, ce n'est pas ce qu'ils ont fait de mieux... Mais bon c'est de notre faute à nous développeur, on a pas assez râlé.