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

Question

I need to use a third-party DLL in our main application. When I statically refer to the provided DLL, it works fine, and I can export the DLLs. But we do not want our main application to depend on this DLL at startup, so I tried to dynamically load the DLL when I needed it:

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

but it doesn’t work: the LoadLibrary function returns 0, and LastErrorcode returns 3221225616. Since I don’t know what I am doing wrong, I tried the same (on the same PC) encoded in c and it works: but what does it not work with delphi ?: I call the same LoadLibrary function in the same DLL!

When I track using ProcMon, I see that 3rdparty dll is loading, and third-party dependency dlls and dlls are also loading. Thus, windows, of course, detect DLLs. But somewhere this loading process fails: When I try to load the DLL from LoadLibraryEX using DONT_RESOLVE_DLL_REFERENCES or LOAD_LIBRARY_AS_DATAFILE, it also works (but I cannot refuse to call the necessary functions ...)

I have no ideas: I hope you guys can help me ...

thanks in adv. Christoph

Answer 1

It works?

 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 to be when Google requested it, is the result of an invalid floating point operation. Now it seems very technical; really, what happens when loading a library with floating point calculations? The floating point control word (CW) is a bit field where the bits determine how the processor should handle floating point errors; in fact, it is quite common that unexpected floating point errors can be resolved by changing one of these bits to 1 (which, by the way, is the default state). In another example, see this my question , in which I get a completely unexpected division by zero error, which is associated with the bit "div by zero" from the control word to 1.

Answer 2

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

Answer 3

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

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

Answer 4

I think you should inform 3rdparty.dll developers about an error in your DLL.

Answer 5

I know this is an old thread, but I ran into 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));