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.
Related
I've been desperatly trying to get my School Project to run on those crappy school pcs, but i am not able to resolve the issue of missing Dll's.
My Project is set to "\MT" as Runtime Library and I've set MFC to static linking.
At first the MSVCP140.dll was missing, so i copied it in the folder with the .exe, but I'm not able to do that with before mentioned DLL.
Unfortunately, I can't install any runtimes or redists on the school pcs. (They run windows 7 with the latest updates)
EDIT:
I've did exactly what is recommended in all stackexachange answers, and it still doesn't work, so no, this is no duplicate.
Any help is appreciated! (it's my first stackoverflow question ^^)
I am new to C++ an I am making an application in Visual Studio 2010 using an SDK which has 3rd party dll's. I want to be able to run this program on other computers so I looked at this question to make sure I include them right (specifically Laserallan's answer). I then build the program in release mode and it compiles fine. The problem is, when I try to run the .exe in the sample release folder the program doesn't run. Not sure if these detals are relevent but my project uses MFC in a static library and Multi-Threaded(MT) runtime library. Incremental linking is not enabled.
My suspicion is that it has something to do with the dll's being in the same place as the .exe because if I move one of them out of the sample release folder, I get this error:
I also noticed this in the SDK's API. I'm not sure if it is relevent or not:
"The eBUS SDK is provided as DLLs. Static libraries are not offered at this point. Even though DLLs are provided, it is still necessary to link your application against link libraries of the DLLs."
The .exe was working fine before, It only started mucking up when I tried to put the dll's in the same place as the exe, tried to make it work on other computers and when I reinstalled the SDK. Does anyone have any ideas on what it could be? It has been doing my head in for the past 2 days now. Any help would be greatly appreciated.
I solved it, turns out the new computer had 2 versions of PvBuffer, one had the GetAcquiredSize method and the other didn't. The program was executing the version that didn't and was trying to find a method that wasn't there. Thanks for your help!
here is some information to understand my situation better.
OS: windows 8.1
IDE: Visual Studio 2008 Pro
Language: C++
i have just my Firefox reinstalled and after this(maybe it was not the reason),
my visual studio Project compiled only with 9.0.30729.6161 VC++ Runtime DLL.
Until yesterday it always compiled with 9.0.30729.8387 VC++ Runtime DLL.
Because of this (or maybe other reason), now i cannot start my Project.exe.
Nothing is changed in source-code. Project-Property and all other things are also unchanged.
I just get the error number 0xc000007b suddenly.
How can i fix this?
It was because of an 32bit DLL, which should not be loaded for my 64bit Project.exe.
I have found this with Process Monitor.
I don't know why, but anyway is the "path" is changed and the 32bit DLL(which has the same name with 64bit DLL) is loaded..
If you have the same Problem, check whether there is a problem between your application and its dependencies using dependency walker.
Entered the answer in another place, but figure it could be helpful for folks who badly need some help:
It has been mentioned in other 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.
-Turn off your antivirus software before starting the installation.
-Accept any additional software offered during installation process, since it may be crucial for running your application properly. You can skip things such as search bars, antivirus scanners, registry cleaners and the other software which isn’t directly related to the application.
-Install an application to the system partition (C:). Although this shouldn’t matter, it’s been proven that some apps may return an error if installed on a logical partition.
There is more than one way to solve it. This link might also be helpful.
http://finally-found-the-solution.blogspot.com/2015/02/how-to-fix-0xc000007b-application-error.html
Okay so I have read a few responses about this topic and can't seem to find someone having the same issue.
Why installing vcredist_x86.exe doesn't fix SideBySide error when I develop an EXE on one machine and run it on another one?
http://www.codeproject.com/Articles/43681/Side-by-Side-Configuration-Incorrect
background: I work on Fortran code that use a few c++ libs that I don't have access to the code of. These were apparently built using VS2008, and this error has only started to occur since my machine had to be rebooted and I asked IT not to install VS2008 in addition to VS2012. I know that installing VS2008 will fix the problem, but that is not a good soultion.
The error is: unable to start program 'C:\blah\blah\blah.exe'. This application has failed to start because the application configuration is incorrect. Review the manifest file for possible errors. Reinstalling the application may fix this problem. For more details, please see the application event log. The application event log tells me the same things listed in the first link posted.
Originally I was getting the problem so I looked up these articles and I went and installed the correct version of the VC C++ redist package (it is version 9.0.21022.8 for x86 source:the manifest file for the project). I originally installed the 64 bit, quickly determined I needed the 32 bit version and then installed that one.
I have the folders and files within for
C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.21022.8_none_b59bae9d65014b98
C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.21022.8_none_b59bae9d65014b98
C:\Windows\winsxs\x86_microsoft.vc90.atl_1fc8b3b9a1e18e3b_9.0.21022.8_none_b59bae9d65014b98
The related manifest files also seem to be there.
The program still doesn't run even though the files are there. What am I missing?
I am well aware of the fact that a multitude of similar problems already appeared on this board, however none of the solutions helped me.
I am trying to get Eclipse CDT running with MinGW toolchain on Windows 7 Service Pack 1. I already did that on Windows XP and thought that the same procedure will make it run smoothly on Windows 7, but it seems I was mistaken ;)
After installing MinGW from the automatic installer (just in case I installed a few things more than what I needed) and adding the C:/MinGW/bin to my PATH environment variable, I tried to compile a simple Hello, World! program. Eclipse did not give me any errors, but it didn't want to give any output in the Console window. Alarmed, I tried to run the executable file outside of Eclipse and got the error that
"Program can't start because libstdc++-6.dll is missing".
Strangely enough, this dll is in the C:/minGW/bin directory, so the PATH variable should 'find' it - but it does not. Copying the dll to the directory with the executable file helped, but it is obviously a short-term solution and I would prefer to have a more "normal" one.
The thing that makes my problem different, I think, from the others I've noticed on this board is the fact that, for one, Eclipse does not find any errors with my PATH variable (which it usually does, if the MinGW was not included in the Path variable or something), and besides the required dlls are where they should be, but it seems my Windows can't find them.
The "real" solution is indeed to copy the DLL locally. You have to ship that dll when shipping your EXE.