dll missing dependencies on Windows 7 files - c++

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.

Related

Building executable in Visual Studio 2022 with "Release" configuration, built EXE asking for debug DLLs

The EXE I'm building builds fine using Release config (x64). When ran on another computer it asks for both:
ucrtbased.dll
vcruntime140d.dll
From what I can tell, the program shouldn't be asking for these debug (denoted with "d" at the end of their filenames) DLL files.
I am researching this simultaneous to asking this question, but have a bit of a time crunch to figure this out. I'm looking for any common culprits, or things that I could be missing? Not the most versed on this WIN process.
If I source the missing DLLs and add them to the directory with the EXE, I get this error message:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
The EXE works fine on my machine, where I co-developed the program. Does not work when we try to take it to another machine with a release package.
You need to check whether the library files are mixed with 32/64 bits versions.
vcruntime140.dll is Visual C++ Redistributable.
In addition, the methods in this issue are worthy of your reference.

Having problems registering and using a 64-bit C++ written ATL dynamic library

I am having issues registering and using a dynamic library under Windows 7 x64, the 64-bit version of dll compiles but the compiler log outputs:
Error MSB3073: The command "RegSvr32 /S "...\x64\Debug\xxxxx.dll" exited with code 3.
But, when I build 32-bit version of the dll, compiler log outputs the RegSvr32 command was successful.
I already set the Linker >> General >> Register Output to No in both x86 and x64 build configurations.
I tried running 64-bit and 32-bit version of RegSvr32 (without silent mode) with 64-bit dll, but it responds with the following error:
The module "xxxxx.dll" failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found.
I checked it using dependency walker and it reported more than 100 dlls are missing so, I cannot show them here. Some of them are:
API-MS-WIN-CORE-COM-L1-1-1.DLL
API-MS-WIN-CORE-DATETIME-L1-1-1.DLL
API-MS-WIN-CORE-DEBUG-L1-1-1.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL
API-MS-WIN-CORE-FILE-L1-2-1.DLL
...
WLANUTIL.DLL
WLDAP32.DLL
WTSAPI32.DLL
XMLLITE.DLL
Dependency Walker with opened dll:
I am wondering what the reason for only 64-bit version of dll cannot register using RegSvr32.
Any help is greatly appreciated to resolve this issue.
UPDATE 1
Trying to running the application with this dynamic library results in the following error (both 32-bit and 64-bit versions) :
The program can't start because api-ms-win-core-errorhandling-l1-1-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
All redistributable packages currently I have installed:
Is there any visual c++ redistributables I have to install to solve this?
UPDATE 2
I found More information on api-ms-win-core-errorhandling-l1-1-1.dll here and tried linking WindowsApp.lib with this dynamic library, but it even didn't resolve the issue.
UPDATE 3
I ran system file checker and it gave me following output as I thought it should:
Windows Resource Protection did not find any integrity violations.
Go into the project properties of the DLL you're trying to register
Go to Configuration Properties >> Debugging
Under "Command", click on the little down arrow and choose "regsvr32.exe"
Under "Command Arguments" type "$(TargetName)"
Put a breakpoint somewhere in your DLLMain
Now Debug the DLL (Right click on the dll project in solution explorer and choose "Debug")
If you get to your DLL main, you can debug from there until it fails. If you do not, you should take a look at the output window to see any relevant messages. You might need to change your output window filters too. Right Click on the output window and check all categories of messages to be sure it gives you everything and then debug again.
That should at least tell you where you are failing. Look for module load failures and the like
Edited to add - you might try just changing the build step by removing the "/S". That is "Silent" mode and in this case you want to see the messages.
I finally solved the problem by removing mincore.lib from linked .lib files in both x86 and x64 versions of project, which I recently linked to use GetFileVersionInfoSize API function.

Debugging load time error in C++ SDL2 program compiled with VS2015 on Win10

