I've read about running 32 bit DLLs in 64 bit environments, especially here. But I'm still getting errors. Here's what I have. I have a real old 32-bit DLL that can't be converted to 64 bit. I have another DLL, my own, written in VB.NET, that I've compiled as x86. It calls the older one. My DLL is part of a Windows Service which I've compiled to x86 as well. So all x86 running on a 64-bit Win2012 server. The older DLL is actually installed on the machine itself, not part of my DLL or the Win Svc because of the nature of that DLL.
The older DLL is invoked using the standard X = CreateObject("oldDLL"). Everything works until I try to call a method on X. Then the method can't be found.
Any thoughts?
Related
I have created simple BHO with ATL using these instructions
http://msdn.microsoft.com/en-us/library/bb250489(v=vs.85).aspx. I am creating both 64 bit and 32 bit dll of the dll. The problem happens when I try to to unregistered the 64 bit dll after the 32 bit version using regsvr32, I am getting 0x8002801c error.
(If I try vise versa the same problem happens). I have added images to celrify.
I think it has something to do with TypeLib registration because I it does the same thing for the 64 bit and 32 bit with no difference, after registering the 32 bit i have these two keys
HKEY_CLASSES_ROOT\TypeLib{5EA5008F-7766-499D-B4B0-9A671C752333}\1.0\0\win32 default = C:\programming\vswork\testfile\test64atlcom\Debug\test64atlcom.dll
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib{5EA5008F-7766-499D-B4B0-9A671C752333}\1.0\0\win32 default = C:\programming\vswork\testfile\test64atlcom\Debug\test64atlcom.dll
Why does this happens, and how can solve it?
The error code is TYPE_E_REGISTRYACCESS. A typical problem with VS projects is that default template does not have x64 configuration and it's copying from Win32 does not update target environment in MIDL settings.
x64 build with Win32 would load and run, however it's registration would still COM-register the type library as 32-bit and cause 32/64-bit build collision.
So, you need to make sure that type libraries in Win32 builds target 32-bit, and x64 builds have them target 64-bit environment.
I have a simple program that makes a call via JNI to a DLL wrote ini C#.
Now when I run my servlet on Tomcat within a 32 Bit JVM, on a 64 bit PC, is the bitness of the DLL driven by the bitness of the JVM or of the Underlying hardware.
ie, Do I need a 32 bit or 64 bit version of the DLL?
Match the JVM, 32-bit JVM = 32-bit DLL.
I'm developing a C#/WPF app that talks to a USB device using some custom 32 bit dlls. It's developed as an x86 app, and installed with WIX. When I install the package on a 64-bit machine, the program files get installed to Program Files (x86) as I expect.
The dlls are installed to the SystemFolder using WIX. On 32-bit machines, this means C:\Windows\System32. On 64-bit, they end up in C:\Windows\SysWOW64. This is ok, but when I run my app, it is unable to find the dlls (it uses them via [DllImport...]).
So, what is the right way to make my app find the dlls, whether they are in System32 or SysWOW64?
Thanks
Tom
If it is a default C# app, it will automatically be a 64 bit app on 64 bit Windows (C3 defaults to 32 bit on 32 bit Windows). Go into the project properties in your development app and explicitly set the architecture (I think; I don't have Studio up right now) to 32 bit. If it is running as a 64 bit app, it won't be able to use your 32 bit DLLs.
Please check if the dll in application is of the same version as that in the sys32 or wow64 folder depending on your version of windows.
You can check that from the filesize of the dlls.
Eg: I faced this issue because my libeay.dll file in system32 had a different dll than my libeay.dll file in openssl application. I copied the one in sys32 into openssl and everything worked well.
I'm getting an 'AccessViolationException' 'Attempted to read or write protected memory' when calling a method in an x86 dll when running on an x64 platform (Windows 7). Everything works great on x86 platforms.
I've read many, many posts about similar problems but haven't been able to get my code to work.
I'm in the process of trying to make our old x86 app work happily on Windows 7 (x64) and Server 2008 R2 (x64). The app is an assortment of VB6 , VB.Net, C#, MicroFocus COBOL and C++. (We couldn't think of any other languages to throw in at the time). The DotNet code was originally written in Visual Studio 2003 for DotNet 1.1. I've ported the code up to Visual Studio 2010 and DotNet 4.0. I've set the target for all the projects to x86. When I call into un-managed 32 bit dll's I get the above error.
Our InstallShield setup routine is installing the x86 dll's into C:\Windows\sysWOW64 instead of C:\Windows\System32. This behavior seems correct. The dll's are some COBOL object code and runtime components linked together into a 'C Style' dll. I don't think the problem has to do with COBOL or the linking process as I also ported up a sample app from Code Project with a VB.Net WinForms app that calls a simple C++ dll, all targeted to x86. I get the same error there. I've also tried building a C++ command line app to call the dll. The Load Library succeeds. GetProcAddress succeeds. Calling the function pointer for the particular method fails. Our VB6 apps can call the dll's just fine when running on Windows 7 x64. I've also tried turning off UAC and setting the requestedExecutionLevel in the manifest to the highestAvailable. I've tried running as administrator.
Seems like this should work, but not sure what to try next. Any ideas?
On x64 .net programs will be run as 64-bit programs and cannot call 32bit-dlls.
Try compiling the application with target x86 instead of "Any Target". You can also force the
target of the built .exe with the .Net CorFlags.exe utility to run in 32bit-mode.
Of course your program will then run in the 32bit environment, especially it will only have a maximum of 2gb of RAM.
Good news,
We investigated DEP as a possible cause of the problem as we saw that even our VB6 code will fail when DEP is turned on. We noticed that the VB.Net code was failing in the same way as VB6 when DEP was on. Apparently our COBOL dll's do something that DEP isn't happy with. Unfortunately the DotNet assemblies don't seem to respect the operating system DEP setting, so you have to turn off DEP with using editbin.exe:
editbin.exe /nxnocompat:no
I still have to test it on our full application, but it looks like we have a solution!
I've built and installed my service from vs2010 onto a 64bit machine.
My problem comes in when my service references 32 bit dlls (spssio32.dll to be precise) - I get the error in my event viewer : "System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Any help on the matter would be appreciated.
Regards,
Byron Cobb.
Is your service code written in a .NET language? If so, you need to mark it as targeting x86 rather than Any CPU (via Project properties / Build / Platform target).
(By default, .NET code targets Any CPU, meaning that on 64-bit machines it will compile into x64 machine code. Because such 64-bit code can't load 32-bit DLLs, that can lead to failures like the one you're seeing. Where code has a dependency on a 32-bit DLL, it needs to always compile to 32-bit machine code even on 64-bit machines, hence setting the target platform to x86.)
You can use a COM surrogate
http://www.dnjonline.com/article.aspx?id=jun07_access3264
The other variant is to spawn an external 32 Bit server-process and add a .NET remoting interface to it and your 64 bit application, so you can use .NET remoting for interprocess communication.