Ik heb een client/server-app die ik op een enkele pc heb ontwikkeld. Nu heeft het twee seriële poorten nodig, dus ik leende een pc van een vriend.
Als ik mijn app bouw en probeer deze uit te voeren of fouten op te sporen (in de Delphi IDE of vanuit Windows Bestandsbeheer), krijg ik de foutmelding “De toepassing kon niet correct starten (0xc000007b)”.
Googelen levert niet veel op, maar lijkt erop te wijzen dat dit niets Delphi-specifiek is en met andere apps gebeurt. Het lijkt te worden veroorzaakt door het aanroepen van een 32-bits DLL vanuit een 64-bits app of omgekeerd.
- beide pc’s zijn Windows 7, 64 bit
- beiden hebben de Delphi Xe2-startversie die maar 32 bits aankan
- De app werkt prima op mijn pc, maar niet op die van mijn vriend
- Andere Delphi-apps werken prima op beide pc’s
Kan iemand me een hint geven hoe ik dit kan opsporen?
Antwoord 1, autoriteit 100%
Om te beginnen zou ik willen voorstellen om te testen of er een probleem is tussen uw toepassing en de bijbehorende afhankelijkheden met behulp van dependency walker
Antwoord 2, autoriteit 41%
Een afhankelijkheid van de laadtijd kan niet worden opgelost. De eenvoudigste manier om dit te debuggen is door Dependency Walker te gebruiken. Gebruik de optie Profiel om diagnostische uitvoer van het laadproces te krijgen. Dit zal het punt van mislukking identificeren en u naar een oplossing leiden.
De meest voorkomende oorzaak van deze fout is het proberen een 64-bits DLL in een 32-bits proces te laden, of omgekeerd.
Antwoord 3, autoriteit 9%
Het is een ontbrekende dll.
Mogelijk heeft uw dll die met com-poorten werkt een onopgeloste dll-afhankelijkheid.
U kunt afhankelijkheidswandelaar en Windows Debugger gebruiken. Controleer bijvoorbeeld de hele mfc-bibliotheek. Je kunt ook nrCommlib gebruiken – het zijn geweldige componenten om met com-poorten te werken.
Antwoord 4, autoriteit 9%
Ik heb alle dingen geprobeerd die hier zijn gespecificeerd en heb nog een ander antwoord gevonden. Ik moest mijn applicatie compileren met 32-bits DLL’s. Ik had de bibliotheken zowel in 32-bits als in 64-bits gebouwd, maar had mijn PATH ingesteld op 64-bits bibliotheken. Nadat ik mijn applicatie opnieuw had gecompileerd (met een aantal wijzigingen in mijn code ook) kreeg ik deze gevreesde fout en worstelde ik twee dagen. Ten slotte, na een aantal andere dingen te hebben geprobeerd, heb ik mijn PATH gewijzigd om de 32-bits DLL’s vóór de 64-bits DLL’s te hebben (ze hebben dezelfde namen). En het werkte. Ik voeg het hier alleen voor de volledigheid toe.
Antwoord 5, autoriteit 7%
In eerdere antwoorden is al vermeld dat het gebruik van dependency walker de beste keuze is, in mijn geval (mijn toepassing faalt steeds met de foutcode), liet de dependency walker een paar dll’s zien die NIET relevant zijn!
Eindelijk bedacht dat ik profilering kan uitvoeren door naar het “profiel”-menu te gaan en het zal de applicatie uitvoeren en stoppen bij de exacte dll die het probleem veroorzaakt! Ik ontdekte dat er een 32-bits dll was gekozen vanwege het pad en ik heb het opgelost.
Antwoord 6, autoriteit 4%
Ik ondervond hetzelfde probleem bij het ontwikkelen van een client-server-app met Microsoft Visual Studio 2012.
Als u Visual Studio hebt gebruikt om de app te ontwikkelen, moet u ervoor zorgen dat de nieuwe (d.w.z. de computer waarop de software niet is ontwikkeld) het juiste Microsoft Visual C++ Redistributable Package heeft. Eventueel hebt u het juiste jaar en de juiste bitversie nodig (d.w.z. x86 voor 32 bit en x64 voor 64 bit) van het Visual C++ Redistributable Package.
De Visual C++ Redistributable Packages installeren runtime-componenten die nodig zijn om C++-applicaties uit te voeren die zijn gebouwd met Visual Studio.
Hier is een link naar de Visual C++ Redistributable voor Visual Studio 2015 .
U kunt controleren welke versies zijn geïnstalleerd door naar Configuratiescherm -> Programma’s -> Programma’s en functies.
Dit is hoe ik deze fout heb gekregen en het heb opgelost:
1) Ik heb een 32-bits applicatie ontwikkeld met Visual Studio 2012 op mijn computer.
Laten we mijn computer ComputerA noemen.
2) Ik heb de .exe en de gerelateerde bestanden op een andere computer geïnstalleerd die we ComputerB zullen noemen.
3) Op ComputerB heb ik de .exe uitgevoerd en kreeg de foutmelding.
4) Op ComputerB keek ik naar de programma’s en onderdelen en zag ik Visual C++ 2012 Redistributable (x64) niet.
5) Op ComputerB heb ik gegoogeld naar Visual C++ 2012 Redistributable en heb ik de x64-versie geselecteerd en geïnstalleerd.
6) Op ComputerB heb ik de .exe op ComputerB uitgevoerd en heb ik de foutmelding niet ontvangen.
Antwoord 7, autoriteit 4%
Ik had onlangs een probleem waarbij ik een applicatie aan het ontwikkelen was (die een seriële poort gebruikte) en het werkte op alle machines waarop ik het heb getest, maar een paar mensen kregen deze foutmelding.
Het blijkt dat alle machines waarop de fout zich voordeed, Win7 x64 draaiden en NOOIT EENMAAL waren bijgewerkt.
Het uitvoeren van een Windows-update loste in mijn specifieke geval alle machines op.
Antwoord 8, autoriteit 2%
In feite duidt deze fout op een ongeldig beeldformaat. Maar waarom gebeurt dit en wat betekent de foutcode meestal? Dit kan in feite verschijnen wanneer u een programma probeert uit te voeren dat is gemaakt voor of bedoeld is om te werken met een 64-bits Windows-besturingssysteem, maar uw computer draait op een 32-bits besturingssysteem.
Mogelijke redenen:
- Microsoft Visual C++
- Moet opnieuw opstarten
- DirectX
- .NET Framework
- Moet opnieuw worden geïnstalleerd
- Moet de applicatie als beheerder uitvoeren
Antwoord 9
Dit kan een geval zijn waarbij het debuggen van de debugger nuttig kan zijn. Als je de instructies hier volgt, kun je twee ide’s uitvoeren en één zal debuggen in de andere. Als u uw toepassing in één verwijdert, kunt u soms fouten opvangen die u anders zou missen. Het is het proberen waard.
Antwoord 10
Ik heb de fout gezien bij het uitvoeren van het uitvoerbare bestand van VC++ debug op een machine waarop Visual C++ niet was geïnstalleerd. Een releaseversie bouwen en die gebruiken loste het op.
Antwoord 11
In mijn geval trad de fout op toen ik een DLL hernoemde nadat ik deze had gebouwd (met Visual Studio 2015), zodat deze past bij de naam die wordt verwacht door een uitvoerbaar bestand, dat afhankelijk is van de DLL. Na het hernoemen was de lijst met geëxporteerde symbolen die door Dependency Walker werd weergegeven leeg en werd het genoemde foutbericht “De toepassing kon niet correct starten” weergegeven.
Het kan dus worden opgelost door de naam van het uitvoerbestand te wijzigen in de Visual Studio-linkeropties.
Antwoord 12
U kunt dit hebben als u probeert uw toepassing te laten zien dat deze afhankelijk is van de Microsoft.Windows.Common-Controls-assembly. U doet dit wanneer u versie 6 van de bibliotheek met gemeenschappelijke besturingselementen wilt laden, zodat visuele stijlen worden toegepast op gemeenschappelijke besturingselementen.
Je hebt waarschijnlijk de originele documentatie van Microsoft gevolgd vanaf de tijd van Windows XP, en het volgende aan het manifest van je toepassing toegevoegd:
<!-- 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 is niet langer het besturingssysteem en u bent niet langer een 32-bits toepassing. In de tussenliggende 17 jaar heeft Microsoft hun documentatie bijgewerkt; nu is het tijd voor u om uw manifest bij te werken:
<!-- 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 heeft een mooie geschiedenis van de Common Controls:
Antwoord 13
Zojuist dit probleem opgelost voor mijn persoonlijke project (met dank aan Dries daarvoor). Voor mij was het omdat het projecttraject te lang was. Na het opslaan van de .sln naar een korter pad (C:/MyProjects) en het van daaruit compileren liep het zonder de fout.
Antwoord 14
Download en pak “Afhankelijkheden” ook uit in dezelfde map waar u de wget.exe vandaan hebt geplaatst
http://gnuwin32.sourceforge.net/packages/wget.htm
Je hebt dan een aantal lib*.dll-bestanden en wget.exe in dezelfde map en het zou goed moeten werken.
(Ik antwoordde hier ook https://superuser.com/a/873531/146668 die ik oorspronkelijk vond. )
Antwoord 15
Ik kwam dit probleem net tegen. Ik zocht naar “C++” onder mijn “Apps en functies” in het configuratiescherm van Windows 10 en merkte dat er een paar dagen eerder een update was uitgevoerd en installeerde VC++ Redistributable 2012-2017. De app die de foutmelding tegenkwam, vereiste alleen VC ++ 2010. Ik heb ze allemaal verwijderd en vervolgens alleen 2010 x86/x64 opnieuw geïnstalleerd, en de fout ging weg en de applicatie functioneerde zoals verwacht.
Antwoord 16
Dat kan gebeuren als om de een of andere reden een x86-bron wordt geladen vanaf een x64-machine. Om dat expliciet te voorkomen, voegt u deze preprocessor-richtlijn toe aan stdafx.h (in mijn voorbeeld is de problematische bron natuurlijk de 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
Antwoord 17
Het is mogelijk dat u meerdere versies van de dll(‘s) op uw systeem heeft staan. U kunt uw systeem doorzoeken om erachter te komen. Het probleem kan worden opgelost door simpelweg de volgorde van de mappen in uw pad te wijzigen. Dit was mijn probleem. (Kan niet voer Qt Creator GUI uit buiten Qt. “De toepassing kon niet correct starten (0xc000007b)” fout)
Antwoord 18
Het grootste probleem is natuurlijk dat een DLL-bestand ontbreekt of, nog waarschijnlijker, beschadigd is. Als dit het geval is, heb ik een paar goede ideeën (vooral als je handmatig een DLL hebt gedownload en geïnstalleerd!)…
TLDR: verwijder elke handmatig gekopieerde/geplakte DLL die je hebt gedaan, verwijder oude herdistribueerbare installaties en installeer nieuwe herdistribueerbare bestanden voor beide 32 -bits en 64-bits installaties.
Wat te doen
Deze oplossing van het kopiëren/plakken van ontbrekende DLL’s in system32, enz., werkte sinds ik me kan herinneren in de jaren ’90, maar het lijkt niet meer te werken (2020). Dus als je recentelijk tegen dit probleem aanloopt, raad ik het volgende aan:
- Binnen
windows\system32enwindows\SysWOW64verwijdert u alle bestanden die overeenkomen metms*.dlldie het besturingssysteem u toestaat verwijderen als beheerder. - Verwijder alle Visual C++ Redistributables die u bij Windows hebt. Dit voorkomt dat de “Je hebt dit al!” dialoogvenster verschijnt bij opnieuw installeren, zoals beschreven in de volgende stap wanneer we opnieuw installeren.
- Installeer de 2015-2019 Visual C++ Redistributable opnieuw vanaf een regelmatig beschikbare downloadsite. Als dit niet werkt, download en installeer dan de anderen, maar persoonlijk dekte de 2015-2019 alles voor mij. Ongeacht uw computer, installeer zowel x32- als x64-pakketten! (Alle downloadlinks: Verzamelde VC++-downloadlinks; MSVCR120.dll Fix; MFC140U.dll Fix.)
Hoe u weet dat het werkt
Er is veel variatie in codeurs die dit ervaren, dus het idee dat er één enkele mogelijke oplossing is, wordt vaak verworpen, maar laten we positief zijn!
- Als het verwijderen van de overeenkomende
ms*.dll-bestanden werkte, krijg je geen foutmelding meer overerror code 0xc000007b. In plaats daarvan krijg je een bericht over een ontbrekende.dll. Dit vertelt je dat je het juiste codepad hebt gevonden! - Als de herdistribueerbare werken worden geïnstalleerd, moeten bepaalde populaire DLL-bestanden in de bovengenoemde mappen
system32enSysWO64verschijnen. Bijvoorbeeld:MSVCR120.dll,MSVCR140.dll,MSVCR100.dll,MSVCP100.dll,MSVCP120.dll,MSVCP140.dllen vrienden.
Laatste, mogelijk beste kansen
Soms werken dingen niet volgens plan (zoals we allemaal in de Windows-wereld weten). Je kunt ook het volgende proberen!
- Open het tabblad ‘Windows-onderdelen in- of uitschakelen’ in Windows (ondersteund in Windows 8-10). Schakel de
.NET Frameworkinstallaties uit. Je ziet een kleine installatie voorbij gaan. - Start het systeem opnieuw op. Ga opnieuw naar de bovenstaande functie, controleer
.NET Frameworkopnieuw en klik op “oke”. Als dit werkt, ziet u een bericht “installeren en bijwerken van .NET-framework” dat misschien een minuut duurt. Zodra dit is gebeurd, raad ik aan om opnieuw op te starten.
Veel succes!
Antwoord 19
Ik kwam dit probleem tegen bij het ophalen van code uit mijn repository en het compileren op een nieuwe machine. Het kopiëren van de hele repository en vervolgens compileren resulteerde in een uitvoerbaar bestand dat werkte. Blijkt dat een 32-bits DLL per ongeluk niet is ingecheckt. Zoals de mensen hierboven aangeven, gebruik “Dependency Walker” om erachter te komen waar het fout gaat.
Om het duidelijker te maken waarnaar te zoeken, zie de onderstaande schermafbeelding, met op de achtergrond de exe die de verkeerde DLL probeert te laden (let op de ’64’), wat resulteert in “de toepassing kon niet correct starten 0xc00007b” en in op de voorgrond de exe die eenvoudig werd gekopieerd (die de juiste DLL bevatte).
