We Keep Coding

c# - using LoadLibrary returns 0 with Win32Error 193

I'm building a c# class library that calls third party DLLs supplied by a vendor we're working with. The vendors examples are all in vc++ and are running and working.
I'm trying to load one of the DLLs and it's returning an IntPtr 0. When I call Marshal.GetLastWin32Error() I get 193 which from what I've read means that I'm trying to load a 32-bit DLL in 64-bit app. But I checked again and again and both my class library is set to x86 and my console application that makes the call to that class library is set to x86.
I can successfully load other DLL files by the same vendor (which are also 32-bit).
This is my Native helper class:
class NativeHelper
{
[DllImport("kernel32.dll", EntryPoint = "LoadLibrary", SetLastError = true)]
public static extern IntPtr LoadLibrary(string dllToLoad);
[DllImport("kernel32.dll", EntryPoint = "LoadLibraryEx", SetLastError = true)]
public static extern IntPtr LoadLibraryEx(string dllToLoad, IntPtr hFile, LoadLibraryFlags flags);
[DllImport("kernel32.dll")]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);
[DllImport("kernel32.dll")]
public static extern bool FreeLibrary(IntPtr hModule);
[System.Flags]
public enum LoadLibraryFlags : uint
{
DONT_RESOLVE_DLL_REFERENCES = 0x00000001,
LOAD_IGNORE_CODE_AUTHZ_LEVEL = 0x00000010,
LOAD_LIBRARY_AS_DATAFILE = 0x00000002,
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE = 0x00000040,
LOAD_LIBRARY_AS_IMAGE_RESOURCE = 0x00000020,
LOAD_WITH_ALTERED_SEARCH_PATH = 0x00000008,
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR = 0x00000100,
LOAD_LIBRARY_SEARCH_SYSTEM32 = 0x00000800,
LOAD_LIBRARY_SEARCH_DEFAULT_DIRS = 0x00001000
}
}
And this is how I make the call:
IntPtr pDll = NativeHelper.LoadLibrary(#"dhplay.dll"); // returns 0
if (pDll == IntPtr.Zero)
{
var err = Marshal.GetLastWin32Error().ToString(); // returns 193
Console.WriteLine(err);
}
What am I missing here? If I'm running x86 why is that DLL not loaded and others do?
Edit (Additional information):
IntPtr.Size is 4
dumpbin returns 8664 machine (x64) - That means it's 64-bit? I checked for other DLL used and they are 8664 machine (x86)
As far as dependencies, it's working on a vc++ application on my machine.

If there is smoke, there is often fire. Some dll is probably x64 while your app is x32 (or the reverse).
Check in you app IntPtr.Size. 4 → x86, 32 bits, 8 → x64, 64 bits
If you use the Visual Studio Command Prompt, you should be able to use dumpbin. Do a dumpbin /headers yourdll.dll | more for your dlls. One of the first rows should be machine (...). In the (...) it should be written if it is x86 (so 32 bits) or x64 (so 64 bits)
To the second question, you can't in any way mix 32 and 64 bit dlls in a single process. Some programs "cheat" and create a secondary process with the correct bits to load the dlls and then do IPC (inter-process-communication) between the primary process and the secondary process to use the dll. Clearly it is complex.

App fails to find unmanaged dll when deployed

I am running a Web API Asp.Net 4.6 app running in Any CPU mode (though I've also tried this specifying x64) and it makes a call to an unmanaged x64 C dll. This works fine when running within Visual Studio (using default IIS Express settings) though I get Windows Error 126 (The specified module could not be found.) when I deploy to another server and run in IIS or IIS Express even though I am sure that the path to the DLL is correct. Is there something else I can try?
My Native Methods Wrapper:
public static class NativeMethods
{
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, SetLastError = true)]
public static extern IntPtr LoadLibrary(string dllToLoad);
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, SetLastError = true)]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);
[DllImport("kernel32.dll")]
public static extern bool FreeLibrary(IntPtr hModule);
[DllImport("kernel32.dll", CharSet = CharSet.Ansi)]
public static extern IntPtr GetModuleHandle(string lpModuleName);
[DllImport("kernel32.dll")]
public static extern uint GetLastError();
}
My Load DLL Method:
private static void LoadDll()
{
UnloadDLL(); //Unload the module first
if (string.IsNullOrEmpty(DllDirectory))
throw new ApplicationException("DPI DLL directory not specified.");
if (!File.Exists(DllPath))
throw new ApplicationException("Could not find DPI DLL.");
pDll = NativeMethods.LoadLibrary(DllPath);
//Fails Here
if (pDll == IntPtr.Zero)
throw new ApplicationException(string.Format("Failed to load library <{0}> (ErrorCode: {1})", DllPath, Marshal.GetLastWin32Error()));
}
Let me know if I can make anything else more clear, thanks!

Use Dependency Walker to get the list of module's dependencies (module with path DllPath). Also check do you need install Visual C++ Redistributable on the server.
By ikenread: Need to check unmanaged DLL compilation mode. If it compiled in Debug mode, it will be dependent on Debug versions of Visual C++ Redistributable dlls and they will be absent (most likely) on the production server.

C# pointer exceeds IntPtr limit

I'm trying to read a process's memory, but the address I would like to start reading from exceeds the IntPtr and UIntPtr limit.
[DllImport("kernel32.dll", EntryPoint = "ReadProcessMemory")]
private static extern bool ReadProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, [Out] byte[] lpBuffer, int dwSize, [Out] int lpNumberOfBytesRead);
ReadProcessMemory(ProcessHandle, (IntPtr)0x14EC7B38A, buffer, buffer.Length, bytesused);
Doing this produces a OverflowException exception even if I use a UIntPtr. I have tried using a ulong, but this produces an AccessViolationException exception. What other data type should I use?

