O aplicativo não pôde iniciar corretamente (0xc000007b)

159

Eu tenho um aplicativo cliente / servidor que desenvolvi em um único PC. Agora, ele precisa de duas portas seriais, então peguei emprestado um PC de um amigo.

Quando crio meu aplicativo e tento executá-lo ou depurá-lo (seja no Delphi IDE ou no gerenciador de arquivos do Windows), ele erro "O aplicativo não pôde ser iniciado corretamente (0xc000007b)".

Pesquisando no Google não traz muita coisa, mas parece indicar que isso não é nada específico do Delphi e acontece com outros aplicativos. Parece ser causado pela chamada para uma DLL de 32 bits de um aplicativo de 64 bits ou vice-versa.

  • ambos os PCs são Windows 7, 64 bits
  • ambos têm a edição iniciada em Delphi Xe2, que suporta apenas 32 bits
  • O aplicativo funciona bem no meu PC, mas não no do meu amigo
  • Outros aplicativos Delphi funcionam bem nos dois PCs

Alguém pode me dar uma dica de como rastrear isso?

Mawg diz que restabelece Monica
fonte
6
Além disso, você pode usar o com0com para instalar portas seriais virtuais em um único PC. Ótimo para depuração e teste, basta criar 2 portas virtuais e vinculá-las na configuração, depois execute seus aplicativos em cada porta para que eles possam se comunicar.
Remy Lebeau
1
Você verificou o log de eventos do Windows? Às vezes, o Windows fornece mais informações sobre qual DLL fez o aplicativo falhar.
Luis Carrasco
1
Suspeito que seja uma DLL ausente, geralmente algum utilitário ou mesmo o gerenciador de memória.
Mj2008
4
@ mj2008 A falta de DLL fornece um erro diferente: O programa não pode ser iniciado porque está faltando XXXX.dll no seu computador. Tente reinstalar o programa para resolver este problema.
David Heffernan
3
@snd Este erro é STATUS_INVALID_IMAGE_FORMAT. Você não consegue isso quando o sistema não consegue encontrar uma DLL com esse nome. Você obtém STATUS_INVALID_IMAGE_FORMATquando uma DLL pode ser encontrada, mas está corrompida ou tem a testemunha errada.
David Heffernan

Respostas:

133

Para começar, sugiro testar se há um problema entre seu aplicativo e suas dependências usando o dependency walker

mox
fonte
31
com base nos códigos de erro do Windows ( google.de/… ), este código de erro significa: 0xC000007B STATUS_INVALID_IMAGE_FORMAT.
Mox
95
O que é uma boa indicação de que o aplicativo de 32 bits tentou carregar uma DLL de 64 bits.
Remy Lebeau
4
De fato, este arquivo PDF com código de erro é uma excelente fonte.
Mox
4
+1 e o aswer. Obrigado, dependente walker salvou o dia. Substituí uma DLL de 64 bits por uma versão de 32 bits e ela funciona agora.
Mawg diz que restabelece Monica
6
Certifique-se de ter a versão correta do Dependency Walker. O x86 depende exibirá resultados incorretos para binários x64.
precisa saber é o seguinte
53

Uma dependência de tempo de carregamento não pôde ser resolvida. A maneira mais fácil de depurar isso é usar o Dependency Walker . Use a opção Perfil para obter uma saída de diagnóstico do processo de carregamento. Isso identificará o ponto de falha e deverá guiá-lo para uma solução.

A causa mais comum desse erro é tentar carregar uma DLL de 64 bits em um processo de 32 bits ou vice-versa.

David Heffernan
fonte
2
+1. Observe também que você deve executar a versão de 32 bits do walker de dependência e garantir que todas as DLLs carregadas sejam de 32 bits. Se você tentar executar o walker de dependência da versão de 64 bits, ele carregará as DLLs de 64 bits, como o VCRedist, mesmo que você também tenha as versões de 32 bits.
liorda 14/09/17
12

É uma dll ausente. Possivelmente, sua dll que funciona com portas com uma dependência de dll não resolvida. Você pode usar o walker de dependência e o depurador do Windows. Verifique toda a biblioteca mfc, por exemplo. Além disso, você pode usar o nrCommlib - são ótimos componentes para trabalhar com portas de comunicação.

