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.
Related
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.
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.
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.
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.