La aplicación no pudo iniciarse correctamente (0xc000007b)

Tengo una aplicación cliente / servidor que he estado desarrollando en una sola PC. Ahora necesita dos puertos serie, así que pedí prestada una PC a un amigo.

Cuando construyo mi aplicación y trato de ejecutarla o depurarla (ya sea en Delphi IDE o desde el administrador de archivos de Windows), se produce un error “La aplicación no pudo iniciarse correctamente (0xc000007b)”.

Google no aporta mucho, pero parece indicar que esto no es específico de Delphi y ocurre con otras aplicaciones. Parece ser causado por llamar a una DLL de 32 bits desde una aplicación de 64 bits o viceversa.

  • ambas PC son Windows 7, 64 bit
  • ambos tienen la edición de inicio Delphi Xe2 que solo puede manejar 32 bits
  • La aplicación funciona bien en mi PC, pero no en mi amigo
  • Otras aplicaciones Delphi funcionan bien en ambas PC

¿Alguien puede darme una pista sobre cómo rastrear esto?

Para comenzar, sugeriría que compruebe si hay un problema entre su aplicación y sus dependencias mediante el uso de walker de dependencias

Una dependencia del tiempo de carga no se pudo resolver. La manera más fácil de depurar esto es usar Dependency Walker . Use la opción Perfil para obtener la salida de diagnóstico del proceso de carga. Esto identificará el punto de falla y lo guiará a una solución.

La causa más común de este error es intentar cargar un archivo DLL de 64 bits en un proceso de 32 bits, o viceversa.

Es un DLL faltante. Posiblemente, su dll que funciona con puertos de comunicación tiene una dependencia dll no resuelta. Puede usar el cajero de dependencias y el depurador de Windows. Verifique toda la biblioteca mfc, por ejemplo. Además, puede usar nrCommlib; es un gran componente para trabajar con puertos de comunicación.

Probé todas las cosas especificadas aquí y encontré otra respuesta. Tuve que comstackr mi aplicación con archivos DLL de 32 bits. Construí las bibliotecas tanto en 32 bits como en 64 bits, pero mi PATH configurada para bibliotecas de 64 bits. Después de recomstackr mi aplicación (con una serie de cambios en mi código también) obtuve este temido error y luché durante dos días. Finalmente, después de probar varias otras cosas, cambié mi PATH para tener las DLL de 32 bits antes de las DLL de 64 bits (tienen los mismos nombres). Y funcionó. Solo lo estoy agregando aquí para completarlo.

Se ha mencionado en respuestas anteriores que el uso del walker de dependencias es el camino a seguir, en mi caso (mi aplicación sigue fallando con el código de error), el walker de dependencia mostró unos pocos DLL que NO son relevantes.

Finalmente me di cuenta de que puedo ejecutar el perfil yendo al menú “perfil” y se ejecutará la aplicación y se detendrá en el dll exacto que es el causante del problema. Descubrí que se eligió un dll de 32 bits debido a la ruta y lo arreglé.

enter image description here

Recientemente tuve un problema en el que estaba desarrollando una aplicación (que usaba un puerto serie) y funcionó en todas las máquinas en las que lo probé, pero algunas personas estaban recibiendo este error.

Resulta que todas las máquinas en las que ocurrió el error estaban ejecutando Win7 x64 y NUNCA UNA VEZ se habían actualizado.

Al ejecutar una actualización de Windows se corrigieron todas las máquinas en mi caso particular.

En realidad, este error indica un formato de imagen no válido. Sin embargo, ¿por qué ocurre esto y qué significa el código de error? En realidad, esto podría aparecer cuando intente ejecutar un progtwig creado o destinado a funcionar con un sistema operativo Windows de 64 bits, pero su computadora se ejecuta en un sistema operativo de 32 bits.

Posibles razones:

  • Microsoft Visual C ++
  • Necesidad de reiniciar
  • DirectX
  • .NET Framework
  • Necesidad de volver a instalar
  • Necesita ejecutar la aplicación como administrador

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

Experimenté el mismo problema al desarrollar una aplicación cliente-servidor utilizando Microsoft Visual Studio 2012.

