DLL in working directory fails to load after invoking Crystal Reports components

A DLL in the OpenEdge client's working directory fails to load with error "Could not load DLL procedure <procedure>. (3258)", if before calling the DLL function the Crystal Reports Engine was called via .NET interface.

May 4, 2016
Knowledge

Title

URL Name

DLL-in-working-directory-fails-to-load-after-invoking-Crystal-Reports-components

Article Number

000185284

Environment

Product: OpenEdge Version: 11.x OS: Windows Other: Crystal Reports runtime engine

Question/Problem Description

OpenEdge-based application relies on several external components, including Crystal Reports engine and self-built DLLs
Self-built DLLs are deployed in session's working directory
ABL code sets up entry points using relative pathnames in the PROCEDURE <function> EXTERNAL "<dll name>" declaration

After Crystal Reports engine gets invoked, the DLLs in the working directory are no longer recognised
Trying to invoke DLL functions fails with "Could not load DLL procedure <procedure>. (3258)"

Steps to Reproduce

Clarifying Information

Using absolute pathnames in the PROCEDURE <function> EXTERNAL "<dll name>" declaration avoids the issue, but is not a valid workaround as it's too restrictive when deploying to different sites (or even different machines on same site)

Error Message

Could not load DLL procedure <procedure>. (3258)

Defect Number

Enhancement Number

Cause

The root cause of this issue lies within the Crystal Reports components:
At some point, Crystal Reports code calls SetDllDirectoryW to add a directory to the DLL search path, and later removes it by calling SetDllDirectoryW("") -> using an empty string. It should pass in a NULL pointer instead when resetting the search path.

According to the documentation for SetDllDirectory (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx):

lpPathName [in, optional]
The directory to be added to the search path. If this parameter is an empty string (""), the call removes the current directory from the default DLL search order. If this parameter is NULL, the function restores the default search order.

So passing the empty string will not fully reset the search path to what it was before they changed it. As result when the OpenEdge AVM regains control the search path is no longer what it expects to be.

Resolution

As workaround for the 3rd-party issue:
In the ABL code, after the program is done with the Crystal Rports Engine, invoke the SetDllDirectory API with a NULL pointer within the ABL code.

Sample code that calls the API:

PROCEDURE ResetDLLpath:
  DEFINE VARIABLE hCall AS HANDLE NO-UNDO.

  CREATE CALL hCall.
  ASSIGN
    hCall:CALL-NAME      = "SetDllDirectoryW":U 
    hCall:LIBRARY        = "kernel32.dll":U
    hCall:CALL-TYPE      = DLL-CALL-TYPE
    hCall:NUM-PARAMETERS = 1.

  /* API expects pointer to character, pass NULL pointer (= pointer with address 0)
     to reset path. */
  hCall:SET-PARAMETER(1, "LONG", "INPUT", 0). 
  hCall:INVOKE( ).
  
  DELETE OBJECT hCall.
END.

Workaround

Notes

Issue is confirmed to exist in the Crystal Reports runtime versions 13.0.0.x through 13.0.16.1954 (current version at the time of this writing)

Keyword Phrase

Last Modified Date

5/4/2016 1:29 PM

DLL in working directory fails to load after invoking Crystal Reports components

Files(0)

Was this article helpful?

Was this article helpful?

DLL in working directory fails to load after invoking Crystal Reports components

Information

Related Articles