Cannot Load 32-bit .dll On A Amd 64-bit Platform

[Stefanie Mordaunt]

Ihave temporally solved the problem copying the ocijdbc11 files (.dll and .sym) from the 64-bit Oracle Instant Client 11.2 and pasting them to the 32-bit folder, but I know that some error occurs soon.

You cannot load 32bit libraries into 64bit processes and vice-versa. Therefore the only option if you really need 32bit libraries is to use a 32bit KNIME Analytics Platform installation. Which has certain drawback, of course.

There is company software that needs a 32-bit Oracle Client, so I have put this client into the Oracle path, and I have added this path in system variables, before the path of 64-bit Oracle Client.

This procedure ensure that the company software works correctly.

If I want to connet to Oracle DB from KNIME Analytic Platform, now, KNIME follows the first path written in system variables.

Instead, if I put the 32-bit path AFTER the 64-bit one, the Oracle connection works, but the Company software not.

This problem is popular when you work on 64-bit JVM and try to use 32-bit libs.

I remember when I had this problem with LeJOS on some project.

To be honest its not a hard-to-solve problem but still, there are times when you are exhausted by the whole day, you add some 32-bit lib on your 64-bit JVM getting in effect "Can't load IA 32-bit .dll on a AMD 64-bit" and have no clue what the friendly-word.

Anyway nice art.

If you have time could you make one about why use 64-bit JVM on 64-bit machines, it would be great. But it would be a long one I guess.

we are running IDM 8.0 with latest SPs. Now, trying to connect an ABAP system runs into connection error "Parameter message server host ('jco.client.mshost') is missing" although all parameters are correctly set. So after some investigation and checking some SAP notes I tried to check the installed JCo version (system was installed & updated using SWPM/SUM). The console showed Java VM version and JCo3 API. But library could not be found. Instead there was an error "Can't load AMD 64-bit .dll on a IA 32-bit platform".

Ok... so, following note 2313331 I replaced the JCo3 files with the 32 bit version, re-started everything and checked again the JCo console. Now, it's fine - no errors, library was loaded, initialization successfully.