I'm writing a project in C++ with SDL2 on 64-bit Windows 10 using Visual Studio 2015. I recently purchased a new Windows 10 laptop and cloned my project from github. My project compiles correctly, but I get the following error when I run it:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
Based on my research so far, this error is usually caused by loading an incompatible DLL, e.g. a 64-bit version instead of 32-bit. Suggestions I've found so far include:
Checking that I'm using the 32-bit versions of the SDL2 DLLs
Installing/reinstalling the x86 version of the Visual C++ Redistributable for Visual Studio 2015
Using Dependency Walker to troubleshoot which DLL is failing
My project is set to build for Win32, and I've ensured that I'm using the 32-bit versions of all DLLs I'm explicitly linking (libfreetype-6, libpng16-16, SDL2, SDL2_image, SDL2_mixer, and SDL2_ttf). I have confirmed that the x86 VC++ Redistributable is installed on my machine.
Finally, I've attempted to use Dependency Walker to determine what DLL might be causing the problem (although I've read caveats that Dependency Walker has a lot of false positives). These were the results:
Dependency Walker static analysis
Dependency Walker profiling results
After that point, the profiler freezes and never continues. Note that the SDL components and the VC runtime are loading without error.
The program compiles and loads correctly on my two older machines, one running 32-bit Windows 7 and one running 64-bit Windows 10.
Now for the actual question. What other steps can I take to debug this crash? Or does anyone see from the information I've provided what I'm doing wrong?
Related questions:
The application was unable to start correctly (0xc000007b)
Win 7, 64 bit, dll problems
Using SDL_image in Visual studio 2010, with error "application was unable to start correctly 0xc000007b"
Edit:
As rflobao suggested, I was using the 64-bit version of Dependency Walker on a 32-bit exe. Here is the new output of my profiling run:
At this point, as before, Dependency Walker freezes. I'm still totally lost and don't feel like I'm any closer to being able to determine what's causing the problem.
Note that Dependency Walker has 32 and 64 bit version. If your application is 32-bit you should use the 32 bit version. Otherwise the Dependency Walker will see the libs to System32 and not SisWOW64.
You image show 32bit and 64bit libs mixed, where 64 has error.
This is by no means completely reliable, but you can give it a try. It requires dumpbin.exe, which is included with Visual Studio.
First, get a list of dependent DLLs for your program, resolved against your path:
del dlls.txt
for /f %d in ('dumpbin /dependents Questless.exe ^| findstr /ic:".dll"') do #echo %~$PATH:d >> dlls.txt
Then get the bitness of each:
for /f "delims=" %d in (dlls.txt) do #echo %d & dumpbin /headers "%d" | findstr /c:"machine (x"
This will produce output like:
C:\Windows\System32\kernel32.dll
8664 machine (x64)
C:\programs\ed23\bin\hydra.dll
14C machine (x86)
Note that this is incorrectly using the kernel32.dll from System32, rather than the WOW6432 one, so it shows that as x64. That's because it just used the path, when the Windows loader will actually use the WOW6432 mapper, SxS, the application manifest, and only fall back on the path if none of those resolve the dependency. It also doesn't find dependents of dependents (you could script recursing through the dependents, but be sure to filter out duplicates), and of course doesn't know anything about run-time explicit dynamic loads.
Nevertheless, it's a quick way to get a short list to check, and might identify your problem.
I feel profoundly dumb, but I finally figured out the real problem. I'm using the SDL font library SDL2_ttf, and I simply hadn't copied zlib.dll from the SDL2_ttf lib directory into my build directory. I don't understand why the error message was so cryptic; in the past missing DLLs have given me a helpful "foo.dll is missing" error message.
Anyway, thank you all for your help. At least I've learned a useful lesson: always make sure all the required DLLs are present before suspecting a more complex problem.

Caffe Compilation on Windows - Compiles Successfully But 0xc000007b Error [duplicate]

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.

How do I determine which c++ redistributables my program needs to run?

Is it possible that I need to install both a vcredist for vs2012 AND for vs2010?
I just had an error where my app couldn't load a .dll and it suddenly started working after I did an unrelated installation, which prompted me to guess that it must have installed an older vcredist which fixed the issue.
However I'm sure I'm using c++11 features.
Deployment is a job on its own. And I hate it, I hate the way you have to write installations on Windows. …So that feel better now…
You only need one vcredist. The one the linker decided to link your program to. If you have the "Windows SDK's" installed you will find the actual redist in:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\vcredist_x86
If you install all updates including the not important ones, Microsoft will update your redist in that folder!
Maybe you have an executable, which do not want to run, you need the dependency walker. A tool, so usefully that Microsoft had to remove it from the Visual Studio. Download the program and open your exe in it. You do not need to understand what really happen. As long as no Dialog comes up during opening, everything is okay, even if there are exclamation marks in the bottom window. If a Dialog comes up with something like "Could not resolve" than look in the bottom window. Usually there is now in the lower window something like
"msvcr.dll" or "msvcr100.dll" or "msvcr110.dll".
If it includes an "d" before the extension like "msvcr100d.dll" the executable was compiled in debug mode and your journey ends on a system without installed compiler. If not, the name is telling you which vcredist you need:
msvcr100 = VS 2010 redist (32bit) (64bit)
msvcr110 = VS 2012 redist (32/64bit?)
sometimes it is not msvcr but it always starts with "ms". Of course the program will tell you every dll which is missing, not only microsofts and which command in the dll is used. This is sometimes extremely useful.
You have to do that with every dll in the folder of your executable as they can also have unresolveable dependencies.
Back to your first question. Your program can only link to msvcr100 or msvcr110, not to both, that is the reason you only need one vcredist per executable.
As mentioned in a commentary, A third party DLL can be guilty of using a different msvcp version. So yeah, you have to search all DLL's you use and you have to install both vcredist some times.
PS: There are always at least two of them, msvcr and msvcp.
I solved this problem as follows (on Windows 7):
I tried to load the library and it failed showing "The application failed to start because its side by side information is incorrect."
I opened "Computer management" window: Start -> right click on Computer->Manage.
In the "Computer management" window I selected "Event Viewer"->"Windows logs"->"Application".
The log corresponding to the error said that a DLL for a certain version of Microsoft.VC90.CRT was not found. In my case the version was 9.0.30729.6161 and the search for it in Google revealed I needed to install an "unusual" version of redistributables from here.
The dependency walker did not help for me (it only confused me by reporting unnecessary dependencies).
If you want to know which runtimes are needed, you can try using the "Dependencies" tool from lucasg on github (https://github.com/lucasg/Dependencies) which works on modern systems like win10.
You'll just have to look for MsVcR##.dll o VcRuntime###.dll (where # stands for a digit) in the dependency tree..
HTH
PS: The old-and-faithful "dependency walker" we've been using for years seems to be unable to handle the way newer OS handle delayed dependencies, marking them as "missing", while they are not missing, just delay loaded in a way it doesn't know...
If your OS is Vista or later (not XP), use the built-in SxStrace.exe to generate a log of which DLL's are being loaded and what module requires them. It will clearly show you if multiple CRT DLL versions are being loaded, and for what DLL's (3rd party or no).
The VS2012 redistributable is put into, e.g. "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist".
-- David