msvcr100.dll (Visual C++ Runtime) seems to have become part of the Java runtime on Windows after Java 1.6, and I'm thinking if Java ran on Windows all these years without it, why is it now I must put up with it, or can I configure it out of the picture.
I have a program that has a mysterious very occasional crash of msvcr100.dll. I noticed that I can rename msvcr100.dll after my Java program has started (so the dll is not loaded), but when I call Runtime.exec to spawn a Windows program, the missing DLL is "noticed" again, and gives the message "The specified module could not be found. Java Runtime Environment not valid."
In earlier versions of Java, this dll was not required, so my question: is there a way to tell the JVM that we don't want to use msvcr100.dll?
No, it is not possible. Oracle's Java runtime is written in C, and built with Visual Studio 2010, so it needs the Visual Studio 2010 C runtime library, msvcr100.dll.
Java 6 used the Visual Studio 6 runtime library, msvcrt.dll, instead.
The runtimes are not interchangeable. An application built for one runtime cannot use a different one. In any case, the runtime is unlikely to be the source of your problem.
Related
I have a problem running my application on other machines.
I am developing with Visual Studio 2008 in a Win7 x64 machine.
The solution contains several C# projects (the main application is written in C#, all others are library projects) and two c++/CLI libraries. The C++ libraries are Win32 and all C# projects are set to x86 target processor. No third party libraries used. Framework used is v3.5.
The application builds and runs fine on my machine.
I copied the whole "bin\release" folder to a Win7 x86 machine and it ran fine, too.
But when I tried on a XP x86 system, it did not start. No error message, not even showing up shortly in the task manager. The XP system has all updates installed, all available .NET frameworks installed and all Visual Studio Runtimes installed.
I checked with DependencyWalker and the only missing dlls are "IEShim.dll" and "wer.dll" which are only for Vista or higher.
I tried another of my applications that's not using C++ libraries and they work fine. So I guess I am doing something wrong deploying the C++ dlls.
Registering the C++ dlls with "regsvr32" failed with a "DllEntryPoint" not found message. Registering with "regasm" was successful, but had no effect.
What is it that I am missing?
Well, seems like I was a bit hasty stating "no third party components".
Actually it was the SQL Server Compact who was missing its runtime.
What are the different platforms/languages in which an app can be compiled and run on Windows without any prerequisites? I know of .NET but it requires the specific version of .NET to be present in the Windows installation.
C and C++, but Visual Studio defaults to dynamically linked library. Change the default to static and you will be fine.
That being said, ther are no compilers that come with windows. You must install a compiler to build the a program that will run everywhere after that. There are free version of the compiler in the Platform SDK and in mingw (Cygwin requires a dll).
If you are using Visual C++ as language and development tool, you may switch to Statically bound DLLs, which would produce larger binaries, but would run without any runtime-prerequisites. Visual C++ Runtimes are easily installable, can be distributed, or users may be asked to install them directly. If users are using Windows Update, they would anyhow get the latest VC runtimes.
My company is always having problems with software not working because "run-times" or missing. I hear people say this a lot (you need the 32-bit run times, Microsoft run-times, etc etc).
What exactly is being referred to? DLL files? Something different? Can anyone please clarify?
Run-time is basically the time at which your code is running (as opposed to compile-time or link-time).
In the context you're seeing it, it means run-time libraries, those libraries needed to load an execute your program.
This is dynamically linked stuff (DLLs or shared objects) since statically linked code can't be missing (it's in the executable file itself).
A classic example is to depend on Microsoft's C run-time or .NET libraries but not ship them with your product. That means your executable will run on any machine that has those libraries already there (such as those with Visual Studio installed) but not necessarily every computer you want to run your code on.
I answered a question here regarding the difference between static and dynamic linking which should hopefully add to your knowledge. The dynamic linking allows you to update certain parts of the application without recompiling or relinking. You do this by dropping in a new version of the DLL. Unfortunately, having that code in a separate file means it can go missing.
That would be one cause of the problem but I suspect the most likely is just that someone didn't do their installation code very well, otherwise everything needed would have been installed.
A runtime in this context is a runtime library - a shared library (on Windows indeed a DLL), most commonly specifically referring to the one which provides basic functionality of the language. It implements the functions that are thought to be "built into" a language core. Thus, no program compiled with a compiler which requires a runtime library will run if such a library for it is not installed - or if the program is specifically statically linked (with everything needed packed into the executable).
To give you a practical example - here are some links to some common runtimes:
Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) (x86 means 32-bit)
Microsoft Visual C++ 2010 Redistributable Package (x86)
Microsoft .NET Framework 4 (Web Installer)
These are system-wide installs - so any software that requires a particular runtime will be able to use it, once installed.
They are probably referring to Microsoft's 3rd party libraries and the .NET framework.
Your company's applications probably uses some 3rd party libraries such as MFC, ATL etc. in case of application's written in a .NET language e.g. C#, VB.NET, if you're developeing using Java there is a JRE (Java Runtime env) that have to be installed for the application to run.
If the required dlls/framework ween't installed/deployed on the customer's machine you'll probably get a "runtime error".
This is a deployment issue - which with the correct install process can be solved - e.g. the installer can check if the required framework is installed and if not install it as part of the installation process.
I have a c++/cli dll that I load at runtime and which works great in debug mode. If I try and load the dll in release mode it fails to load stating that one or more dependencies are missing. If I run depends against it I am missing MSVCR90.DLL from MSVCM90.DLL. If I check the debug version of the dll it also has the missing dependency, but against the debug (D) version.
I have made sure debug/release embed the manifest file. I read something about there being issues with the app loading the dll being build as Any CPU and the dll being built as x86, but I don't see how to set them both to x86.
I am using VS2010.
Anyway, I've been messing around for a while now and have no idea what is wrong. I'm sure someone out there knows what is going on. Let me know if I need to include additional info.
alt text http://www.freeimagehosting.net/uploads/fb31c0e256.png
UPDATE:
This ended up being the resolution to my problem: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/07794679-159b-4363-ae94-a68fe258d827
MSVCR90 is the runtime for Visual Studio 2008. If you are running your application on your development PC, then you should have the debug and release runtimes installed (as part of Visual Studio) but it is possible something has gone awry with your install, or that VS2010 doesn't actually include the older runtimes. If you're trying to run the Release on a different PC, then it just needs the runtime installed.
Either way, you may be able to fix it by installing the Visual Studio 2008 redistributable - but make sure you get the right download for your PC (x86 or x64).
In previous versions of VS, you needed the runtime for the version you were compiling with, so if VS2010 follows this precedent you'd need MSVCR100, not MSVCR90 - which suggests that you may not have recompiled the dll with VS2010 - doing so may be another approach to get it running on your PC (using the redist that is in your VS2010 install) but beware that you will still need other users to install the appropriate (VS2010) redistributable on their PC.
As for "Any CPU" versus "x86", this is a problem only on a 64-bit computer. On those systems a 64-bit application can't link dynamically to 32-bit dlls. If you compile your application as "Any CPU" it will be JIT compiled to be 64-bit on an 64-bit OS, so will crash if it tries to call any 32-bit dlls directly. THe solution is to build the application targeting "x86" as that forces the JIT compiler to generate 32-bit code (even on a 64-bit machine) and thus ensures compatibility with the dll you wish to call. If the DLL is a managed assembly, then you can use Any CPU on both the app an dll as they will both be JITted to the same format.
It happened to me something similar running a website in Vistual Studio 2012, after migrating from Visual Studio 2010. The error message was saying that MSVCR90.DLL was missing. The solution was:
1) Delete the folder _bindeployable located at the project path.
2) Rebuild.
I hope it helps.
This question already has answers here:
The application failed to initialize properly (0xc0150002)
(5 answers)
Closed 5 years ago.
my mfc application created in visual studio 5 running on windows server 2000 sp4, i create a release for it and try running it win xp slp2. it gives me application failed to initialize properly (0xc0150002)
i have tried following things
-Install Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) the one that comes within the release folder as well as one downloadable from website
copied all dll and mainfest from microsoft visual sutdio\vc\redist
I still keep receiving the same messsage. c
what could be wrong?how can i fix it
some things to check:
check the /SUBSYSTEM linker option for you project. It might include OS major/minor version numbers.
ensure that you are using appropriate Windows XP PlatformSDK on DEV machine; check values of WINVER, _WIN32_WINNT
use depends to see whether the problem is in unresolved dependencies
check the version of runtime that your application requires with that on target machine. I usually do this by looking at the app's manifest from one side and into WinSxS folder of the target machine from another (recently there had been an ATL Security update from Microsoft http://msdn.microsoft.com/en-us/visualc/ee309358.aspx; new binaries created by updated Visual Studio will not run on machines that haven't the same updated version of runtime).
It is possible you have applied a security update or compiler update to your VS2005 SP1. That makes it generate a manifest that requests a different MFC/CRT-dll than the one installed with Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) .
Try to use Depends.exe and open your application, then in the menu choose "Profile". Look in the output window below for a more detailed description.
Are you trying to run the debug version? That may give you an error similar to 0xc0150002. Try the release build, or you could compile against the static libraries rather than dynamic libraries. If you get this problem on a release build then the chances are that it's a missing dll (in which case try running Depends.exe) or an incorrect manifest.
If you have a missing dependency on a runtime dll you could try creating a deployment project for it as this will detect the appropriate runtime dlls and build it into an installer for you.