Great, I thought, problem solved, I thought... Nope.. the connection test to ABAP repository still failed. I increased the trace level and checked the DSE.log file. Now, here comes the funny part... it says "Can't load IA 32-bit .dll on a AMD 64-bit platform" (>_

Although quite old, maybe someone else still gets here

"Parameter message server host ('jco.client.mshost') is missing" means you specified jco.client.r3name but not jco.client.mshost, which is mandatory in this case. If you would like to do a direct application server logon instead of a load balanced logon, then simply drop jco.client.r3name and specify jco.client.ashost and jco.client.sysnr instead. jco.client.r3name is not needed for direct application server logons.

Of course, it is applicable. My answer explains what error message "Parameter message server host ('jco.client.mshost') is missing" means and how it can be solved - the initial issue of Richard. This answer is just not saying anything about the subsequent unneccessarily performed installation errors due to the wrong library with wrong bit-widht being used. In general, an answer does not need to cover all details of a question, especially not if it is a late answer for a 2-year old question.

In general, native libraries loaded by a Java VM must match the JVM's own word size, i.e. a 64 bit JVM will only ever load 64 bit native libraries successfully. Assuming you're using SAPJVM 8 for SAP IDM 8.0, it seems unlikely that the 32 bit version of the JCO DLL is the correct one, because -at least on the public download location at - SAPJVM 8 is only available for x64. Hence, my guess is that this can only work with 64bit JCO.

Maybe the misleading results you received from the console in your initial analysis have been caused by a different environment of your own user (which may have a different path and other environment variables), compared to the OS user that is executing the SAP IDM runtime?

Could it be that the real root cause is really more related to the connection parameters -which implicitly combine with data read from the SAP IDM runtime matchine's content of /etc/services- , and that there was initially no problem at all with the native library?

My project consists of an executable program and several DLLs, all compiled with IVF. Another 32 bit program starts the Fortran executable and calls various functions in the DLLs. The Fortran executable is compiled in 32 and 64 bit versions and the appropriate one is installed on the target machine. There's no advantage to making separate 32 and 64 bit DLLs, and in fact I've read elsewhere that problems might occur in calling functions in a 64 bit DLL from a 32 bit program. So on a 64 bit system I have a 64 bit Fortran executable and several 32 bit Fortran DLLs. The problem I'm encountering is that the required redistributable DLLs, for example mkl_rt.dll, come in 32 and 64 bit versions with the same name, and some are used by both the 32 bit DLLs and 64 bit executable. I can't figure out how to install both versions so that the executable and DLLs will call the appropriate ones. I could create subdirectories for the redistributable DLLs, but is there a way to tell the program DLLs where to find the correct redistributables? Or is it possible to rename one set of redistributable DLLs and tell the program executable and DLLs to use them instead of the defaults?

Windows makes this easy. 64-bit Windows will skip over the "wrong architecture" DLLs when searching, so all you have to do is put your 32-bit and 64-bit DLLs in different directories and add both directories to PATH. (You could also put them alongside the executable if they're in different folders.)

our experience with 64-bit MS Excel is that it is unable to load 32-bit DLL's. So where customers are using 64-bit Excel, it appears we need to develop 64-bit DLL's in addition to the 32-bit versions.

Yes, if you have customers using 64-bit Excel you will need to provide 64-bit DLLs and make sure Excel loads the correct one. If you have your DLLs in PATH, then this is easy, but if Excel is specifying a fully qualified file path, then it's more complicated.

Do your comments about Windows skipping over the wrong architecture DLLs apply in the 64-bit Excel case? Can I install both the 32-bit and 64-bit DLLs into separate folders, and add both locations to the path, or is that expecting too much?

Thanks very much for the information. I really dislike it when applications add to or modify my system's PATH environment variable, so I won't have my application do it to others. Because my application consists entirely of 32 bit components (executable and several DLLs it calls) except for one 64 bit executable started by the main program, I decided to put all the 32 bit components into one main directory along with mostly shared 32 bit run time DLLs, and the 64 bit executable into a subdirectory with its 64 bit run time DLLs. That's the easiest scheme for me to implement and live with, and keeps my application's run time DLLs separate from everyone else's and vice versa. It appears that the side-by-side methodology could do the same, but with a lot more effort on my part.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

After pressing "Login" in the launcher, the new window pops up and remains white. There is no error message and I have to manually close Minecraft. This happens on any modpack as well as the vanilla.

Any and all help is appreciated as I can not figure out this on my own. Google has not been of much help either and all suggestions seem to point to recompiling, but I don't know how that applies to my case. Thanks!

How many versions of Java do you have? Check your Control Panel. That error has always been associated with trying to run 32-bit Java on a 64-bit system. Your Java install in your Control Panel should specifically say 64-bit. If it doesn't, you have the wrong version.

As in the Java control panel? There does not seem to be anything denoting any form of bit, however the only install of Java shown in that panel is in the 64-bit program files folder. As I said, I have even tried to re-install java with no luck.

also, I did a little digging and I see what you mean about having a hard time googling the problem. from what I can gather, this issue is caused most often by the 64-bit libraries being inaccessible for some reason. either the JVM has no read permissions to them or it can't find them so it defaults to 32-bit and dies.

the other thing you could also try is using command line arguments to force java to look in the right place for the LWJGL libraries. do this by using the -Djava.library.path="path/to/lwjgl/64bit/dlls" command line parameter. in order to make that stick though you'll need to use a second little trick to prevent the launcher from restarting itself with default parameters. make a batch file in your .techniclauncher directory. in the batch file, place the following lines:

As far as I know, JVM should have read permissions on the .dlls. I can't think of any reasons as to why it wouldn't. My Windows and Java installs are both standard and I have not been playing with permissions settings. From the error though, it seems right that the lwjgl.dll panics because it can't handle 64 bit instructions, but even with the switch you supplied it won't load the 64 bit version.

3a8082e126