I am using JNI to interface to a CAN driver I wrote using MSVC++ 2012. Everything compiles and runs fine - but only on my computer. Whenever I try to run on any other computer, I get the JNI "UnsatisfiedLinkError" - can't find dependent libraries. I've implemented JNI before, and typically this issue is resolved by simply installing the Microsoft Visual C++ Redistributable Package before running my program. The Redistributable does not solve my issue, however, installing the entire MSVC++ Express 2012 IDE on the computer in question seems to make everything work just fine. Thus, I assume this means that there is some dependency that gets installed and added to PATH when the IDE is installed but not when the Redistributable is installed. Just for verification, I uninstalled the IDE and my JNI driver failed to load once again. The primary difference between this and my other implementations of JNI is that I use Windows.h since it is required for the CAN API I use in my driver. Any ideas on any libraries installed with the IDE but not the Redistributable and whose prototypes are included with Windows.h? (Note: I am aware that Windows.h includes a number of headers itself but I imagine the other criteria make the issue a bit more specific.)
First guess: You are installing a debug build intead of a release build. Debug builds depend on debug versions of the CRT, which cannnot be redistributed.
Check that you are using the right "Microsoft Visual C++ Redistributable Package". There are 2012, 2012 Update 1 and 2012 Update 2 (as well as many for 2010, 2008, ...).
Assuming your dependencies are load-time DLLs, you can use Depends to find out what's missing. (Note: you'll typically see some delay-load DLLs that are "missing". Ignore thoses; See the FAQ.)
Of course, once you find out the name and path of the missing DLL, you'll have to find out what redist package installs it.
Related
I am trying to build a few different 32-bit C++ applications with Visual Studio 2015 that use CEF. To use CEF, I am currently acquiring the CEF prebuilts from Spotify. The dll wrapper for CEF is built using Visual Studio 2015 with some modifications to its CMake files to force it to build with MD and MDd mode regardless of other settings. This was sufficient to make these C++ applications run on some machines. Any machine on which Visual Studio 2015 is installed on before anything else they can run on, however some machines seem to exist in a state such that the program will produce an error on starting when lacking the MSVC 2015 runtime (as expected), but when adding the MSVC 2015 runtime the program simply crashes; however, it only crashes after CEF is used. These programs work fine when they don't link to libcef.dll and don't include the browser functionality.
Upon investigating, I found that libcef.dll, as built by spotify, links to MSVCP110_WIN.DLL, which is from the Visual C++ 2012 Redistributable package. Naturally, the application I am building links to MSVCP140.DLL, which is from the Visual C++ 2015 Redistributable package. This means that the application ultimately links to two runtimes simultaneously. I do not know if this is an issue, but so far it seems to be my best lead. Installing the Visual C++ 2012 Redistributable does not change the outcome and it continues to crash when CEF is used.
This issue has been witnessed on both Windows 7 and Windows 10 and the application works without CEF on both of those operating systems as well, so the operating system is not likely to be the cause of the failure on these systems specifically.
Has anyone else encountered this issue and does anyone know a workaround? Also, does anybody know if it is okay to mix these two runtimes and what the limitations are? It seems that the installation history of a given machine affects the success of running the application, so any hints into what combination of things leads to this failure would be helpful as well.
You have some options:
Use the lastest version of VS that will allow a selection of Platform Toolset that matches libdef.dll. For example, VS2013 might allow the selection of the 2012 CRT.
Or convince Spotify to rebuild libcef.dll such that it matches your version of CRT
Or convince Spotify to not release libraries that depend on the CRT (yes that's probably a bit of work).
Or make a small app built against the older CRT, this app can then successfully use libcef.dll. Then you get to use any IPC technique so that your main VS2015 app can talk to this wrapper. Running out-of-process is one way to segregate the unruly third party libraries.
EDIT:
This is open source? Well good news, you can fix this yourself, built the CEF against your favorite version of VS.
I recently had a hard disk fail on me. I've re-installed Win XP from scratch, updated to SP3, and run the same vcredist_x86.exe that I have always run before to install Visual C++ components. It seems to install... but none of my executables requiring the essential VC++ DLLs will run - they all give the "application configuration is incorrect" message familiar to many of us.
If I run Dependency Walker, I can see that all executables built using VC++ 2005 are simply failing to pick up the likes of MFC80.dll, MSVCRP80.dll, MSVCP80.dll, etc. When I look in the Windows\WinSxS folder, there appear to be folders containing those files in the correct places. These executables ran fine a couple of weeks ago, so I know their manifests are OK.
What could be causing all these applications to fail to run?
Make sure the correct up-to-date version of the redistributable is used and/or matches the versions used to build the executable(s). Note also that the version number of the vcredist_x86.exe file will not be the same as the version(s) of the files installed in the WinSxS folder. This was really useful for shining light on the version issues.
I develop an unmanaged DLL with Visual C++ which is part of my application. I have always had various problems with linking the VC runtime library. Somehow I managed with VS 2005, but since I moved to VS 2008, the release version of my DLL no longer works on any PC other than the one with my development tools (namely VS 2008).
I link the runtime library as multi-threaded DLL (/MD). I tried the /MT option but that causes a lot of error messages. I allow isolation of the manifest file, and of course installed the VC++ 2008 runtime (although I don't think it should be needed). I also tried the dependency walker to check what is missing. On my development PC (VS 2008 SP1 installed) three files are reported missing:
MSVCR90.DLL, GPSVC.DLL, IESHIMS.DLL
But that does not stop the application (and my DLL) from running.
On all other PCs I tried to install my application on, apart from these three, a fourth file is reported as missing by dep. walker: MSVCP90.DLL.
More importantly, my own DLL is not working as well.
I know this is nothing new and I tried to read everything I could find about SxS problems but I still don't know what to do. Hopefully my description of the 'phenomenon' is good enough for someone more experienced to give me some help.
Thanks in advance.
You may need to distribute and install Microsoft Visual C++ 2008 Redistributable, OR SP1 versionf of it.
I have designed an application that requires no install and can be used by non-administrators. I would rather not lose this functionality but when I use the .exe on other computers than the one I programmed it on I get an error that a missing MSVCP100.dll is preventing the file from executing.
What am I doing wrong here? How do I include the file in my release build?
Thanks!
Configure your project to statically link to the C/C++ runtime instead of linking to the runtime DLL:
Configuration Properties | C/C++ | Code Generation | Runtime Library
Select Multi-threaded (/MT) (or Multi-threaded Debug (/MTd) for your debug build).
As an alternative, you should be able to get xcopy deployment of the C/C++ runtime DLL using the technique documented on http://msdn.microsoft.com/en-us/library/ms235291.aspx under the heading "Deploying Visual C++ library DLLs as private assemblies". I haven't tried that technique, as it's generally simpler to just statically link if you need xcopy installation of a native C++ program.
http://msdn.microsoft.com/en-us/library/ms235299.aspx
Distributing apps that have been compiled with Visual C++ requires distributing the C++ runtime .dlls that your app uses. In your case, I assume you want to just distribute a folder, so follow the directions (appropriately modified for your app) here:
http://msdn.microsoft.com/en-us/library/dd293565.aspx
Or just copy msvcp100.dll into your application's directory alongside the .exe and you'll be good to go.
32-bit msvcp100.dll is in C:\Windows\SysWOW64\
64-bit msvcp100.dll is in C:\Windows\System32\
What am I doing wrong here
What you had was dll hell. You had unintentionally used a dynamic linkage with the previous compiler where it just happened on most target systems there was an appropriate C runtime. Windows often included VC 6 CRT, and with more recent SP even VC7 & 8 CRT.
When you changed to the latest VC compiler most systems will not have the new VC runtime pre installed for you.
As Michael Burr says, you can have your 'no install' back if you link statically.
Or you could include the CRT and manifest in the same folder, still doesn't require install.
Or include the vcredist.exe from VS2010 and have a 1 off install
You need to install Microsoft Visual C++ 2010 Redistributable Package.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.