Si usó Visual Studio para desarrollar la aplicación, debe asegurarse de que la nueva (es decir, la computadora en la que no se desarrolló el software) tenga el paquete redistribuible de Microsoft Visual C ++ adecuado. De forma apropiada, necesita la versión correcta del año y el bit (es decir, x86 para 32 bits y x64 para 64 bits) del paquete redistribuible de Visual C ++.

Los paquetes redistribuibles de Visual C ++ instalan componentes de tiempo de ejecución que son necesarios para ejecutar aplicaciones C ++ creadas con Visual Studio.

Aquí hay un enlace a Visual C ++ Redistributable para Visual Studio 2015 .

Puede verificar qué versiones están instaladas yendo al Panel de control -> Progtwigs -> Progtwigs y características.

Así es como obtuve este error y lo solucioné:

1) Desarrollé una aplicación de 32 bits usando Visual Studio 2012 en mi computadora. Llamemos a mi computadora ComputerA.

2) Instalé el .exe y los archivos relacionados en una computadora diferente que llamaremos ComputerB.

3) En ComputerB, ejecuté el .exe y obtuve el mensaje de error.

4) En ComputerB, miré los Progtwigs y Características y no vi Visual C ++ 2012 Redistributable (x64).

5) En ComputerB, busqué en Google Visual C ++ 2012 Redistributable y seleccioné e instalé la versión x64.

6) En ComputerB, ejecuté .exe en ComputerB y no recibí el mensaje de error.

Este puede ser un caso donde la depuración del depurador podría ser útil. Básicamente, si sigues las instrucciones aquí , puedes ejecutar dos ide y uno depurará en el otro. Si inserta su aplicación en una, a veces puede detectar errores que de otra manera no detectaría. Vale la pena intentarlo.

He visto el error al intentar ejecutar el ejecutable de depuración de VC ++ en una máquina que no tenía instalado Visual C ++. Construir una versión de lanzamiento y usar eso lo solucionó.

En mi caso, el error ocurrió cuando cambié el nombre de una DLL después de comstackrla (usando Visual Studio 2015), de modo que se ajusta al nombre esperado por un ejecutable, que dependía de la DLL. Después de cambiar el nombre, la lista de símbolos exportados mostrada por Dependency Walker estaba vacía y se mostraba el mensaje de error “La aplicación no se pudo iniciar correctamente”.

Por lo tanto, podría solucionarse cambiando el nombre del archivo de salida en las opciones del vinculador de Visual Studio.

Acabo de resolver este problema para mi proyecto personal (gracias a Dries por eso). Para mí fue porque la ruta del proyecto era demasiado larga. Después de guardar .sln en una ruta más corta (C: / MyProjects) y comstackr desde allí, se ejecutó sin el error.

También descargue y descomprima “Dependencias” en la misma carpeta donde coloca el wget.exe

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

A continuación, tendrá algunos archivos lib * .dll y wget.exe en la misma carpeta y debería funcionar bien.

(También respondí aquí https://superuser.com/a/873531/146668 que encontré originalmente).

Me encontré con este problema. Busqué “C ++” en mis “Aplicaciones y características” en el panel de control de Windows 10 y noté que algún tipo de actualización acababa de ejecutarse unos días antes e instalé VC ++ Redistributable 2012-2017. La aplicación que se estaba ejecutando en el mensaje de error solo requería VC ++ 2010. Desinstalé todos y luego volví a instalar solo 2010 x86 / x64, y el error desapareció y la aplicación funcionó como se esperaba.

Eso puede suceder si, por alguna razón, se carga un recurso x86 desde una máquina x64. Para evitar esto explícitamente, agregue esta directiva de preprocesador a stdafx.h (por supuesto, en mi ejemplo, el recurso problemático es 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 

Puede tener esto si está intentando manifestar que su aplicación depende del ensamblado Microsoft.Windows.Common-Controls . Haga esto cuando desee cargar la Versión 6 de la biblioteca de controles comunes, para que los estilos visuales se apliquen a los controles comunes.

Probablemente haya seguido la documentación original de Microsoft desde los días de Windows XP, y haya agregado lo siguiente al manifiesto de su aplicación:

       

Windows XP ya no es el sistema operativo y ya no es una aplicación de 32 bits. En los 17 años transcurridos, Microsoft actualizó su documentación ; ahora es el momento para que actualice su manifiesto:

       

Raymond Chen tiene una hermosa historia de los controles comunes:

  • El historial de los controles comunes de Windows XP ( archivo )