I was trying to run the GStreamer hello-world demo, after successful compilation, but the application doesn't run as expected. An error message pops up and the application quits. The message says the msvcrt.dll in my computer doesn't have function rand_s. The Dependency Walker is shown below.
I'm pretty sure it is libglib-2.0-0.dll that came with GStreamer caused the trouble. So, where can I download the msvcrt.dll that offers function rand_s? Thanks in advance.
I solved my problems with InkScape by nulling out _s in rand_s in .dll import table of glib*.dll.
Technically, rand_s are available in msvcr*.dll if you install appropriate redistributable. Having installed sequentially MSVS 2005, 2008, 2010, 2012, 2013 redistributables, I can see rand_s in msvcr100.dll (2010), msvcr110.dll (2012), msvcr120.dll (2013), but not in msvcrt.dll. msvcr90.dll and msvcr80.dll are missing after installation, I don't know why. It seems that some versions of Windows contain rand_s in msvsrt.dll and FLOSS developers expected it to be true everywhere, but in fact one must link against msvcr*.dll to really get these features.
You can also try to install MSVS redistributable 2010 or higher and copy msvcr*.dll from system32 to gstreamer using msvcrt.dll file name. I haven't tried it.
Related
I have an application written in QT. Previously I was using Visual Studio 2012 and Qt 5.3.1 after which I recently upgraded to Visual Studio 2015 and QT 5.6. I would previously provide msvcp110 and msvcr110 as part of the installation (I know that wasn't the best practice but I got away with it).
After upgrading I had to now install VC++ 2015 because of the changes with VS 2015. I don't mind the changes and currently providing redist packages to be installed.
The problem I am facing is that, I do have to provide VC++ 2012 as well and recently running the software in Windows 8.1 Pro, I was asked to provide VC++ 2013 as well (never used VS2013 for compiling). The diagnosis was from dependency walker and google. Not only that, I had to install x86 and x64 of all the 3 versions of VC++ for the software to start (wouldn't even start to be honest).
Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?
How do I get rid of the other redist packages? Is it some code I have written which is dependent? If yes any chance I can find out?
Why do I need to provide both the 32 and 64 bit versions when I compile strictly in the 64 bit compiler?
Any way to diagnose without dependency walker? Can there be some logging when the application refuses to start at all?
Apologies for the long post, but any light here can restore my sanity.
Thanks in advance.
You are using DLLs linked to the older runtime. You can use Dependency Walker on your development machine to track this down, shouldn't need to install any tools on a customer machine for that.
Migrate all the files shipped with your application to a version built against VC++ 2015.
You didn't provide any details that could reveal the reason.
For DLLs other than the language runtime library, you can use delay-loading and then be able to trap failure to load the library. You can't effectively delay-load msvcr*.dll though. One option would be to create a very thin EXE that uses no support DLL at all (either use pure Win32 API, or statically link the runtime) which does nothing except install an error handler and then load your main program which is now in the form of a DLL. Loading your main program DLL should be done either using delay-load linking or LoadLibrary()+GetProcAddress() -- either one will allow catching errors. This main program DLL would be free to import the runtime DLLs as usual.
I have a legacy Visual C++ library. I compile it using Visual Studio 2015 and use it in another applications. Everything is OK on my development environment, but on my production server I'm getting "couldn’t load ManagerApi.dll or one of its dependencies" exception. It works fine if I install Visual Studio 2015 with Visual C++ components on server. But I don't want to do that.
Here is my list of installations on server machine:
What do I have to install to use the library without exceptions?
Here is the dependency walker screenshot for the dll:
Thanks in advance,
Just a guess, but looking at your dependency walker screen, you're missing MSVCP140D.DLL which is a debug version of the c++ runtimes which don't get installed by the VS2015 redist package. If you recompile your DLL as release rather than debug it should be ok. Alternatively, if you use an installation packager such as Installshield that checks dependencies, it should sort the problem for you.
I am running Microsoft Visual Studio Express 2012 for Windows Desktop on a 64 bit machine with windows 8.
I create a completely new Win32 Console Application (in C++) and accept the default options. I then build and run the solution in both debug and release modes and it works all find and dandy. Next I configure the include and library directories for the dynamic SFML library. I link to the debug and release .lib files and put the debug and release .dll files in the proper directories. I then add some simple code which uses the library, build and run the application in debug mode and I get this error: "The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the program to fix this problem." If I build and run the application in release mode it works with no errors. (And yes I have the redistributables installed 32 and 64 bit.) Now from what I understand and according to this thread that .dll file is for debugging only and is not included in the redistributable package (which would explain why it doesn't work in debug mode). The answer says that developers have it installed with visual studio by default. This is obviously not the case as evidence from the error and I've reinstalled visual studio and restarted my computer twice now.
In conclusion, how do I simply compile my solution in debug mode without getting this error?
I'm afraid someone will mark this as a duplicate so here we go:
LINK - "...you appear to be linking to the debug version of the runtime, it is not normal to distribute apps linked against the debug version of the runtime."
Doesn't pertain to me because I'm not distributing this app, just trying to run it in debug mode.
LINK - "I compiled my program using Microsoft visual c++ 2010 Express Edition and tried to run it on another machine that did not have the same compiler."
This person get's the error when he runs what hes compiled on a different computer, not when actually compiling the application.
LINK - "If you get this error for your release build..."
I dont.
LINK - "You can compile your project in "Release"..."
My project is not ready to be released therefore I should compile my project in debug mode.
MSVCR100D.dll is the dll for Visual Studio 10, so somewhere something is depending on it (the SFML dlls?). Whatever you compile (in debug mode) with Visual Studio 2012 will require MSVCR110D.dll, which you should have available on your machine as part of the installation.
I suggest you build SFML yourself on your own version of Visual Studio, it's pretty easy. In fact, the binaries available on the site as part of the SFML 2.0 RC are rather old and you'll do yourself a huge favor by building from the latest sources, as a lot of fixes and improvement were applied in the meantime.
(Also, definitely use 2.0 instead of 1.6. The site is rather misleading, but on the SFML forums virtually everyone will recommend you use the last version)
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
MSVCR100D is part of the 2010 Visual Studio package - indicating that some components of your system are compiled with the older version of Visual Studio, so you will need to install the Visual Studio 2010 version - you can probably still develop with the 2012 version, just as long as [parts of] the 2010 is on the machine.
Or you need to recompile some components that your application depends on to use the 2012 (msvcr110d) libraries - if you have all the source code, that would be my preferrred method.
I've got a problem with several VC++ DLLs, which I should include into my .NET/C# project. One VC++ DLL is a C++/CLI DLL, which I use as public interface from my .NET project. The other DLLs are written in native C++. I have no access to the source of the VC++ DLLs, I just have to use them.
I've made a .NET test project and referenced the C++/CLI DLL. No problem, compiler is lucky, great. There's just one problem: when I start the EXE of the .NET program, I get errors about the C++ DLLs because of missing VC++ core DLLs.
sxstrace shows the following (shortened):
INFO: Reference: Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Reference: Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Resolving reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
...
ERROR: Cannot resolve reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195".
Now I'm no fool and tried several things. I've read much about WinSxS to get a deeper understanding about what's going on.
Now I'm at the point, where it's getting weired for me. The system where I want to execute the program has the VC++ Redistributable package in the current version 8.0.50727.762 (SP1) installed. I know that there's a policy file for Microsoft.VC80.CRT in winsxs that redirects all versions of this assembly to the current version 8.0.50727.762 (that's the solution for the problem at http://blogs.msdn.com/b/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx).
But as the error above says, this policy file doesn't seem to work or isn't taken into account. The system just wants to find the 8.0.50727.6195 version of the assembly.
Now that's the first question: what's the problem here? After I got this figured out, I could solve the initial problem...
Ok, now it works - thanks for your help.
I figured out two problems that had to be solved:
1) I had to install the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update", which deploys version 8.0.50727.6195 of the VC++ assemblies. This update was hard to find at the Microsoft servers, so here's the link: http://www.microsoft.com/download/en/details.aspx?id=26347
Normally you only find the 8.0.50727.762 version ("Visual C++ 2005 Service Pack 1 Redistributable Package), which is outdated. Since the C++ DLLs were compiled against 6195, installing the update solved the first problem.
2) While the C++/CLI DLL was compiled in Release mode, the native C++ DLLs below had been delivered in Debug mode. Now the Microsoft license agreement prohibits deploying the VC++ Debug DLLs and the VC++ Redist Packages don't include the VC++ Debug DLLs.
http://msdn.microsoft.com/en-us/library/aa985618.aspx says:
Debug versions of an application are not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable.
Solution: the developers of the native C++ DLLs gave me a release version and everything works fine...
I'm using Visual C++ 2008 Express Edition to create a resource only DLL.
The problem I'm facing is that running the application that makes use of the DLL
on another computer besides mine results in LoadLibrary() function failing with error code 14001.
Searching throught the internet it seems to be a dependecy problem of the computer
running the application lacking libraries of the Microsoft Visual C++ 2008 Redistributable Package.
My first step was to install the latest Microsoft Visual C++ 2008 Redistributable Package but that didn't solved the problem.
Also I changed my project setting so the DLL compiles with static CRT linking assuming that
this way I will get rid the dependencies.
These options seem to be the workarounds for other people having the same issue.
Any idea in which direction to look is highly appreciated.
Thanks
==================================================================================
Thanks for your answers.
Both Dependency Walker and the event viewer indicated a side-by-side configuration
problem as I was missing a debug version library of the VC++ Redistributable Package.
I was careless and have compiled my DLL in debug mode, recompiling in release mode solved the problem.
Try to isolate missing library by Dependency Walker:
http://www.dependencywalker.com/
Just run your application on the second computer with this tool, it should tell you what library is missing. Be sure you are installing the right version of Visual C++ 2008 Redistributable Package; there are two of them, for VS 2008 with SP1 and without any SP...
Look in the eventviewer. Good chance there will be an error there from Windows SideBySide explaining which assembly is missing.
Likely it would be a VC CRT runtime which you will have to bundle with your dll.
(the VC redistributable is available here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=29)
I had the same issues but with Visual Studio 2013; a debugging set of DLL's which required a manifest. In my case Microsoft.DTfW.DHL.manifest and dbghelp.dll had to be added to the path (I used the exe directory).