Puzzling DLL load issue

Question

Hi,
I have a java program that loads a C++ DLL via JNI (using 3rd party JNIWrapper). This DLL then calls into a C# DLL via COM. I was using java 1.6.04 and this worked perfectly.(Btw, I did not know that the java.exe was copied into c:\windows\system32 by the java installer).
I then installed java 6 update 11(that means the java.exe in C:\windows\system32 is not update 11), and the program stopped working. The java program would be able to call into the C++ without any issues but the C++ DLL would no longer be able to find the C# DLL. A test C++ program is able to load both the C++ and C# DLLs successfully. The location of both the C++ and C# DLLs are in my path, so I do not see any reason why the C# DLL would not get loaded. More surprisingly, why would it stop working when I installed java 6 update 11. As the program was not working, I uninstalled java 1.5.04 from my machine. Did something change in java 6 update 11 (or java 6 update 10, as it does not work with that either).
Any help or views into this would be very useful.
Thanks

Answer 1

ok here are some details of my experience with this problem (that I still havnt resolved).
I have a set of third party C# dlls, that I needed to use from a java program. To do this I wrote a C++ program that used JNI to link them. My C++ dll works fine, as I can write a test C++ application that links to it, uses it and runs. Alternatively, if I place all of the third party dlls in the java bin directory (where java.exe is being executed from when I run it in net beans), everything works fine in my java program when I run it from net beans. I simply call LoadLibrary() on my dll, and native function calls work.
The problem, is when I try to avoid placing these dlls in the java bin directory. Placing them on the path or calling LoadLibrary() on them (when they are in the VM library path) does NOT work however. I see no explanation for this behavior other than a problem with java. The VM crashes, and prints out a stack trace. I can clearly see that all of the third party dependencies had been loaded before my dll, just like in the working case. The only difference is that the list of loaded dynamic libraries cuts off at rsaenh.dll.
Similarly, if I create a jar (rather than running from net beans), I can not get it to work at all. It is the exact same symptoms as mentioned above, except that it also occurs when I place the third party dlls in the system32 folder (and all of the java bin directories).
Based on the behavior I've observed, I don't see how the problem could not be with java. The dll's have been demonstrated to work perfectly. The only issue is that the JVM crashes if it loads the dlls from anywhere but the java bin directory.
edit about GAC: I have not tried adding my dlls to the GAC because they are third party. They are not strongly signed and as far as I know there is no way I can add them.
Edited by: michael879 on Jul 27, 2009 4:48 PM