Delphi app: accessing WOW64 version of activeds.dll causes app crash 1

[DanielBragg]

We have a Delphi app that performs user authentication using the activeds.dll library. However, when running on a 64-bit server, even though the WOW64 processing thunks the library to use the psuedo-32-bit version, we're consistently getting an app crash when attempting to use the library.

Any helpful suggestions?

Thanks

 

[Glenn9999]

How are you loading the library?

What functions produce this "app crash"?

How is the app crashing? What messages and so on?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[DanielBragg]

Thanks, Glenn, for the reply.

My call that goes "crunch" is the call to IADsOpenDSObject:

var
  Protocol : string;
  DispPtr : pointer;
  OpenDS : IADsOpenDSObject;
begin
Protocol := 'LDAP';
ADsGetObject(Protocol, IADsOpenDSObject, DispPtr);
if assigned(DispPtr) then
   OpenDS := IADsOpenDSObject(DispPtr);
end;

(This is a cut-and-paste of the routine I'm using, so the Protocol may be LDAP or LDAP:, I don't remember at the moment. It works using activeds.dll v6.0 and v5.1, so it's which ever version that should work.)

Both of IADsOpenDSObject and ADsGetObject are declared in JwaActiveDS.pas, which is the JEDI Active Directory Services API interface Unit for Object Pascal. My copy is dated Nov 23, 2009. It is this Unit which makes the call to the activeds.dll library. The routines are defined as follows:

// *********************************************************************//
// Interface: IADsOpenDSObject
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {DDF2891E-0F9C-11D0-8AD4-00C04FD8D503}
// *********************************************************************//
  IADsOpenDSObject = interface(IDispatch)
    ['{DDF2891E-0F9C-11D0-8AD4-00C04FD8D503}']
    function  OpenDSObject(const lpszDNName: WideString; const lpszUserName: WideString; 
                           const lpszPassword: WideString; lnReserved: Integer): IDispatch; safecall;
  end;

{$IFDEF DYNAMIC_LINK}
var
  _ADsGetObject: Pointer;

function ADsGetObject;
begin
  GetProcedureAddress(_ADsGetObject, adslib, 'ADsGetObject');
  asm
    mov esp, ebp
    pop ebp
    jmp [_ADsGetObject]
  end;
end;
{$ELSE}
function ADsGetObject; external adslib name 'ADsGetObject';
{$ENDIF DYNAMIC_LINK}

The conditional defines are set to use DYNAMIC_LINK at the moment.

When the app crashes, it returns an error from KERNEL.DLL. I would copy the entire error here, but unfortunately, I haven't received the dump from the user yet, as I remote into their server to perform the tests, but I cannot copy files directly from their server.

I'll reply with more detail when I get it. Thanks _very_much_ for any assistance you can offer us.

:-D Daniel

 

[Glenn9999]

How does it work right when the conditional is not DYNAMIC_LINK?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[DanielBragg]

Glenn9999:

Well, I'm 100% certain that before, one of my first steps was to disable DYNAMIC_LINK and recompile, but it seems that I had not recompiled enough of the library to make a difference (I didn't want to ship a copy of _everything_ to the customer just for debugging). However, I tried it again, found out what actually needed to be recompiled, shipped _only_ that, and that did the trick. Seems that the 64-bit Windows 2008 Server R2 simply doesn't like to dynamically link the libraries in the same way as Windows 95 did. Go figure.

Thanks for the encouragement to try again.

:-Daniel

 

[Glenn9999]

Seems that the 64-bit Windows 2008 Server R2 simply doesn't like to dynamically link the libraries in the same way as Windows 95 did. Go figure.

Actually, it's probably because the people that did the JEDI library did something non-standard with their code that doesn't translate well on the 64-bit thunking agent. Hard to tell something for sure without having debugged it, but this is most likely given what you have written. Something "different" may work fine when you test it, but may not work well in all cases.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.