Aplikacja nie mogła się poprawnie uruchomić (0xc000007b)

Mam aplikację typu klient / serwer, którą tworzyłem na jednym komputerze. Teraz potrzebuje dwóch portów szeregowych, więc pożyczyłem komputer od znajomego.

Kiedy buduję swoją aplikację i próbuję ją uruchomić lub debugować (czy to w środowisku Delphi IDE, czy w menedżerze plików Windows), wyświetla się komunikat „Aplikacja nie mogła się poprawnie uruchomić (0xc000007b)”.

Googlowanie nie przynosi zbyt wiele, ale wydaje się wskazywać, że nie jest to nic specyficznego dla Delphi i dzieje się z innymi aplikacjami. Wydaje się, że jest to spowodowane wywołaniem 32-bitowej biblioteki DLL z aplikacji 64-bitowej lub odwrotnie.

• oba komputery mają 64-bitowy system Windows 7
• oba mają startową edycję Delphi Xe2, która obsługuje tylko 32 bity
• Aplikacja działa dobrze na moim komputerze, ale nie na moim znajomym
• Inne aplikacje Delphi działają dobrze na obu komputerach

Czy ktoś może mi podpowiedzieć, jak to wyśledzić?

Na początek proponuję przetestować, czy istnieje problem między twoją aplikacją a jej zależnościami za pomocą narzędzia do przechodzenia zależności

Nie można rozwiązać zależności czasu ładowania. Najłatwiejszym sposobem debugowania tego jest użycie Dependency Walker . Użyj opcji Profil, aby uzyskać dane wyjściowe diagnostyki procesu ładowania. Pozwoli to zidentyfikować punkt awarii i poprowadzi Cię do rozwiązania.

Najczęstszą przyczyną tego błędu jest próba załadowania 64-bitowej biblioteki DLL do procesu 32-bitowego lub odwrotnie.

Jest to brakująca biblioteka DLL. Prawdopodobnie twoja biblioteka dll, która współpracuje z portami com, ma nierozwiązaną zależność dll. Możesz użyć walkera zależności i debuggera systemu Windows. Na przykład sprawdź całą bibliotekę mfc. Możesz także użyć nrCommlib - jest to świetne komponenty do pracy z portami komunikacyjnymi.

Wypróbowałem wszystkie wymienione tutaj rzeczy i znalazłem inną odpowiedź. Musiałem skompilować moją aplikację z 32-bitowymi bibliotekami DLL. Zbudowałem biblioteki zarówno w wersji 32-bitowej, jak i 64-bitowej, ale miałem PATHustawione biblioteki 64-bitowe. Po ponownym skompilowaniu mojej aplikacji (z pewną liczbą zmian w moim kodzie) otrzymałem ten przerażający błąd i walczyłem przez dwa dni. Wreszcie, po wypróbowaniu wielu innych rzeczy, zmieniłem ustawienia, PATHaby mieć 32-bitowe biblioteki DLL przed 64-bitowymi bibliotekami DLL (mają te same nazwy). I zadziałało. Po prostu dodam go tutaj dla kompletności.

Wspomniano już we wcześniejszych odpowiedziach, że użycie walkera zależności jest drogą do zrobienia, w moim przypadku (moja aplikacja ciągle zawodzi z kodem błędu), Dependency Walker pokazał kilka plików DLL, które NIE są istotne!

Wreszcie zorientowałem się, że mogę uruchomić profilowanie, przechodząc do menu "profil", a aplikacja uruchomi się i zatrzyma na dokładnym pliku dll, który jest przyczyną problemu! Dowiedziałem się, że wybrano 32-bitową bibliotekę DLL ze względu na ścieżkę i naprawiłem ją.

Niedawno miałem problem z tworzeniem aplikacji (która korzystała z portu szeregowego) i działała na wszystkich maszynach, na których ją testowałem, ale kilka osób otrzymywało ten błąd.

Okazuje się, że wszystkie maszyny, na których wystąpił błąd, działały pod systemem Win7 x64 i NIGDY RAZEM nie były aktualizowane.

Uruchomienie aktualizacji systemu Windows naprawiło wszystkie komputery w moim konkretnym przypadku.

Doświadczyłem tego samego problemu podczas tworzenia aplikacji klient-serwer przy użyciu Microsoft Visual Studio 2012.

Jeśli do tworzenia aplikacji korzystałeś z programu Visual Studio, musisz upewnić się, że nowy (tj. Komputer, na którym oprogramowanie nie zostało opracowane) ma odpowiedni pakiet redystrybucyjny Microsoft Visual C ++. Potrzebujesz odpowiedniego roku i wersji bitowej (np. X86 dla wersji 32-bitowej i x64 dla wersji 64-bitowej) pakietu redystrybucyjnego Visual C ++.

Pakiety redystrybucyjne Visual C ++ instalują składniki czasu wykonywania, które są wymagane do uruchamiania aplikacji C ++ utworzonych przy użyciu programu Visual Studio.

Oto łącze do pakietu redystrybucyjnego Visual C ++ dla programu Visual Studio 2015 .

Możesz sprawdzić, jakie wersje są zainstalowane, przechodząc do Panelu sterowania -> Programy -> Programy i funkcje.

Oto jak otrzymałem ten błąd i naprawiłem go:

1) Stworzyłem aplikację 32-bitową przy użyciu programu Visual Studio 2012 na moim komputerze. Nazwijmy mój komputer ComputerA.

2) Zainstalowałem plik .exe i powiązane pliki na innym komputerze, który nazwiemy ComputerB.