Alex.kononov
fonte
12

Eu tentei todas as coisas especificadas aqui e encontrei mais uma resposta. Eu tive que compilar meu aplicativo com DLLs de 32 bits. Eu construí as bibliotecas em 32 e 64 bits, mas tenho meu PATHconjunto para bibliotecas de 64 bits. Depois que recompilei meu aplicativo (com várias alterações no meu código), recebi esse erro temido e lutei por dois dias. Finalmente, depois de tentar várias outras coisas, mudei meu PATHpara ter as DLLs de 32 bits antes das DLLs de 64 bits (elas têm os mesmos nomes). E funcionou. Estou apenas adicionando aqui para completar.

unxnut
fonte
9

Já foi mencionado em respostas anteriores que, no meu caso (usar o walker de dependência), o walker de dependência mostrou algumas dll que NÃO são relevantes!

Finalmente descobri que eu posso executar a criação de perfil, indo ao menu "perfil" e ele executará o aplicativo e parará na DLL exata que está causando o problema! Eu descobri que uma DLL de 32 bits foi escolhida por causa do caminho e a corrigi.

insira a descrição da imagem aqui

pktCoder
fonte
5

Recentemente, tive um problema em que estava desenvolvendo um aplicativo (que usava uma porta serial) e funcionava em todas as máquinas em que o testava, mas algumas pessoas estavam recebendo esse erro.

Acontece que todas as máquinas nas quais o erro ocorreu estavam executando o Win7 x64 e NUNCA UMA VEZ foram atualizadas.

A execução de uma atualização do Windows corrigiu todas as máquinas no meu caso específico.

mitchfish36
fonte
5

Tive o mesmo problema ao desenvolver um aplicativo cliente-servidor usando o Microsoft Visual Studio 2012.

Se você usou o Visual Studio para desenvolver o aplicativo, verifique se o novo (ou seja, o computador em que o software não foi desenvolvido) possui o Pacote Redistribuível Microsoft Visual C ++ apropriado. Conforme apropriado, você precisa da versão correta do ano e do bit (por exemplo, x86 para 32 bits e x64 para 64 bits) do Pacote Redistribuível do Visual C ++.

Os pacotes redistribuíveis do Visual C ++ instalam componentes de tempo de execução necessários para executar aplicativos C ++ criados usando o Visual Studio.

Aqui está um link para o Visual C ++ Redistributable for Visual Studio 2015 .

Você pode verificar quais versões estão instaladas no Painel de Controle -> Programas -> Programas e Recursos.

Veja como obtive esse erro e o corrigi:

1) Desenvolvi um aplicativo de 32 bits usando o Visual Studio 2012 no meu computador. Vamos ligar para o meu computador ComputerA.

2) Instalei o .exe e os arquivos relacionados em um computador diferente que chamaremos de ComputerB.

3) No ComputerB, executei o .exe e recebi a mensagem de erro.

4) No ComputerB, observei os Programas e Recursos e não vi o Visual C ++ 2012 Redistributable (x64).

5) No ComputerB, pesquisei no Visual C ++ 2012 Redistributable e selecionei e instalei a versão x64.

6) No ComputerB, executei o .exe no ComputerB e não recebi a mensagem de erro.

user3731622
fonte
3

Na verdade, esse erro indica um formato de imagem inválido. No entanto, por que isso está acontecendo e o que o código de erro geralmente significa? Na verdade, isso pode aparecer quando você está tentando executar um programa criado ou destinado a funcionar com um sistema operacional Windows de 64 bits, mas o computador está executando o sistema operacional 32 bits.

Razões possíveis:

  • Microsoft Visual C ++
  • Precisa reiniciar
  • DirectX
  • .NET Framework
  • Necessidade de reinstalar
  • Precisa executar o aplicativo como administrador

Fonte: http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/

Solve101
fonte
2

Este pode ser um caso em que a depuração do depurador pode ser útil. Essencialmente, se você seguir as instruções aqui, poderá executar dois ide's e um irá depurar no outro. Se você unir seu aplicativo em um, às vezes poderá detectar erros que, de outra forma, perderiam. Vale a tentativa.

