LoadLibrary not working on Vista64?

[Peter Morris]

I have a class named DynamicLinkLibrary which does this:

[DllImport("kernel32.dll")]
private static extern IntPtr LoadLibrary(string fileName);

protected virtual void Load(string fileName)
{
EnsureNotDisposed();
if (LibraryHandle != IntPtr.Zero)
throw new InvalidOperationException("Library already loaded");
if (string.IsNullOrEmpty(fileName))
throw new ArgumentNullException(fileName);

LibraryHandle = LoadLibrary(fileName);
if (LibraryHandle == IntPtr.Zero)
throw new InvalidOperationException("Invalid DLL file name: " +
fileName);
FileName = fileName;
}


In WinXP this works fine, however, when I run it on Vista the result of
LoadLibrary is always IntPtr.Zero. Using a relative path (same folder) or
absolute path makes no difference. Can anyone help? This is stopping me
from migrating an app to Vista!


Thanks


Pete

 

[Willy Denoyette [MVP]]

I have a class named DynamicLinkLibrary which does this:

[DllImport("kernel32.dll")]
private static extern IntPtr LoadLibrary(string fileName);

protected virtual void Load(string fileName)
{
EnsureNotDisposed();
if (LibraryHandle != IntPtr.Zero)
throw new InvalidOperationException("Library already loaded");
if (string.IsNullOrEmpty(fileName))
throw new ArgumentNullException(fileName);

LibraryHandle = LoadLibrary(fileName);
if (LibraryHandle == IntPtr.Zero)
throw new InvalidOperationException("Invalid DLL file name: " +
fileName);
FileName = fileName;
}


In WinXP this works fine, however, when I run it on Vista the result of
LoadLibrary is always IntPtr.Zero. Using a relative path (same folder) or
absolute path makes no difference. Can anyone help? This is stopping me
from migrating an app to Vista!


Thanks


Pete

If you're trying to load a 32bit library, you'll need to target the "X86
platform" when compiling your code.

Note that you should check your error code when the LoadLibrary API call
fails.

[DllImport("kernel32.dll"), SetLastError=true]
....


If (LibraryHandle == IntPtr.Zero)
// Call Marshal.GetLastWin32Error to get the win32 error code.

Willy.

 

[Peter Morris]

Hi Willy

Thanks for the answer!

I didn't know that I cannot use LoadLibraryEx in Win64 to load a 32 bit dll!
This is how my app is structured, each project depends upon the one above:

DynamicLinkLibrary in DynamicLinkLibrary.dll
FortranDynamicLinkLibrary in FortranDynamicLinkLibrary.dll
MySpecificDLL in MySpecificDLL.dll (dynamically loads 3rdparty.dll)
MyApp.exe

I've now set the Target Platform of MyApp.exe to x86 and it works perfectly.
Are there any negative points to doing this?



Thanks very much for your help, I really appreciate it!


Pete

 

[Willy Denoyette [MVP]]

Hi Willy

Thanks for the answer!

I didn't know that I cannot use LoadLibraryEx in Win64 to load a 32 bit
dll! This is how my app is structured, each project depends upon the one
above:

You can not load a 32bit DLL into a 64bit process. A Managed application
built with AnyCPU (MSIL) as target, will load the 64bit CLR and as such run
as a 64bit process.

DynamicLinkLibrary in DynamicLinkLibrary.dll
FortranDynamicLinkLibrary in FortranDynamicLinkLibrary.dll
MySpecificDLL in MySpecificDLL.dll (dynamically loads 3rdparty.dll)
MyApp.exe

I've now set the Target Platform of MyApp.exe to x86 and it works
perfectly. Are there any negative points to doing this?

No, your program runs as a 32bit process under Wow64 on 64bit Windows. The
performance impact of the transition into the 64bit kernel is extremely low,
and is completely compensated by the lower CPU cache pressure.
That means that your code in general runs as fast as it would be compiled as
64 bit.

Willy.

 

[Peter Morris]

Excellent, thankyou so much for your help!