可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I have a client/server app which I have been developing on a single PC. Now it needs two serial ports, so I borrowed a PC from a friend.
When I build my app and try to run or debug it (whether in the Delphi IDE or from Windows File manager), it errors \"The application was unable to start correctly (0xc000007b)\".
Googling doesn\'t bring up much, but seems to indicate that this is nothing Delphi specific and happens with other apps. It seems to be caused by calling into a 32 bit DLL from a 64 bit app or vice versa.
- both PCs are Windows 7, 64 bit
- both have Delphi Xe2 starter edition which can only handle 32 bits
- The app runs fine on my PC, but not on my friend\'s
- Other Delphi apps run just fine on both PCs
Can anyone give me a hint as to how to track this down?
回答1:
To start, I would suggest to test whether there is a problem between your application and its dependencies using dependency walker
回答2:
A load time dependency could not be resolved. The easiest way to debug this is to use Dependency Walker. Use the Profile option to get diagnostics output of the load process. This will identify the point of failure and should guide you to a solution.
The most common cause of this error is trying to load a 64 bit DLL into a 32 bit process, or vice versa.
回答3:
It is a missing dll.
Possibly, your dll that works with com ports have an unresolved dll dependence.
You can use dependency walker and windows debugger. Check all of the mfc library, for example. Also, you can use nrCommlib - it is great components to work with com ports.
回答4:
I tried all the things specified here and found yet another answer. I had to compile my application with 32-bit DLLs. I had built the libraries both in 32-bit and 64-bit but had my PATH
set to 64-bit libraries. After I recompiled my application (with a number of changes in my code as well) I got this dreaded error and struggled for two days. Finally, after trying a number of other things, I changed my PATH
to have the 32-bit DLLs before the 64-bit DLLs (they have the same names). And it worked. I am just adding it here for completeness.
回答5:
It has been mentioned in earlier answers that using dependency walker is the way to go, in my case (my application keeps failing with the error code), dependency walker showed a few dll that are NOT relevant!
Finally figured out that I can run profiling by going to \"profile\" menu and it will run the application and stop at the exact dll that\'s cause the problem! I found out a 32bit dll was picked because of path and fixed it.
回答6:
I recently had an issue where I was developing an application (that used a serial port) and it worked on all the machines I tested it on but a few people were getting this error.
It turns out all the machines that the error happened on were running Win7 x64 and had NEVER ONCE been updated.
Running a Windows update fixed all of the machines in my particular case.
回答7:
I experienced the same problem developing a client-server app using Microsoft Visual Studio 2012.
If you used Visual Studio to develop the app, you must make sure the new (i.e. the computer that the software was not developed on) has the appropriate Microsoft Visual C++ Redistributable Package. By appropriate, you need the right year and bit version (i.e. x86 for 32 bit and x64 for 64 bit) of the Visual C++ Redistributable Package.
The Visual C++ Redistributable Packages install run-time components that are required to run C++ applications built using Visual Studio.
Here is a link to the Visual C++ Redistributable for Visual Studio 2015 .
You can check what versions are installed by going to Control Panel -> Programs -> Programs and Features.
Here\'s how I got this error and fixed it:
1) I developed a 32 bit application using Visual Studio 2012 on my computer.
Let\'s call my computer ComputerA.
2) I installed the .exe and the related files on a different computer we\'ll call ComputerB.
3) On ComputerB, I ran the .exe and got the error message.
4) On ComputerB, I looked at the Programs and Features and didn\'t see Visual C++ 2012 Redistributable (x64).
5) On ComputerB, I googled for Visual C++ 2012 Redistributable and selected and installed the x64 version.
6) On ComputerB, I ran the .exe on ComputerB and did not receive the error message.
回答8:
Actually this error indicates to an invalid image format. However, why this is happening and what the error code usually means? Actually this could be appear when you are trying to run a program that is made for or intended to work with a 64 bit Windows operating system, but your computer is running on 32 bit Operating system.
Possible Reasons:
- Microsoft Visual C++
- Need to restart
- DirectX
- .NET Framework
- Need to Re-Install
- Need to Run the application as an administrator
Source: http://www.solveinweb.com/solved-the-application-was-unable-to-start-correctly-0xc000007b-click-ok-to-close-the-application/
回答9:
This may be a case where debugging the debugger might be useful. Essentially if you follow the instructions here you can run two ide\'s and one will debug into the other. If you un your application in one, you can sometimes catch errors that you otherwise miss. Its worth a try.
回答10:
I have seen the error trying to run VC++ debug executable on a machine which did not have Visual C++ installed. Building a release version and using that fixed it.
回答11:
In my case the error occurred when I renamed a DLL after building it (using Visual Studio 2015), so that it fits the name expected by an executable, which depended on the DLL. After the renaming the list of exported symbols displayed by Dependency Walker was empty, and the said error message \"The application was unable to start correctly\" was displayed.
So it could be fixed by changing the output file name in the Visual Studio linker options.
回答12:
You can have this if you are trying to manifest your application that it has a dependancy on the Microsoft.Windows.Common-Controls assembly. You do this when you want to load Version 6 of the common controls library - so that visual styles are applied to common controls.
You probably followed Microsoft\'s original documentation way back from Windows XP days, and added the following to your application\'s manifest:
<!-- 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 no longer the OS, and you\'re no longer a 32-bit application. In the intervening 17 years Microsoft updated their documentation; now it\'s time for you to update your 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 has a lovely history of the Common Controls:
- The history of the Windows XP common controls (archive)
回答13:
Just solved this problem for my personal project (thanks to Dries for that). For me it was because the project path was too long. After saving the .sln to a shorter path (C:/MyProjects) and compiling from there it ran without the error.
回答14:
Also download and unzip \"Dependencies\" into same folder where you put the wget.exe from
http://gnuwin32.sourceforge.net/packages/wget.htm
You will then have some lib*.dll files as well as wget.exe in the same folder and it should work fine.
(I also answered here https://superuser.com/a/873531/146668 which I originally found.)
回答15:
I just ran into this issue. I searched for \"C++\" under my \"Apps & Features\" in Windows 10 control panel and noticed that some kind of update had just run a few days prior and installed VC++ Redistributable 2012-2017. The app that was running into the error message only required VC++ 2010. I uninstalled all of them and then reinstalled just 2010 x86/x64, and the error went away and the application functioned as expected.
回答16:
That can happen if for some reason a x86 resource is loaded from a x64 machine. To avoid that explicitly, add this preprocessor directive to stdafx.h (of course, in my example the problematic resource is 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