Msvcr71 dll and java

Worse yet, Sun does not follow their own advice: Sun places a java.exe into the Windows system32 folder. So Sun must be following its own advice and place a msvcr71.dll next to that java.exe, right? No, they don’t. So, when java.exe is run from there, it will fail, right? No, it works. So what is going on? Clearly Sun’s java.exe is not following their own advice. Even stranger still is that when there IS a msvcr71.dll right next to java.exe in the system32 folder, it is not used. The msvcr71.dll in the Java installation bin folder is used instead. That seems to violate how LoadLibrary() works.

The bottom line: Sun’s points to a Microsoft article for the reason why they are telling us to copy msvcr71.dll into the same directory as the EXE. That advice is not very good (and something Sun itself does not follow for their own java.exe), and certainly is not ‘future proof’. EXE’s are breaking now. Sun’s fix is to copy msvcr71.dll next to the EXE. But in the future, when Sun moves on to another msvcr##.dll version, your EXE will still work, right? NO. Your ‘fixed’ app works just fine now, but when Java 7 ships and requires msvcr100.dll, your application will once again break. Sun has learned nothing from this experience because they are recommending a course of action where they know that EXE’s will once again break in the future when a new Java VM is shipped.

The Issue: We want LoadLibrary() on the JVM to work on the Java VM without moving any msvcrXXX.dll next to the application EXE. Can that be done? That is what Sun is doing with their java.exe! After all, msvcrXXX.dll is needed by the Java VM, not the EXE. Under Windows, you can use LoadLibrary() to load the Java VM. But how do you force msvcr71.dll, located in the Java bin folder, to be found and used before any other msvcrXXX.dll on the system? Finding another msvcrXXX.dll on the computer (like windows system32) is very likely just fine, but we want to be 100% safe and use the one that Java ships in the Java installation folder (just like Sun’s java.exe does).

Strange enough, on all of my XP and Vista machines, there in the Windows System32 folder is msvcr71.dll. How did it get there? On one of the XP machines, I renamed msvcr71.dll, restarted Windows, and upon startup, an Adobe component complained about msvcr71.dll not being found. I then tried to run Adobe Reader, and it reinstalled itself on the fly, recovering from the ‘lost’ DLL.

The application (EXE) directory or LoadLibraryEx() alternate order
SetDllDirectory()¹ or if NULL and SafeDllSearchMode² is OFF the GetCurrentDirectory()
GetSystemDirectory() folder (eg: C:\Windows\System32)
The 16-bit system directory (eg: c:\Windows\System)
GetWindowsDirectory() folder (eg: C:\Windows)
If SafeDllSearchMode² is ON, GetCurrentDirectory()
Directories in the PATH environment variable

¹SetDllDirectory is new to Windows XP SP1 and Windows Server 2003
²SafeDllSearchMode is ON by default on Windows XP SP2, Server 2003, Vista

One Possible Easy Solution: We can easily modify the PATH to include the Java bin folder via GetEnvironmentVariable() and SetEnvironmentVariable() before calling LoadLibrary(). It works! But, what if there is a msvcr71.dll in the Windows system32 folder? It would be found and used by the Java VM first. Technically, we need to force the msvcr71.dll located in the Java bin folder to be found first and used (like java.exe).

Strategy: As can be seen from the first search step above, if all of Sun’s Java DLL’s were in the Java bin folder, the best option would have been to simply use LoadLibraryEx() with the alternate search strategy. But this will not work since the JVM.DLL is in a ‘client’ or ‘server’ sub-folder of the Java ‘bin’ folder. That leaves the second search step above and SetDllDirectory(). But since SetDllDirectory() is a new Windows function, we also need the backup method of GetCurrentDirectory() to work on older Windows computers. So.

Call SetCurrentDirectory() and SetDllDirectory() to the Java bin folder
Call LoadLibrary() on the full path to the jvm.dll
Call SetCurrentDirectory(old-dir) and SetDllDirectory(NULL)

