I'm trying to use Visual Studio to develop and debug a web application that uses the SharePoint 2007 API. I have been doing this fine on a 32-bit server up until now. Today I've moved over to a 64-bit development server and when I try to run the project out of VS, I get:
Could not load file or assembly 'Microsoft.SharePoint.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I have referenced Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll from the GAC on this machine. That automatically copies in Microsoft.SharePoint.Search.dll from somewhere when I run it (even though copy local is false on the references). My project Platform Target is "Any CPU". I get the same error with x86. If I change to x64, I instead get Could not load file or assembly 'MyProjects.dll'...incorrect format.. I've also tried deleting Microsoft.SharePoint.Search.dll from the bin after it starts up but then I get a SharePoint error saying that the site at my URL can't be found, which I believe is also a bitness issue. I'm not quite sure what the issue is but want to be able to run this application out of Visual Studio. How can I get it working?
You need the x64 (or anyCPU) version of the Sharepoint dlls to make it work
Both Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll in the server's GAC are built for Any CPU. When I build my web app in Visual Studio, it automatically copies Microsoft.SharePoint.Search.dll into my bin, presumably because it's referenced by Microsoft.SharePoint.dll. SharePoint.Search.dll is not in the GAC. It is copied from the 64-bit 12\ISAPI directory and is built with an "Amd64" target architecture (despite my server having an Intel Xeon CPU). So I believe the problem is VS runs the web app in a 32-bit process which causes the error when it tries to load the 64-bit SharePoint.Search.dll.
My first idea was to explicitly reference the 32-bit SharePoint.Search.dll in my project. That makes the error go away but it is replaced with an error saying the website at [my SharePoint site URL] cannot be found. I believe this is because now I'm trying to access the SharePoint site, which runs in a 64-bit app pool, from a 32-bit process. So what I really need is for Visual Studio to run my web app using a 64-bit hosting process. This looks like an option available for VS 2012, but not 2010. The alternatives I've found for VS 2010 are:
On the project properties Web tab, configure it to run using the Local IIS instance. This will add a virtual directory to the default site, which is running in 64-bit mode by default. This isn't a good solution for me because I want to allow multiple developers to work on the same project on the same server simultaneously. Using the same site would cause conflicts. If there were a way to configure the site name conditionally on the user, this would be ok. I opted to try #2 first.
Replace the VS Development Server with an x64 build of the CassiniDev project. This project has the capability of plugging in to VS in place of the default WebDev.WebServer.EXE. So you just need to download the source code, and build with an x64 target platform. Then you can replace the VS default development server exe, as is documented w/ the CassiniDev project, and it will run an x64 development web server which solves my problem!
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?
Normally we get the 0xC000007B error-code (which means STATUS_INVALID_IMAGE_FORMAT), if:
If a 32-bit app tried to load a 64-bit DLL.
Or if a 64-bit app tried to load a 32-bit DLL.
Or if a 64-bit app tried to run on a 32-bit Windows.
To really know, I would suggest to test whether there is a problem between your application and its dependencies using dependency walker
Note that all you need to do is open your App using said tool, and issues appear as red log-entries at buttom of screen.
(At least, at time of writting, namely 2022)
Also, make sure you run the correct version of Dependency Walker, for example, the x86 version will display incorrect results when openning x64 binaries.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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)
The main problem, of course, is that a DLL file is missing, or, even more likely, corrupt. If this is the case, then I have some pretty good ideas (especially if you've downloaded and installed a DLL manually!)...
TLDR: Delete every manually copy/pasted DLL you've done, uninstall old redistributable installs, and reinstall new redistributables for both 32-bit and 64-bit installs.
What To Do
This solution of copying/pasting missing DLL's into system32, etc., used to work since I can remember in the 1990's, but it doesn't seem to work anymore (2020). So if you run into this problem recently, I suggest:
Within windows\system32 and windows\SysWOW64, delete all files that match ms*.dll, that the operating system will allow you delete as admin.
Uninstall all Visual C++ Redistributables that you have with Windows. This prevents the "You already have this!" dialogue showing up upon reinstall, as detailed in the next step when we re-install.
Reinstall the 2015-2019 Visual C++ Redistributable from a regularly available download site. If this does not work, download and install the others, but personally, the 2015-2019 covered everything for me. Regardless of your machine, install both x32 and x64 packages! (All Download Links: Collected VC++ Download Links; MSVCR120.dll Fix; MFC140U.dll Fix.)
How You Know It's Working
There's a lot of variation in coders experiencing this, so, the idea that there's one single, possible solution is often discarded, but let's be positive!
If deleting the matching ms*.dll files worked, then you will no longer get an error about error code 0xc000007b. Instead, you'll get a message about a missing .dll. This tells you that you're hitting the right code path!
If installing the redistributable works, then certain popular, DLL files should appear in the above-mentioned system32 and SysWO64 folders. For instance: MSVCR120.dll, MSVCR140.dll, MSVCR100.dll, MSVCP100.dll, MSVCP120.dll, MSVCP140.dll, and friends.
Last, Possible Best Chances
Sometimes things don't work according to plan (as we all in the Windows world know). You can also try the following!
Open the "Turn Windows Features on or off" tab in Windows (supported in Windows 8-10). Uncheck the .NET Framework installations. You'll see a small installation go by.
Restart the system. Go to the above feature again, recheck .NET Framework, and click "okay". If this works, you'll see a "installing and updating .NET framework" message that takes maybe a minute or so to go by. Once this is done, I recommend a reboot again.
Good luck!
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.
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.)
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.
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
It is possible that you have multiple versions of the dll(s) on your system. You can search your system to find out. The issue may be solved by simply changing the order of the directories in your path. This was my issue. (Cannot run Qt Creator GUI outside of Qt. "The application was unable to start correctly (0xc000007b)" error)
I ran into this issue when fetching code from my repository and compiling on a new machine. Copying over the entire repository and then compiling resulted in an executable which worked. Turns out a 32bit DLL accidentally wasn't checked in. As the people above state, use "Dependency Walker" to figure out where it goes wrong.
To make it more clear what to look for see the below screenshot, with in the background the exe trying to load the wrong DLL (notice the '64') resulting in "the application was unable to start correctly 0xc00007b" and in the foreground the exe which was simply copied over (which included the correct DLL).
I came here when I was searching for: "golang Windows (0xc00007b)"
I have an app written in Golang, which uses iconv. It worked on my machine, but not in someone else's machine.
The first error was the missing DLL: libiconv-2.dll, so I guess they downloaded it on the internet but it was the 32 bit and not 64 bit version, so the 0xc00007b error appeared.
I searched the DLL on my system but I did not have success until I searched on MinGW 64 path which in my case is: C:\msys64\mingw64\bin
The solution was to distribute the DLL with the .exe, which was in the MinGW folder.
I have a problem running my application on other machines.
I am developing with Visual Studio 2008 in a Win7 x64 machine.
The solution contains several C# projects (the main application is written in C#, all others are library projects) and two c++/CLI libraries. The C++ libraries are Win32 and all C# projects are set to x86 target processor. No third party libraries used. Framework used is v3.5.
The application builds and runs fine on my machine.
I copied the whole "bin\release" folder to a Win7 x86 machine and it ran fine, too.
But when I tried on a XP x86 system, it did not start. No error message, not even showing up shortly in the task manager. The XP system has all updates installed, all available .NET frameworks installed and all Visual Studio Runtimes installed.
I checked with DependencyWalker and the only missing dlls are "IEShim.dll" and "wer.dll" which are only for Vista or higher.
I tried another of my applications that's not using C++ libraries and they work fine. So I guess I am doing something wrong deploying the C++ dlls.
Registering the C++ dlls with "regsvr32" failed with a "DllEntryPoint" not found message. Registering with "regasm" was successful, but had no effect.
What is it that I am missing?
Well, seems like I was a bit hasty stating "no third party components".
Actually it was the SQL Server Compact who was missing its runtime.
I have an application that I compile as x86 code but as a separate version, as x64 code as well. The application basically has two parts, a c# managed exe and a c++ unmanaged dll. I have problems with the latter. On my development PC (Windows 7 64-bit, Visual Studio 2008) I create a setup with a deployment project and this setup installs the application in Program Files... as it should and the application runs. I also have a test PC (Windows 7 64-bit with practically nothing else). There the application still installs into Program Files... but it does not run, I get the BadImageFormatException when a function (any function) of the unmanaged dll is called. The problem is that my own project that produces the dll also makes use of quite a few freely available libraries (e.g. glew32, openal, freeimage, etc.) I took as much care is possible to make sure that I use the x64 versions of these libraries, but something still must be wrong. For some reason one of the libraries used by my dll is not available as x64 code on the test PC but it is on the development PC. At least that is the only explanation I have at the moment why my setup works on the development PC but not on the test PC.
My question is: how can I find out where the problem is. The error message I receive does not tell any helpful detail. I tried to analyze my dll with depends but it looks OK. It lists a lot of dependent libraries as X86 (these are probably system files) but all those that I use on purpose are listed as x64.
Is there any way to test why the Windows on my test PC tries to run the DLL as x86 code even though it should be x64?
Thanks.
I noticed something very strange: My application is being deployed in the Program Files folder as it should be for a x64 application but it fails to run. However if I copy all the files in the folder it is installed to to another folder (inside the Documents folder) the application runs perfectly.
Run Fusion Log Viewer in the machine where you want to diagnose the issue. Look carefully at the logs and you'll see exactly which dlls are being loaded, and where from.
You have build your .NET executable (or DLL) with Any CPU configuration, and you have given x64/Win32 native DLL for Win32/x64 (i.e. wrong config).
On x64 systems, your .NET binary will try to load the native DLL as if native DLL is x64.
And on 32-bit systems, it will try to load 32-bit native DLL.
I found the answer. The problem was not the 64-bit dll at all. One of the libraries I did not make but I link to (I do not know which yet, there) seems to try to write a file to the application folder. Of course, this is not allowed inside the Program Files folder unless you run the application as an administrator. Sorry for asking help for the wrong question.
We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies