-1

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?

Lolechi
  • 151
  • 1
  • 3
  • 20
  • CRT issues can be a giant pain, I'll mention a problem I had in the past and how we had to resolve it in case it applies to you. Our application had multiple CRT entries in the manifest due to 3rd party libraries and their dependencies. Windows doesn't like this and it can cause issues, in this case it found the 3rd party CRT version in the Windows dir and would only look for CRT files there after that and ignore the CRT files we patched down in the local dir. We had to externalize the manifest, clean it up to only have our CRT entry (single entry), and check it in to make it permanent. – Scott Jan 11 '16 at 18:18
  • Sorry, character limit. We spent a few days trying to track own the issue and there was little to no documentation about this behavior. It would work on some machines but not others, it all depended on what those machines had patched down to Windows and if they had the current CRT we required (pulled from a Windows header file at build time). Since the DLLs missing are CRT DLLs, maybe you have a similar issue? – Scott Jan 11 '16 at 18:26
  • Thanks a lot Scott, I looked into it and saw that the 3rd party DLL's were calling CRT DLL's that were missing in my windows directory, all I had to do was replace those. – Lolechi Jan 11 '16 at 19:48

1 Answers1

0

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.

Lolechi
  • 151
  • 1
  • 3
  • 20
  • ***This changed the error I got from missing MSVCP140D.dll to MSVCO120D.dll*** This means the original binaries that you downloaded were compiled for Visual Studio 2015 and the new binaries are compiled for Visual Studio 2013. You should not use the Visual Studio 2013 binaries with Visual Studio 2012. This will result in undefined behavior (due to having more than 1 CRT and heap) even though it appears to work. – drescherjm Jan 11 '16 at 19:55
  • Yeah I don't know why it works, but I'm certain I downloaded the [Visual Studio 2012 libraries](http://www.sfml-dev.org/download/sfml/2.3.2/) – Lolechi Jan 12 '16 at 18:48
  • You wanted `Visual C++ 11 (2012)` libraries. If these are dependent on Visual Studio 2013 I would say a bug report needs to be filed on the broken packaging. – drescherjm Jan 12 '16 at 18:55