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.
Related
I need to run the vb6 32 Bit dll in .net application. When I run the application in X86 it works fine. But when I run the application in "Any Cpu" Configuration it gives Following Error:
Retrieving the COM class factory for component with CLSID {AAA4DA7D-FC03-4BF7-B240-FA6F323D41EE} failed due to the following error: 800700c1 is not a valid Win32 application. (Exception from HRESULT: 0x800700C1).
For the Code line
CommonUniqueObj = New Uniquekey.Class1
How to solve this error. I want to run the .net application in "Any cpu" configuration?
AX (COM) DLLs run in-process, and as the comments say, you can't mix x86 and x64 code directly.
One possible workaround is to compile the VB6 DLL as an AX EXE instead. 64-bit programs can instance AX EXEs and data can be marshalled between them, since they run in separate processes.
You can mix 32 bit and 64 bit. By calling into an exe bitness doesn't matter. Data is marshalled as with any out of process call.
DLLs can be run in an exe by setting registry values.
See https://learn.microsoft.com/en-us/windows/win32/com/dllsurrogate
PS when using an exe it is a good idea to always set everytime just before you use it in case the user has terminated the dllhost.exe that hosts the DLLs.
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?
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 have a C#/WCF application (hosted in windows service) which was deployed and tested on 32 bit Windows server. Now I need to deploy it for production. My network team suggested to deploy it on 64 bit Windows Server to take full advantage of server capabilities.
My questions:
Is there any performance gain in deploying an application on 64 bit OS? If yes, how much?
Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
P.S. My application is compiled with "Any CPU" option (Does it matter?).
There is blogs of information out there on this. A quick Bing will bring up 1000s of talking points: http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC But, to be brief:
Is there any performance gain on deploying an application on 64 bit OS? If yes, how much?
The most noticeable benefit is memory utilization - specifically, your service/app, and all of the server's other services/applications, have more room to play. Only true if you have 4 GB or more of RAM. If you have less than that, you are actually wasting memory by each allocation of block.
The benefit, at the raw-performance level, is for every CPU cycle, you can execute up to 64bits of information, instead of 32bits - double the information. Significantly more noticeable with multi-threaded applications: e.g. Your WCF Service hosted in IIS, which is multi-threaded for the incoming requests. :)
Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
Short answer, nothing what-so-ever. :) And that's the benefit of .NET, when you compile with the default "Any CPU" option!
When you compile code into assemblies, you are compiling code into an Intermediate Language (IL) - not actual machine code. The .NET CLR (Common Language Runtime) version, that is installed on the specific server/workstation/device that you are deploying to, is what takes your IL code and executes it in native instructions for that specific platform - x86, x64, or IA-64 (or AMD64, ARM, etc if there any tweaks utilized). You do not have to do anything!
As for coding practices, there is nothing specific to do either.
Referencing 3rd Party Native Assemblies?
Now, the only concern is if you are using referencing any 3rd-party assemblies through COM or alike that are compiled in native code (i.e. basically, 3rd party assemblies writting in raw languages). That becomes tricky referencing a 32-bit native assembly via a CLR on a x64 machine (basically, you have to force your application to complile to 32bit to access it). There are other work-arounds though, which is outside of the scope of this answer.
That's why I either: stick to all .NET references, reference only 3rd party assemblies written in .NET, just write it myself, or beg the author of the 3rd party component to release both 32bit and 64bit compiled versions. The latter becomes difficult to test on your x86 (32bit) machine as you can only reference the 32bit versions, but will have to deploy the 64bit versions.
More-of-a-headache is when dealing with your own WCF project, and those 3rd-party native assemblies, is that the built-in WCF hosting service in Visual Studio (as well as Cassini) is only 32-bit, as well as Visual Studio's IntelliSense. Yeah, it's fun when using 3rd party native assemblies and trying to debug applications on a x64 machine. Good times!
I heard on Windows x64 architecture, in order to support to run both x86 and x64 application, there is two separate/different sets of Windows registry -- one for x86 application to access and the other for x64 application to access? For example, if a COM registers CLSID in the x86 set of registry, then x64 application will never be able to access the COM component by CLSID, because x86/x64 have different sets of registry?
So, my question is whether my understanding of the above sample is correct? I also want to get some more documents to learn this topic, about the two different sets of registry on x64 architecture. (I did some search, but not found any valuable information.)
I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.
For example, let's say you have an application that stores its registry information under:
HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX
If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX
This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.
Your understanding is correct. There wouldn't be any need for a x64 app to access the x86 CLSIDs since it could never load those components anyway and vice versa.
If you want to create component for use by both x86 and x64 then you need to either create a pair of dlls one built for x86 and the other for x64 and register both in their appropriate parts of the registry. The regsrv32.exe in the System32 folder will perversely register the x64 component and the regsrv32.exe in the SysWOW64 folder will register the x86 component.
Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.
They aren't separate registries--one is a subnode of the other, and the OS does virtualization to make sure that 32bit apps get their keys and 64bit apps get their keys.
Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:
http://en.wikipedia.org/wiki/WOW64
I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.
Per MSDN, there is apparently a difference:
http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx
HTH
How to register .NET assembly to be used as COM in pure 64-bit application?
Problem:
By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.
Solution:
To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:
cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"
This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.