Delphi Loadlibrary returns 0 (LastErrorcde=3221225616) What does this mean?

Question

I need to use a 3rd party dll in our main app. When I staticly link to the provided DLL it works ok and I can the DLLs exported functions. But we don't want our main app dependend on this dll on startup so I tried to dynamicly load the DLL when I need it :

DLLHandle := LoadLibrary('3rdparty.dll');
ret := GetLastError();
if DLLHandle = 0 then
begin
  err := SysErrorMessage(ret);
  Writeln(err);
end //...

but did doesnt work : The LoadLibrary function returns 0 and the LastErrorcode is 3221225616. Because I don't know what I'm doing wrong I tried the same (on the same pc) coded in c and it works : but what doesn't it work with delphi ? : I call the same LoadLibrary function on the same dll!

When I monitor with ProcMon I see that the 3rdparty dll gets loaded and that also the dependand dlls of the 3rdparty dll gets loaded. : So windows certainly finds the DLL. But somewhere it the loading process it fails : When I try to load the DLL with LoadLibraryEX with DONT_RESOLVE_DLL_REFERENCES or LOAD_LIBRARY_AS_DATAFILE it also works (but I can't offcourse call the needed functions...)

I'm out of ideas : hope you guys can help me further...

thx in adv. Kristof

Answer 1

Does this work?

var
  SavedCW: word;

...

SavedCW := Get8087CW;
Set8087CW(SavedCW or $7);
DLLHandle := LoadLibrary('3rdparty.dll');
Set8087CW(SavedCW);
if DLLHandle = 0 then
begin
  ret := GetLastError();  
  err := SysErrorMessage(ret);
  Writeln(err);
end //...

Some discussion:

The error code, 3221225616, seems, when asking Google, to be the result of an invalid floating point operation. Now, this seems very technical; indeed, what does loading a library have to do with floating point computations? The floating point control word (CW) is a bitfield where the bits specify how the processor should handle floating-point errors; it is actually rather common that unexpected floating point errors can be dealt with by changing one of these bits to 1 (which by the way is the default state). For an other example, see this question of mine, in which I get a totally unexpected division by zero error, which is dealt with by setting the "div by zero" bit of the control word to 1.

Answer 2

3221225616 = STATUS_FLOAT_INVALID_OPERATION. My wild guess is that the FPU CW is different in your Delphi and C apps, and that your DLL's initialization is sensitive to this.

Answer 3

Possibly related: http://discuss.joelonsoftware.com/default.asp?joel.3.88583.15

Try using SafeLoadLibrary() in the Delphi RTL instead of the Win32 LoadLibrary. This function preserves the FP control word before calling LoadLibrary, and sets it back to what Delphi wants after the LoadLibrary returns.

Answer 4

I think that you should report to 3rdparty.dll's developers about a bug in their DLL.

Answer 5

I know this is an old thread but I just came across the same problem with a DLL written in VB.

This solution works for both x86 and x64

var  ret:cardinal;
     em:TArithmeticExceptionMask;
begin
  result:= 1;
  If Lib <> 0 Then exit;     // already loaded
  em:=GetExceptionmask;
  SetExceptionmask(em+[exInvalidOp,exZeroDivide,exOverflow, exUnderflow]);
  Lib := LoadLibrary(DLLname);
  SetExceptionmask(em);
  ret := GetLastError;
  if ret<>0 then
    raise exception.create(SysErrorMessage(ret));