I've got a new computer with Win7-64 on it. I installed VS2010, and am trying to compile a C++ unmanaged DLL for a 32-bit environment. When I look at the created DLL in Dependency Walker, I see my file is 32-bit, but all dependent DLLs are 64-bit, and the error message: Modules with different CPU types were found.
What do I need to do so that the DLL is usable, and I don't see an error in depends.exe?
You need to use 32-bit Dependency Walker (both can be installed on the same machine).
Dependency Walker isn't smart enough to use the WOW64 directories, so 32-bit dependencies are only found when Dependency Walker is itself running inside WOW64.
Related
When compiling my Rust app in Windows 10, it is linked against ucrtbase.dll; however, this dll does not exist on some editions of Windows Server 2008 R2 Datacenter, making my app impossible to execute.
I tried setting -Ctarget-feature=+crt-static as found here, but it did not do anything; ldd app.exe still shows this dll.
Is there a way of removing the dependency on this dll?
If your Rust app does not depend on C libraries that specifically require the MSVC toolchain, you can build it for the x86_64-pc-windows-gnu (or i686-pc-windows-gnu, to build for 32-bit CPUs) target instead. This target links to DLLs that are available in all Windows versions.
For more information about the different Windows ABIs, you can check out this documentation page.
I have installed VSCode and GO extension with defaults packages.
My project need to load a 32-bit DLL. When I launch project with F5, I get error 193 on syscall.LoadLibrary().
I found on internet that error usually occurs when someone try to load a 32-bit DLL on a 64-bit arch.
I think if I debug with GOARCH=386 I would be able to load the DLL. But every time that I try to execute with GOARCH=386 I get error on VSCode saying that this architecture is unsupported.
Need help.
(I assume that a 64-bit DLL is out of reach)
64-bit process cannot load a 32-bit module into its process space, and a 32-bit processes cannot load a 64-bit module into its process space. The only way that communication can happen between 32-bit and 64-bit modules is through inter-process communication (IPC). Microsoft recommends that you use inter-process COM to use 32 bit code with a 64 bit application. Here's an article explaining the process. It's ugly.
If it's OK on your end, build your project to X86 platform (32-bit). In that way ehlapi32.dll is compatible & problem solved. Your 32-bit software is still supported on a 64-bit platform as 32-bit processes can be executed on 64-bit Windows operating system.
--
I familiar with C++ & not at all with GO. I have no idea how (or if at all) that technique can be implemented in GO.
The issue is because you are trying to load 32bit dll on 64bit architecture. Use 64 bit dll file. Along with that Install using 64bit dll for golang.
Just if you try to install delve from 32bit dll on 64 bit OS. This is also mentioned in the issues on github:
https://github.com/derekparker/delve/issues/20
VS Code complains if you want to run 32bit dll on 64 bit OS.
If you have 32bit dll for golang Uninstall that and install from 64bit dll again.
UPDATE: This is all essentially bogus. It turns out the version of Depends.exe on the machine where the application runs was the 32 bit version. Upon fixing that, both machines show the system DLLs as 64bit, so that is not the source of the problem. Not sure why depends shows them that way in a 32 bit exe.
FURTHER UPDATE: Ultimately the problem was one 64 bit DLL. This was easier to find after using the correct version of Dependency Walker. Selecting the 32 vs 64 bit version is not based on the platform you're running on. From the FAQ:
Dependency Walker will work with any 32-bit or 64-bit Windows module.
There are 32-bit and 64-bit versions Dependency Walker. All versions
are capable or opening 32-bit and 64-bit modules. However, there are
major advantages to using the 32-bit Dependency Walker to process
32-bit modules and the 64-bit Dependency Walker to process 64-bit
modules. This is especially true when running on a 64-bit version of
Windows, which allows execution of both 32-bit and 64-bit programs.
The 32-bit subsystem on 64-bit Windows (known as "WOW64") has its own
private registry, "AppPaths", "KnownDlls", system folders, and
manifest processing. Only the 32-bit version of Dependency Walker can
access this 32-bit environment, which is needed to accurately process
a 32-bit module. Likewise, only the 64-bit version of Dependency
Walker can fully access the 64-bit environment, so it should always be
used for processing 64-bit modules.
I have an application that builds correctly on one machine and incorrectly on another one. Both are MacBook Pros running Windows 7 via BootCamp. They are being built via QtCreator with VS2010 as the compile/link tool.
On Machine A it compiles and links without any reported errors. However, when run it fails with a 0xc000007b error (STATUS_INVALID_IMAGE_FORMAT). Depends.exe confirms that the exe is a 32-bit exe but that all of the Windows DLLs (advapi32.dll etc.) are linked as 64 bit DLLs. It seems as though this would be a link time error but apparently not.
On Machine B, everything compiles and runs correctly. Depends.exe confirms that the exe and all linked DLLs are 32-bit.
My Qt project is configured as follows:
qmake: qmake.exe PROJECT.pro -r -spec win32-msvc2010 "CONFIG+=declarative_debug"
I believe the -spec win32-msvc2010 part is sufficient to specify a 32 bit build.
The project file explicitly links to the Windows import lib files located in:
C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Lib
I have confirmed these are 32 bit import libs. An explicit LIB+= line in the project file calls out this path. If this line is removed from the project file, the link succeeds anyway. So I am not sure how the location of the Windows system import libs is specified in that case.
I verified with dumpbin that import .libs are tagged as either 32 or 64 bit. We are specifiying locations with 32 import libs.
Because one machine works and another doesn't, I believe the problem is one of machine configuration. Therefore, I removed and re-installed the MS tools from Machine A:
Uninstalled VS2010, Windows 8 SDK, .NET Framework 4.5, QT Libraries and QtCreator.
Reinstalled all of the above, in this order:
VS2010
VS2010 SP1
.NET Framework 4.5
Windows 8 SDK
Qt Libraries 4.8.4
QtCreator 2.7.1
I still get a 32 bit exe linked to 64 bit DLLs.
What could be causing the strange linking? And/or how can I determine more precisely why it thinks it should link to 64 bit DLLs?
It is not.
Answer from question text:
This is all essentially bogus. It turns out the version of Depends.exe
on the machine where the application runs was the 32 bit version. Upon
fixing that, both machines show the system DLLs as 64bit, so that is
not the source of the problem.
Ultimately the problem was one 64 bit DLL. This was easier to find
after using the correct version of Dependency Walker. Selecting the 32
vs 64 bit version is not based on the platform you're running on. From
the FAQ:
Dependency Walker will work with any 32-bit or 64-bit Windows module.
There are 32-bit and 64-bit versions Dependency Walker. All versions
are capable or opening 32-bit and 64-bit modules. However, there are
major advantages to using the 32-bit Dependency Walker to process
32-bit modules and the 64-bit Dependency Walker to process 64-bit
modules. This is especially true when running on a 64-bit version of
Windows, which allows execution of both 32-bit and 64-bit programs.
The 32-bit subsystem on 64-bit Windows (known as "WOW64") has its own
private registry, "AppPaths", "KnownDlls", system folders, and
manifest processing. Only the 32-bit version of Dependency Walker can
access this 32-bit environment, which is needed to accurately process
a 32-bit module. Likewise, only the 64-bit version of Dependency
Walker can fully access the 64-bit environment, so it should always be
used for processing 64-bit modules.
I have a COM component which I wish to deploy in a 64bit environment. There are multiple applications using this COM component. Some of these applications are 32-bit and others are 64-bit.
So while creating an installer, I which to bundle both the 32-bit and 64-bit versions of my COM dll.
In my first attempt, while building the installer project, I get a lot of warnings:
Ex. WARNING: Two or more objects have the same target location ('[payload_ul]\msvcp90.dll')
The warnings above are to do with merge modules. I have checked, but no multiple merge modules are present.
Also while the projects compiles successfully though with the warnings, while testing I found that the 64 bit module had failed to register.
The MSI was marked for x64 platform.
Can anyone provide pointers for the correct way to do this?
MSI doesn't support mixed x86 and x64 installers (check out this blog: http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx ). There are ways to "workaround" it, but eventually you will be bitten one way or another.
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.