3) Na komputerze B uruchomiłem plik .exe i otrzymałem komunikat o błędzie.

4) Na ComputerB przyjrzałem się programom i funkcjom i nie widziałem pakietu redystrybucyjnego Visual C ++ 2012 (x64).

5) Na komputerze B wyszukałem w Google pakiet redystrybucyjny Visual C ++ 2012, wybrałem i zainstalowałem wersję x64.

6) Na komputerze B uruchomiłem plik .exe na komputerze B i nie otrzymałem komunikatu o błędzie.

W rzeczywistości ten błąd wskazuje na nieprawidłowy format obrazu. Jednak dlaczego tak się dzieje i co zwykle oznacza kod błędu? W rzeczywistości może się to pojawić, gdy próbujesz uruchomić program, który jest przeznaczony lub przeznaczony do pracy z 64-bitowym systemem operacyjnym Windows, ale Twój komputer działa w 32-bitowym systemie operacyjnym.

Możliwe przyczyny:

• Microsoft Visual C ++
• Musisz ponownie uruchomić
• DirectX
• .NET Framework
• Musisz ponownie zainstalować
• Musisz uruchomić aplikację jako administrator

Źródło: http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/

Może to być przypadek, w którym debugowanie debugera może być przydatne. Zasadniczo, jeśli postępujesz zgodnie z instrukcjami tutaj , możesz uruchomić dwa idee, a jeden będzie debugować w drugim. Jeśli umieścisz swoją aplikację w jednym, możesz czasami wyłapać błędy, które w innym przypadku byś przeoczył. Warto spróbować.

Widziałem błąd podczas próby uruchomienia pliku wykonywalnego debugowania VC ++ na komputerze, na którym nie zainstalowano programu Visual C ++. Stworzenie wersji wydania i użycie tego naprawiło to.

W moim przypadku błąd wystąpił, gdy zmieniłem nazwę biblioteki DLL po jej zbudowaniu (przy użyciu programu Visual Studio 2015), tak aby pasowała do nazwy oczekiwanej przez plik wykonywalny, który był zależny od biblioteki DLL. Po zmianie nazwy lista wyeksportowanych symboli wyświetlona przez Dependency Walker była pusta i pojawił się wspomniany komunikat o błędzie „Aplikacja nie mogła się poprawnie uruchomić”.

Więc można to naprawić, zmieniając nazwę pliku wyjściowego w opcjach konsolidatora programu Visual Studio.

Możesz to zrobić, jeśli próbujesz zamanifestować swoją aplikację, że jest ona zależna od zestawu Microsoft.Windows.Common-Controls . Robisz to, gdy chcesz załadować wersję 6 wspólnej biblioteki kontrolek - aby style wizualne były stosowane do wspólnych kontrolek.

Prawdopodobnie skorzystałeś z oryginalnej dokumentacji Microsoftu z czasów Windows XP i dodałeś następujące elementy do manifestu swojej aplikacji:

<!-- 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 nie jest już systemem operacyjnym i nie jesteś już aplikacją 32-bitową. W ciągu ostatnich 17 lat Microsoft zaktualizował swoją dokumentację ; teraz nadszedł czas, aby zaktualizować swój manifest:

<!-- 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 ma cudowną historię wspólnych elementów sterujących:

• Historia wspólnych elementów sterujących systemu Windows XP ( archiwum )

Właśnie rozwiązałem ten problem dla mojego osobistego projektu (dzięki za to Driesowi). Dla mnie to dlatego, że ścieżka projektu była zbyt długa. Po zapisaniu .sln w krótszej ścieżce (C: / MyProjects) i skompilowaniu stamtąd działał bez błędu.

Pobierz także i rozpakuj „Zależności” do tego samego folderu, w którym umieściłeś wget.exe

http://gnuwin32.sourceforge.net/packages/wget.htm

Będziesz wtedy mieć kilka plików lib * .dll, a także wget.exe w tym samym folderze i powinno działać dobrze.

(Odpowiedziałem również tutaj https://superuser.com/a/873531/146668, które pierwotnie znalazłem.)

Właśnie natknąłem się na ten problem. Szukałem „C ++” w moim „Aplikacje i funkcje” w panelu sterowania Windows 10 i zauważyłem, że jakiś rodzaj aktualizacji został uruchomiony kilka dni wcześniej i zainstalowałem pakiet redystrybucyjny VC ++ 2012-2017. Aplikacja, która wyświetlała komunikat o błędzie, wymagała tylko VC ++ 2010. Odinstalowałem je wszystkie, a następnie ponownie zainstalowałem tylko 2010 x86 / x64 i błąd zniknął, a aplikacja działała zgodnie z oczekiwaniami.

Może się tak zdarzyć, jeśli z jakiegoś powodu zasób x86 jest ładowany z maszyny x64. Aby tego uniknąć, dodaj tę dyrektywę preprocesora do stdafx.h (oczywiście w moim przykładzie problematycznym zasobem jest biblioteka DLL Windows Common Controls.

#if defined(_WIN64)
#pragma comment(linker, "\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'\"")
#endif

Możliwe, że masz w systemie wiele wersji bibliotek dll. Możesz przeszukać swój system, aby się tego dowiedzieć. Problem można rozwiązać, po prostu zmieniając kolejność katalogów na ścieżce. To był mój problem. ( Nie można uruchomić interfejsu GUI kreatora Qt poza Qt. Błąd „Aplikacja nie mogła poprawnie uruchomić się (0xc000007b)” )