asked on

LoadLibrary fails

I have a .EXE which depends on DLL A. The .EXE uses LoadLibrary to load DLL B, which also depends on DLL A. The LoadLibrary call on DLL B failes, reporting "invalid access to memory location" in its static initializer. The static initializer for DLL B is using static data from DLL A, and fails whether trying to assign to that static data or invoke a method which likely also modifies the static data.

This application is *not* using MFC or MFC shared libs.

How can I fix this? What's causing the memory fault?

NickRepin

So you export the data, not functions only, from the A?
Could you show the code related to the static data?

twall

ASKER

Yes, both data and functions are exported from A.

Here's the static declaration, from DLL A:

namespace NS { vector<CORBA::Narrow_proto> * BasicType::_narrow_helpers; };

Here's the access, from DLL B:

struct _global_init_MYPLUGIN_DerivedType {
_global_init_MYPLUGIN_DerivedType()
{
vector<CORBA::Narrow_proto>* vec = ::NS::BasicType::_narrow_helpers;
if( vec == NULL )
vec = ::NS::BasicType::_narrow_helpers = new vector<CORBA::Narrow_proto>;
vec->push_back( MYPLUGIN::DerivedType::_narrow_helper2 );
}
} __global_init_MYPLUGIN_DerivedType;

NickRepin

Probably it would be easier to use the function thunks, but not to export the data directly.

Like this

A:

__declspec(dllexport) void SetNarrowHelpers(p)
{
::NS::BasicType::_narrow_helpers=p;
}

__declspec(dllexport) HelperType GetNarrowHelpers(p)
{
return ::NS::BasicType::_narrow_helpers;
}

twall

ASKER

Maybe, except that the code is auto-generated (by the CORBA IDL compiler). Is there something inherently wrong with data access from DLL to DLL? Obviously the data access works from .EXE to DLL.

NickRepin

Hard to say. Probably, the problem is as follows.

The .h file [may be] declares the static data differently for EXE (as imported) and DLL (as exported).

It is correct as long as you use this header in the EXE and in the DLL that exports the data (A).

But for B.DLL, the data must be declared as IMPORTED as well, but not as exported (the header file may detect that it is compiled in DLL mode and make the data exported).

NickRepin

BTW, do you think that it's twice easier to answer your question in this area than in the C++ one?

twall

ASKER

Adjusted points from 100 to 200

twall

ASKER

We are generating .DEF files that indicate all the exports. DLL B gets its class definitions from the original class header file, which has no declspecs in it.

twall

ASKER

Wrapping the static data in static functions results in the same memory fault when trying to set the vector.

NickRepin

What is the .DEF file you use?

ASKER CERTIFIED SOLUTION

NickRepin

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

twall

ASKER

And the answer is:

The .DEF file *does not* require "DATA" after all the data members being exported.

DLL B *does* require that the headers that it uses for DLL A use __declspec(dllimport) in order to access the data correctly.

Thanks, Nick.

twall

ASKER

The second reference indicates part of what is necessary.

DATA is not required in the .DEF file.
__declspec(dllimport) *is* required in the headers from DLL A which are used by DLL B.

Thank you Nick.