Toby Allen
fonte
2
Este é quase certamente um erro relatado pelo carregador e, portanto, ocorre antes do início do processo. Portanto, a depuração não seria uma opção. Obviamente, posso estar errado no meu diagnóstico de que o erro foi gerado pelo carregador.
David Heffernan
2

Eu vi o erro ao tentar executar o executável de depuração do VC ++ em uma máquina que não tinha o Visual C ++ instalado. Construindo uma versão de lançamento e usando isso a corrigiu.

Bill Greer
fonte
2

No meu caso, o erro ocorreu quando eu renomeei uma DLL após compilá-la (usando o Visual Studio 2015), para que ela se encaixe no nome esperado por um executável, que dependia da DLL. Após a renomeação, a lista de símbolos exportados exibida pelo Dependency Walker estava vazia e a mensagem de erro "O aplicativo não pôde iniciar corretamente" foi exibida.

Portanto, ele pode ser corrigido alterando o nome do arquivo de saída nas opções do vinculador do Visual Studio.

nucleon
fonte
2

Você pode ter isso se estiver tentando manifestar seu aplicativo que ele depende do assembly Microsoft.Windows.Common-Controls . Você faz isso quando deseja carregar a versão 6 da biblioteca de controles comuns - para que os estilos visuais sejam aplicados aos controles comuns.

Você provavelmente seguiu a documentação original da Microsoft desde os dias do Windows XP e adicionou o seguinte ao manifesto do seu aplicativo:

<!-- 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>

O Windows XP não é mais o sistema operacional e você não é mais um aplicativo de 32 bits. Nos 17 anos seguintes, a Microsoft atualizou sua documentação ; agora é hora de atualizar seu manifesto:

<!-- 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 tem uma história adorável dos controles comuns:

Ian Boyd
fonte
3
"O Windows XP não é mais o SO" fez o meu dia: D
Victoria
Mas eu fiz essa pergunta em 12 - os aplicativos do Windows ainda tinham manifestos?
Mawg diz que restaura Monica
1
@Mawg Isso pode ou não estar relacionado ao seu problema. Mas com Stackoverflow sendo uma combinação de wiki e reddit para conhecimento; é um bom boato saber o erro exato que você relatou. Dito isto, os aplicativos do Windows tiveram manifestos de montagem que remontam ao Windows 2000; e, começando no Windows XP, você não obteria mais a versão mais recente do comctl32.dll, a menos que o manifesto do seu assembly declarasse uma dependência.
Ian Boyd
1

Acabei de resolver esse problema para o meu projeto pessoal (obrigado ao Dries por isso). Para mim, foi porque o caminho do projeto era muito longo. Depois de salvar o .sln em um caminho mais curto (C: / MyProjects) e compilar a partir daí, ele foi executado sem o erro.

user1539405
fonte
1
@jojodmo: na verdade, "Para mim, foi porque o caminho do projeto era muito longo" parece-me ser uma contribuição válida para a caça bug ...
Christian Severin
1

Acabei de encontrar este problema. Procurei "C ++" em "Aplicativos e recursos" no painel de controle do Windows 10 e notei que algum tipo de atualização havia acabado de executar alguns dias antes e instalei o VC ++ Redistributable 2012-2017. O aplicativo que estava sendo executado na mensagem de erro exigia apenas o VC ++ 2010. Desinstalei todos eles e reinstalei apenas o 2010 x86 / x64, e o erro desapareceu e o aplicativo funcionou conforme o esperado.

Chris Putnam
fonte
1

Isso pode acontecer se, por algum motivo, um recurso x86 for carregado de uma máquina x64. Para evitar isso explicitamente, adicione essa diretiva de pré-processador ao stdafx.h (é claro, no meu exemplo, o recurso problemático é a DLL de controles comuns do 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
Michael Haephrati
fonte
1
Os controles comuns fazem parte do sistema operacional. O sistema operacional sabe de onde carregar a versão correta. Isso não faz nada para resolver o problema do OP. Nem sequer instala uma dependência. Tudo o que faz é compilar um recurso manifesto no aplicativo para usar a versão 6 dos controles comuns. O condicional do pré-processador também não é necessário. Basta definir processorArchitecture='*', e isso é tudo o que existe.
IInspectable