I downloaded zlib and compiled the library as both Windows 32-bit and Windows 64-bit dll. I now have zlibwapi.dll and zlibwapi64.dll.
The dlls are copied into my application folder and are referenced as follows:
[DllImport(#"zlibwapi.dll", EntryPoint = "uncompress", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = false)]
private static extern int uncompress32(
IntPtr dest,
ref uint destLen,
[In(), MarshalAs(UnmanagedType.LPArray)] byte[] source,
uint sourceLen
);
[DllImport(#"zlibwapi64.dll", EntryPoint = "uncompress", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = false)]
private static extern int uncompress64(
IntPtr dest,
ref uint destLen,
[In(), MarshalAs(UnmanagedType.LPArray)] byte[] source,
uint sourceLen
);
At runtime I check whether I'm 32-bit or 64-bit, and call appropriate version.
This works fine if I'm 32-bit, but the 64-bit version gives
Cannot load DLL "zlibwapi64.dll": Module not found. (HRESULT exception: 0x8007007E)
I've found many similar questions on the Internet, and the suggested reason was that the library depends on some other libraries, and it is those libraries that may not be found.
This does not seem to the case:
zlibwapi64.dll only depends on Kernel32.dll and MSVCR90.dll. I do have VS2008 C++ runtimes installed, both 32 and 64 bit.
When I try to load zlibwapi64.dll from a non-managed C++ application, it loads no problem. It is C# that fails to load it.
I have tried setting absolute path to the 64-bit dll, it does not help.
How do I make it work?
It is a fairly basic "file not found" kind of error, unfortunately it doesn't tell you explicitly what DLL it couldn't find. You already know about the issue with dependent DLLs. Note that you can avoid the irksome dependency on msvcr90.dll by compiling the code with /MT
You'll need to debug the problem and that requires getting insight in where it is looking for DLLs. One good tool is SysInternals' ProcMon utility, it shows you exactly where your program is looking for files. You should see it probing for the DLL, searching through the directories of the PATH and failing to find the file.
Unfortunately ProcMon is a bit chatty and has a habit of drowning you in the data. A more dedicated tool is GFlags.exe, a tool available from the Debugging Tools for Windows package. These days included with the Windows SDK. Stored in c:\program files (x86)\debugging tools for windows\gflags.exe after you installed it. You can turn on the "Show loader snaps" option. On later Windows versions, that tells the Windows loader to generate debugging messages when it is searching for DLLs. They'll appear in the Output window when you enable unmanaged debugging.
Try ProcMon first, much easier to get going.
And of course consider pure managed solutions so you are not fighting these kind of install problems. Good ones are DotNetZip and SharpZipLib, take their first google hit.
Another good tool for examining Dll dependencies is Dependency walker (depends). It looks at the file in a static way so a little easier than using process monitor.
http://www.dependencywalker.com/
Related
I have compiled and imported the GameNetworkingSockets library into the unity Plugins folder. When doing a standalone build on my pc and running it, everything works fine, but when running the build on another pc, the dll files are not found. I have confirmed that the dll libraries are included in the builds Data/plugins folder.
internal static class Native
{
private const string nativeLibrary = "GameNetworkingSockets";
[DllImport(nativeLibrary, CallingConvention = CallingConvention.Cdecl)]
internal static extern bool GameNetworkingSockets_Init(IntPtr identity, StringBuilder errorMessage);
}
I have tried moving the dlls into the root folder next to the executable
I have tried changing the minimal api to .net framework
The native Plugins are in the Plugins folder
Also, which is kind of wierd, the set resolution for the game (windowed) is not used on other computers. Thanks in advance and sorry for my bad english :)
Here is c++ dll code:
#include<stdlib.h>
#include "pch.h"
extern "C" _declspec(dllexport) int Add(int a, int b)
{
return a + b;
}
C# code, that i run in Visual Studio:
[DllImport(#"C:\Dll1.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
public static extern int Add(int port, int speed);
public static void Main()
{
int res = Add(8, 11);
Console.WriteLine(res);
}
No problems, output: 19
PowerShell code:
Add-Type -Name MyFunctions -Namespace Cpp #'
[DllImport(#"C:\Dll1.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
public static extern int Add(int port, int speed);
'#
[Cpp.MyFunctions]::Add(8, 11)
Output:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
But functions from user32.dll/kernel32.dll imports without any problems.
How to fix it?
Make sure that you are using 32 bit dll for 32 bit powershell process and 64 bit dll for 64 bit powershell process.
The error looks like as if you trying to load 32 bit dll into 64 bit process. Please note that .net applications compiled as "Any CPU" will run in 32 bit mode by default even on 64-bit operating system.
Update
If you have a sources for your dll, then you should recompile it for 64 bit environment and then import this 64-bit build.
If you need to execute PS script in a both 32- and 64-bit powerShell environments, then you should deploy two versions of dll and select the right one in runtime. I do not know how this can be done for PS, but for C# solution you can use #ifdef-based solution as described here: Using a 32bit or 64bit dll in C# DllImport
If you do not have sources for your dll, then all become complicated and I do not know any direct solution here. You can try to wrap your DLL in the 32-bit in-process (or even out-of-process) COM server (with help of C# or C++) and then use this server with New-Object. As I know, the Windows have special shims which allow to utilize 32-bit COM objects from 64-bit process and vice versa, but I am unsure if this will work for PS or not.
For build-in DLLs Windows has automatic file paths redirection from System32 to SysWOW64. So, when you requesting user32 import, you will get different user32 libraries depending on your process bitness. You can read more about this here: 64bit PowerShell calls the 32bit DLL
I my c# app I am trying to call into a Delphi DLL build as 64bit. I keep getting an error stating "An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B". I am running on a Windows 7 64 bit machine and have my C# project set to Any CPU.
API call
[DllImport("Cipher.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.ThisCall)]
public static extern void Encrypt(StringBuilder szPlainText, StringBuilder zCipherText);
Encrypt(plainString, encText);
If the Delphi DLL was build as 32bit this call works fine. Any ideas?
For some reason your app is not run as a 64-bit but rather a 32-bit process. If you need to do things like this, it's better to specify "x64" instead of "AnyCPU".
I'm trying to create an .sav file programmatically without having to use SPSS automation (the SPSS.BackendAPI library) in order to free up more SPSS licenses. I found this library at CodePlex that uses the 32-bit I/O module without requiring a license, which is good.
The problem is that I need to build the application as x64 in order to gain access to the extra addressable memory in my own application. Thus, I need to use the 64-bit libraries as well. Has anyone had luck using the 64-bit libraries in managed code?
You can use that library from CodePlex, but you'll have to modify it a bit to work with the spssio64.dll that's included with the I/O Module. In the SpssThinWrapper.cs file, you'll need to change the DLL that's being imported. You'll also have to change some of the entry points. To get the names of the entry points in the 64-bit DLL, you'll want to run dumpbin /exports spssio64.dll. If you do this you'll see that the the 64-bit and 32-bit entry points are basically the same, except that some of the 32-bit ones have an # sign and a number after them, whereas none of the 64-bit entry points do. Do change all of those along with the DLL in the DllImport attribute. For example:
[DllImport("spssio32.dll", EntryPoint="spssCloseAppend#4", CharSet=CharSet.Ansi, SetLastError=true, ExactSpelling=true)]
public static extern ReturnCode spssCloseAppend(int handle);
becomes
[DllImport("spssio64.dll", EntryPoint = "spssCloseAppend", CharSet = CharSet.Ansi, SetLastError = true, ExactSpelling = true)]
public static extern ReturnCode spssCloseAppend(int handle);
and so on.
After doing this you'll want to make sure you're using the correct DLLs. Copy the spssio64.dll, icudt32.dll, icuin32.dll, and icuuc32.dll from the win64 folder of the I/O Module into the Resources folder from the SPSS .NET library from CodePlex. This will overwrite the existing 32-bit dlls, so if you need both 32-bit and 64-bit you'll have to do something different, but it sounds like you just need 64-bit, so this should work.
As an example of how easy it is to create an .sav with this library:
using (SpssDataDocument spssDoc = SpssDataDocument.Create("test.sav")) {
SpssVariable v = new SpssNumericVariable();
v.Name = "gender";
v.Label = "What is your gender?";
v.ValueLabels.Add(1, "Male");
v.ValueLabels.Add(2, "Female");
doc.Variables.Add(v);
doc.CommitDictionary();
SpssCase c = doc.Cases.New();
c["gender"] = 1;
c.Commit();
}
The library handles all of the spss* calls for you, and makes sure they're in the right order and everything.
Why don't you just use the SPSS Statistics i/o dll available via the SPSS Community site (www.ibm.com/developerworks/spssdevcentral)? It is free and comes in 32 and 64 bit versions for all the supported SPSS platforms. It does not require an SPSS license.
I'm trying to install and run a 32 bit application on a Win7 x64 machine. The application is built as a Win32 app. It runs fine on 32 bit platforms. On the x64 machine it installs correctly in the Programs(x86) directory and runs fine until I make a call into a 32 bit dll. At that time I get the incorrect format error (0x8007000b) indicating it is trying to load the dll of the wrong bitness. Indeed it is trying to load the 64 bit dll from the System32 directory rather than the 32 bit version in the SystemWOW64 directory.
Another 32 bit application provided by the dll vendor runs correctly and it does load the 32 bit dll from the SystemWOW64 directory. I do not have source to their application to see how they are accessing the DLL.
I'm using the DllImport function as shown below to access the dll. Is there a way to decorate the DllImport calls to force it to load the 32 bit version?
Any thoughts appreciated.
Thanks, DP
public static class Micronas
{
[DllImport(#"UAC2.DLL")]
public static extern short UacBuildDeviceList(uint uFlags);
[DllImport(#"UAC2.DLL")]
public static extern short UacGetNumberOfDevices();
[DllImport(#"UAC2.DLL")]
public static extern uint UacGetFirstDevice();
[DllImport(#"UAC2.DLL")]
public static extern uint UacGetNextDevice(uint handle);
[DllImport(#"UAC2.DLL")]
public static extern uint UacSetXDFP(uint handle, short adr, uint data);
[DllImport(#"UAC2.DLL")]
public unsafe static extern uint UacGetXDFP(uint handle, short adr, IntPtr data);
}
Force your .exe to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86.
Avoid getting confused by the project's Platform setting, it doesn't actually have to match the real setting. Which is Project + Properties, Build tab, Platform Target. Bit of a mess there.
Since your post is tagged with C#, I'm assuming this is a .NET app. It's probably not being set 32-bit only. You can verify by running corflags.exe on it, and setting the 32-bit only flag on it with corflags /32bit+ myapp.exe. If that fixes it, you need to fix your solution/project to build as x86 instead of Any CPU.
In order to force the application to run in 32-bit mode on 64-bit platform you can set it in IIS application pool: in advanced settings set "Enable 32-bits applications" to TRUE.