I had application, that was made in 32 bit system.
Now, I have 64bit, and the app automatically switched to load 64 bit dependencies... (and it crashes in 64bit OS).
however, how to force it to load not from Wow64, but from system32?
How to force it to load not from Wow64, but from system32?
WoW64 is the way to call 32-bit LIBs/APPs from a 64-bit system. I quote from this Wikipedia entry:
In computing on Microsoft platforms, WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the Windows operating system capable of running 32-bit applications that is included in all 64-bit versions of Windows[...]
So WoW64 accesses the 32-bit system32 LIBs by design, because that's its sole reason to exist.
Related
I am wrestling with an issue I cannot understand. We have a ClickOnce deployment of a WPF application in Azure blob storage. The processor architecture is everywhere "msil" in this deployment. When it gets run from IE, it runs as a 32bit application on AMD64 computers. The desired behavior would be to run as 64 bit. Could someone please enlighten on where should I look to fix this problem?
I already managed to go through the hoops to build the assemblies as x64 and create the ClickOnce deployment as amd64. This combo will run as 64 bit. The desired behavior is to still have it "msil" so it can run as either 32-bit or 64-bit, depending on the operating system it will be running on.
I know similar questions have been answered before, but I can't seem to clear my particular problem.
The architecture mismatch exception is prompted when Db-driver and VS-project have different platform targets (32, 64 bit). So far so good.
First thing I tried:
I changed my platform targets for my whole solution to 32 and after that to 64 bit.
-> same error in both cases (I'm not sure under which circumstances VS considers a project to be of a specific architecture, though. Maybe someone can elaborate on this point...)
Now I focused on the driver and DSN for Virtuoso 7.1.
Following the instructions for installing of the open source version of Virtuoso (link), I registered the driver in /lib using 'regsvr32 virtodbc.dll'. This promptly added it as a 32-bit Driver (visible when using the system32/odbcad32.exe). Using this driver in a DSN provided the architecture mismatch.
I tried to register the same dll as a 64 bit driver using the 64 bit version of regsvr32 without success. Since I can not add a suitable 64-bit DSN I would be content in using the 32-bit target cpu. As described the seemingly 32-bit versions of the virtodbc.dll are causing a architecture mismatch under any target platform configuration in VS.
I even installed the Client Connectivity Kit (link) which claim to provide only 64-bit drivers. Only to find out that the automatically installed drivers and DSN are also featuring as 32-bit drivers (meaning: they are only visible when using the 32-bit version of odbcad32.exe and not the 64-bit version)
I'm not sure where the problem lies (VS or Virtuoso drivers) and I would be thankful for your suggestions.
I think, you could try to install 32-bit ODBC driver from Virtuoso 6.4 Client Connectivity Kit.
p.s.
64-bit ODBC app requires 64-bit ODBC driver (and 64-bit ODBC driver manager)
32-bit ODBC app requires 32-bit ODBC driver (and 32-bit ODBC driver manager)
You can not mix them.
I am not quite sure I understand what your problem was or is ?
What is the bit'ness of your Visual Studio installation i.e. 32 or 64 bit ?
system32/odbcad32.exe is the 64bit ODBC Driver Manager despite the "system32" reference, which is a historic folder Microsoft retained from the 32 bit Windows days, placing the actual 32bit binaries on a 64bit system in sysWOW64 folder.
To make things even worse in the last 64bit Visual Studio I used the development environment is actually 32bit and the deployment is 64 bit, requiring a 32 & 64 bit driver for development and deployment, see http://wikis.openlinksw.com/dataspace/owiki/wiki/UdaWikiWeb/MsSqlOn64bitWin
As Virtuoso 7 is only available in 64bit form and the Virtuoso 6 ODBC Drivers (and data access client in general) are compatible with Virtuoso 7 server, you can install the Virtuoso 6 commercial (as Sergei mentioned) or open source (http://bit.ly/1A3mCje) 32 & 64 bit ODBC Drivers and VS should then just work as it has one for development and one for deployment.
I am upgrade my 32 bit sample Voip application to 64 bit. After upgrade my application .exe file give a problem:
The application was unable to start correctly (0xc000007b)
My PC is 64 bit. and i build it in 64 bit
I realize this is probably late for you, but for anybody looking at this question, the problem is that you have a mixture of 32-bit and 64-bit components (DLLs) that are loaded at start-up. Since your app is built as 64-bit, you probably still have some 32-bit DLLs that the system attempts to load in the process and fails (since 32-bit modules cannot be loaded in a 64-bit process).
Recently since I moved to Excel 2010 64-bit I discovered that many add-ins (XLLs) I used regularly stopped working (Excel reports an "invalid add-in" error when I try to add it).
Does it always hold that 32-bit built add-ins are never compatible to 64-bit Excel, or is it just the case of my add-ins?
32-bit plug-ins won't run in IE 64-bit. 32-bit drivers won't run under 64-bit Windows. 32-bit add-ins won't run in 64-bit Office. It's not just you, it's because 64-bit programs can't load 32-bit modules.
Please see Compatibility Between the 32-bit and 64-bit Versions of Office 2010
"Native 64-bit processes in Office 2010 cannot load 32-bit binaries. This is expected to be a common issue when you have existing Microsoft ActiveX controls and existing add-ins,"
One more link from MS about the differences between 32 and 64 bit versions of Office, and how 64-bit versions cannot run 32-bit add-ons.
We have a 32-bit ATL out-proc COM server. In order to register itself in the registry it calls CComModule::UpdateRegistryFromResource() and passes an id of a .rgs file compiled into the resources of the same executable.
Works great on 32-bit systems, but not on 64-bit ones. Obviously when a 32-bit .exe runs on a 64-bit Windows its registry accesses are redirected and so it registers itself in "32-bit HKCR" and so 64-bit programs don't see its registration.
How do I register the same out-proc server in the 64-bit HKCR the cheapeast and most reliable way?
As far as I can tell/remember you don't actually have to do anything special.
I have checked a 32-bit ATL COM EXE server which I wrote specifically to be called from 64-bit code ( http://www.pretentiousname.com/adobe_pdf_x64_fix/index.html ) and the registration code is completely boilerplate (unless I forgot and today cannot see something I had to change).
Unless the code on the 64-bit side calling CoCreateInstance(Ex) is specifically passing CLSCTX_ACTIVATE_64_BIT_SERVER, COM should automatically check the 32-bit registry if needed. (Even if CLSCTX_ACTIVATE_64_BIT_SERVER is passed it may still do. MSDN isn't entirely clear if that flag is a preference or a requirement. I'm assuming it isn't being passed anyway.)
Perhaps the problem isn't how the COM server is registered but something else. Or perhaps there is a broken 64-bit version of the server registered, maybe from earlier in development/testing, which is being chosen over the 32-bit server and failing?
By the way, there are differences in which parts of the registry are 32/64-bit split on Windows 7 vs earlier OS versions, but I know from experience that you don't need to do anything special on Vista, Windows 7 and Server 2008 R2. I haven't personally tested on other OS versions (e.g. XPx64).