This question already has answers here:
The application was unable to start correctly (0xc000007b)
(20 answers)
Closed 7 years ago.
I have followed the steps at this URL to compile Caffe for windows. The compilation succeeds but I am unable to run the generated EXE file. Also, when I downloaded the Git branch, there was already a caffe.exe file listed there. When I tried to run the precompiled file, I also got this error: "The application was unable to start correctly (0xc000007b). Click OK to close the application". This is the same error I get on my compiled binary.
Please help me. I am running Windows 7 x64. I suspect the problem could be creeping in somewhere that maybe since I have like 32 bit MinGW or something maybe it is trying to use the 32 bit libraries?
Right now, I have my configuration set to build x64 bit. I feel like one of the problems could be that maybe the CUDA is trying to build 32 or something? I just don't know what's causing this.. Even stranger, why am I not able to run the precompiled caffe.exe that I found when I downloaded this.. (I get the exact same error, that makes me feel like it isn't my compilation process.. there is something else going on).
Thank you for your help
OK - I ran the dependency walker. I identified the following issues:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
LIBGCC_S_DW2-1.DLL
LIBGFORTRAN-3.DLL
are x86 but the rest of them are x64. Where can I get the 64 bit DLLs from?
Also,
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL
Are listed as being not found (the system cannot find the file specified).
This is a dependency error for Windows applications--in others words, you're probably missing a DLL file. Use dependency walker to help find out which DLL files you're missing.
Related
This question already has answers here:
The application was unable to start correctly (0xc000007b)
(20 answers)
Closed 6 years ago.
I am trying to make an application with OpenGL and GStreamer. I have a couple of files linking to GStreamer-libraries, but for now, they are not included to the main source file in any way. The program compiles just fine, but upon running, I get the error message
The application was unable to start correctly (0xc000007b).
I got no more information about the error.
But when excluding the GStreamer-related files from the project, while leaving the include- and library-directories in the property page untouched, the code compiles and runs without problems.
I am building for the Win32 platform and have checked that I link to the correct versions of the GStreamer libraries.
Furhermore, when trying to run a build for x64 (also linking properly, I believe), I get the exact same error, even when the files are excluded from the project.
Could anyone tell what's wrong from this sparse information, or at the very least explain why the application won't run when I add files that are not used?
I may give more information on demand, but right now, I really don't know what is relevant.
As suggested by PaulMcKenzie, it turned out that Windows searched through the directories in PATH and took the first dll's that fit, even though they were built for a 64-bit platform.
The cause of the error when I run with x64 turns out to have been that some other dll's, that I had downloaded from a public GitHub repository, were built for 32-bit software.
I've been losing sleep over this for a few days now:
I'm using SFML to create an application and everything was well until I created a new project a few days ago. After that whenever I tried to compile a solution that uses SFML libraries I would get linker errors and missing DLL files.
I looked around and found a program called dependency walker which looks at which DLL files a program depends on. Apparently my program executable was missing some DLL files that are meant to be inside the windows directory.
I freaked out just a little, before finding out they all had the prefix "CRT" and the suffix of either nothing or "D" which meant that they were Visual C run-time library DLL's.
Even though I'm not missing vital DLL's from my PC, I still need to fix this issue. No there was not major hardware/software changes to my PC prior to the problem (I don't have an antivirus and just trust my guts, I haven't had an issue for 5 years now) and yes I'm sure I'm setting up the SFML directories properly following a tutorial.
I've tried reinstalling and repairing VS and the redistributable VC's for my version of VS (which is 2012 express for win desktop), tried clean booting, the windows self file check (sfc /scannow) and also tried manually placing DLL's into my directory that the dependency walker said I was missing.
Has anyone else encountered this before? How did you solve it?
*Interesting note: I have access to an admin account on my school network and installed VS on a computer there to see if the problem would re-occur. Since the windows directories on those machines are never modified VS executed fine. Could it be that I need to get a clean installation of windows?
I'm not sure if OP is allowed to answer on his own thread (or if there is a time limit), but here goes:
I solved my issue after looking at it with a cool head. I re-checked the version of my SFML libraries and wasn't sure if they were 64 or 32 bit, so I re-downloaded the 32-bit version (because my debug compiler is set to run on 32-bit) that was compatible with my version of VS. This changed the error I got from missing MSVCP140D.dll to MSVCO120D.dll (the numbers correspond according to the architecture).
I Googled/asked around for a while more to figure out that I needed a file named MSVCR120D.dll, which was found in system32 but not in SysWoW64. After placing respective architecture DLL files (64 bit for system32, 32 bit for SysWow64) it finally worked!
Even though dependency walker still says the executable is missing 6-7 other DLL files, the project still compiles and runs fine.
I hope this wasn't a solution that only applied to me, I've seen many others with the same problem.
I'm using Visual Studio 2015, and trying to compile a C++ code in Release mode, x86. My operating system is Windows 10, 64-bit OS and x64-based processor.
After it builds, if I run the .exe file from my laptop, it works perfectly fine. However, if I transfer everything in the Release folder to another computer (Windows 8) - no Visual Studio - along with two DLL files (pthreadVC2.dll and ucrtbased.dll), it gives me error 0xc000007b: the application was unable to start.
I've tried statically linking the libraries, but that didn't help. If I run the Dependency Walker, it says that the file - on my computer - has errors, and gives a log of what's wrong, which I cannot understand:
Error: At least one module has an unresolved import due to a missing
export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
I looked around on this website, and apparently it means that 64-bit DLLs are being loaded and I should change that from Path. How do I do that? And why doesn't it work on the other computer, which has the same processor? I installed the Visual C++ Redistributable for Visual Studio 2015, but that did nothing.
Another question: The code uses many external headers. Do I have to export them to the other machine as well? Aren't they compiled as a LIB File?
I'm sorry if I sound clueless, but I rarely write applications using Visual Studio. Thanks for your help!
That error code is an NTSTATUS code, specifically STATUS_INVALID_IMAGE_FORMAT. That usually means that the loader is finding 64 bit modules rather than 32 bit modules. Exactly which modules are the wrong bitness is hard for us to tell. Running the startup under Dependency Walker's profile mode would reveal all.
You do really need to get a clear handle on what dependencies your program has. You have specific dependencies related to your program that go beyond the normal MSVC runtime dependency. Only you can know what your dependencies are. A tool like Dependency Walker can help you understand them, but make sure your understanding is solid. Try not to use trial and error to resolve this.
Is there a way to tell the full path of every DLL used while compiling?
I am trying to make a DLL with easy-to-Marshal functions to communicate between a C# application and a filesystem Minifilter (currently using the Minispy sample to check if everything is running smoothly).
It was successfully compiling and running when using "Win32" as my target platform in Visual Studio 2013, but when printing out pointers with printf("%p",...); their length was only 8 characters where they should have been 16 (my computer is 64 bits) which threw off future pointer juggling.
My active solution platform has always been x64 for the other projects. Unfortunately, changing the platform in the Configuration Manager to x64 for the DLL generates the following error during compilation:
Error 1 error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
I checked online and this seems to be a configuration problem of some part of the solution, but all my projects should be compiling in x64. Cleaning and rebuilding to remove old files had no effect either.
I have used dumpbin.exe to check the Machine types of the DLLs I think my library is linking to and everything seems in order. I got these by checking the linker command line options in my project's Properties, but their names don't show where they are read from ( ex: kernel32.lib; user32.lib; gdi32.lib; fltLib.lib ... ). Since I'm still having this problem, I think it might be linking to the wrong (32bit) versions of the same DLLs.
Is there a way to tell the full path of every DLL used while compiling? Or better yet, is there a way to tell which DLL specifically is causing the LINK1112 error?
I have used the /VERBOSE:LIB command and removed the /NOLOGO option but the output is underwhelming, stopping right after the command to be executed with no other information.
I should have answered this when I solved it a couple months ago but I forgot I posted it here. But I'll try to recall what I did.
In the end, if I remember correctly, I'm pretty sure that what saved me was using Dependency Walker on the successfully compiled (x86) library. I used it before, but I was running it in the wrong mode (x64 or x86) and using the correct one revealed the missing modules for the x64 architecture.
I have built a C++ dll to use from dot net. When I run the progran I get an error, dll not found.
The dll is there - but I checked it with dependency walker - and got for the following:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
Error opening file. The system cannot find the file specified.
I did a search - apparently these are Win 7 files an d I have Windows 7 - but didn't find them.
What can I do ?
I am using VS2010, Windows 7
Dependency Walker (from here : http://www.dependencywalker.com/ ) has grown out of date. While it runs on win7/win8 it fails to detect normal DLLs from them. If you open up the 'about' tab of the latest version 2.2.6000, you'll see it was build on Oct 29th, 2006. yikes. Surprised it works at all.
You can get the process monitor tool at several locations. I snagged mine from here : https://technet.microsoft.com/en-us/sysinternals/bb896645
Once you've got it, you can add a filter for 'program name is ' whatever and then run your program. You'll see stuff that loads and fails to load and such. The result isn't quite as concise as you'd like, but when something fails, it'll be listed.