Windows is a 64-bit OS. UInt is 64bits wide. I assume the problem is that your application is either built for 32bit or is built to "Prefer 32bit" (the Visual Studio defaults).
This answer has the details of the setting you want to change.

32-bit Java Accessibility on a 64-bit machine

I have a 32-bit app that makes use of Java Accessibility (WindowsAccessBridge-32.dll, via the Java Access Bridge), and works perfectly on a 32-bit machine, but fails on an x64 machine.
I believe I have tracked it down to one of the first calls after Windows_run:
getAccessibleContextFromHWND(hwnd, out vmId, out context)
defined as follows:
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("WindowsAccessBridge-32.dll", CallingConvention = CallingConvention.Cdecl)]
public extern static bool getAccessibleContextFromHWND(IntPtr hwnd, out Int32 vmID, out IntPtr acParent);
This call works fine on the 32-bit system, returning True, populating both vmId (with some 5-digit value, which), and context - whereas on the 64-bit system, it returns True, populates 'context', but returns '0' for vmId.
If I assume that 0 is valid (even though it's a random 5-digit number resembling a pointer on the 32-bit system), the next call still fails:
AccessibleContextInfo aci = new API.AccessibleContextInfo();
if (!getAccessibleContextInfo(vmId, context, ref aci))
throw new Exception();
where:
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("WindowsAccessBridge-32.dll", CallingConvention = CallingConvention.Cdecl)]
public extern static bool getAccessibleContextInfo(Int32 vmID, IntPtr ac, ref AccessibleContextInfo info);
(I'm omitting the AccessibleContextInfo struct for brevity, but I can provide it if necessary).
I know that the libraries are working, because both JavaMonkey and JavaFerret work correctly. Furthermore, call to isJavaWindow works, returning 'true', or 'false' as appropriate, and I am linking to the correct DLL (WindowsAccessBridge-32).
Can anyone suggest what may be wrong here?

It appears that the problem is in the type of AccessibilityContext:
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("WindowsAccessBridge-32.dll", CallingConvention = CallingConvention.Cdecl)]
public extern static bool getAccessibleContextFromHWND(IntPtr hwnd, out Int32 vmID, out IntPtr acParent);
AccessibilityContext (acParent above), which I had incorrectly mapped as an IntPtr, is actually an Int32 when using the "legacy" WindowsAccessBridge.dll library (used under x86), and an Int64 when using the WOW64 WindowsAccessBridge-32.dll library.
So the upshot is, the code has to differ between x86 and WOW x64, and must be compiled separately for each. I do this by #define'ing WOW64 during x64 builds, always referencing the Int64 methods, and using "shim" methods on x86:
#if WOW64 // using x64
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("WindowsAccessBridge-32.dll", CallingConvention = CallingConvention.Cdecl)]
public extern static bool getAccessibleContextFromHWND(IntPtr hwnd, out Int32 vmID, out Int64 acParent);
#else // using x86
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("WindowsAccessBridge.dll", EntryPoint = "getAccessibleContextFromHWND", CallingConvention = CallingConvention.Cdecl)]
private extern static bool _getAccessibleContextFromHWND(IntPtr hwnd, out Int32 vmID, out Int32 acParent);
public static bool getAccessibleContextFromHWND(IntPtr hwnd, out Int32 vmID, out Int64 acParent)
{
Int32 _acParent;
bool retVal = _getAccessibleContextFromHWND(hwnd, out vmID, out _acParent);
acParent = _acParent;
return retVal;
}
#endif

If your using a 64 bit JVM with a 32 bit version of the Java Access bridge it won't work correctly. You need a 64 bit version of the access bridge which has recently been released. see
http://blogs.oracle.com/korn/entry/java_access_bridge_v2_0
For instructions on installing a 32 bit copy of the access bridge for use with 32 bit JRE's under 64 bit windows see
http://www.travisroth.com/2009/07/03/java-access-bridge-and-64-bit-windows/

The call to 'initializeAccessBridge' REQUIRES you to have an active windows message pump.
Inside 'initializeAccessBridge', it (eventually) creates a hidden dialog window (using CreateDialog). Once the dialog is created, it performs a PostMessage with a registered message. The JavaVM side of the access bridge responds to this message, and posts back another message to the dialog that was created (it appears to be a 'hello' type handshake between your app and the java VM). As such, if your application doesn't have an active message pump, the return message from the JavaVM never gets received by your app.

LoadLibrary call from MVC application running in IIS

I'm having trouble executing this line of code in my MVC application:
IntPtr hModule = LoadLibrary(BondProbeSettings.AssemblyFilePath);
The problem is that hModule is always 0.
If I run the same code with the same value for BondProbeSettings.AssemblyFilePath but from a console application instead of the MVC app hModule is non-zero.
Are there any security issues I need to consider?
The signature for LoadLibrary is:
[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
static extern IntPtr LoadLibrary(string lpFileName);

Change the declaration to:
[DllImport("kernel32.dll", CharSet = CharSet.Auto), SetLastError = true)]
static extern IntPtr LoadLibrary(string lpFileName);
And your code to:
IntPtr hModule = LoadLibrary(BondProbeSettings.AssemblyFilePath);
if (hModule == IntPtr.Zero) throw new System.ComponentModel.Win32Exception();
Now you'll know why it doesn't work.

Yep you need to run the site assembly in full trust. I haven't configured this myself but I reckon you need:
to GAC the dll (meaning it has to be strongnamed)
to perhaps configure the application pool in IIS (assuming IIS) to allow full trust (?)
I'm on linux so I can't really help you with screenshots right now