Please note that this solution relies upon Sun properly placing any DLL’s that their Java VM depends upon into the ‘Java installation bin folder’. If Sun changes the folder layout, they will obviously break things once again. Since the ‘bin folder’ layout with client/server/hotspot sub folders applies to Java 1.3, 1.4, 1.5, 1.6, and now Java 1.7, hopefully common sense will prevail and Sun/Oracle will continue to keep the layout the same and all dependent DLL’s in the ‘bin’ folder.

Источник

Java Loves MSVCR71.dll in 64-Bit

As I installed DevMail on fresh 64-bit Windows system, I was greeted with «The program can’t start because MSVCR71.dll is missing from your computer. Try reinstalling the program to fix this problem.» Although program started normally when I dismissed error message I found it annoying.

After some troubleshooting I narrowed issue on Java. And I found pretty good explanation of this problem. After knowing this, solution was simple.

I went into «C:\Program Files (x86)\Java\jre6\bin» folder and copied «msvcr71.dll» from there to DavMail’s application folder («C:\Program Files (x86)\DavMail»). This way DavMail found his dll and everybody was happy.

P.S. It was interesting to see that DavMail developers had more than one ticket open on this subject. They closed them with solution «reinstall Java». That solution is invalid. Real solution would be to include this dll with installation.

P.P.S. I found it annoying and idiotic of Sun Oracle to remove this bug from their bug database. That bug used to exist (and thus we know that it’s ID is 6509291) but they removed it. Only reason that might fit Sun’s Oracle’s FAQ is «security reasons». How this applies to this situation is anybody’s guess.

2 thoughts to “Java Loves MSVCR71.dll in 64-Bit”

Thanks for explaining this in a simple manner… I had found the solution on other sites, but they weren’t clear which .dll to copy and many said to place it in windows/system32 which did not work for me.

For those who are running Java 7, the file is msvcr100.dll instead of 71. The solution is to simply copy and rename the same file to msvcr71.dll in Davmail folder.

Источник

Msvcr71 dll and java

Products
Services
Solutions
Support
OEM
Company
Blog

Easysoft ODBC-JDBC Gateway

Why do I get error «MSVCR71.dll was not found»?

The full text of the error is:

odbcad32.exe - Unable To Locate Component This application has failed to start because MSVCR71.dll was not found.

This error occurs when the Java Virtual Machine ( JVM ) on the Easysoft ODBC-JDBC Gateway machine cannot find the msvcr71.dll file. This can cause the JVM to crash, which then crashes the ODBC-JDBC Gateway and the ODBC Data Source Administrator.

To resolve this issue, find the path to the folder where msvcr71.dll is located on the Easysoft ODBC-JDBC Gateway machine. This file is usually located in the bin subfolder of the jre folder. For example:

When you have the msvcr71.dll folder path, add it to the Path environment variable value:

Updating the Path on Windows 2000, XP and 2003

In Control Panel, double-click System. In the Advanced tab, click Environment Variables.
In the System variables list, highlight Path , and the click Edit.
In the Variable value box, add the msvcr71.dll folder path to the list of paths. Use a semi-colon ( ; ) to separate the msvcr71.dll folder path from the existing list of paths.

Updating the Path on Windows Vista and 7

Do one of the following:
- On Windows Vista, in Control Panel, double-click System.
- On Windows 7, in Control Panel, click System and Security.
Click Advanced System Settings.
Click Environment Variables.
In the System variables list, highlight Path , and the click Edit.
In the Variable value box, add the msvcr71.dll folder path to the list of paths. Use a semi-colon ( ; ) to separate the msvcr71.dll folder path from the existing list of paths.

Applies To

Knowledge Base Feedback

Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Источник

Janel: Java Native Executable / Launcher Discussion

Just a note to help anyone else who stumbles on this — you need to copy msvcr71.dll from the jre1.6.0/bin directory to the directory where you have the janel executable or you will get an error message and your app will not run. It’s covered in the release notes (http://java.sun.com/javase/6/webnotes/), but it took me a little bit to figure out. Greg