DLL and GetProcAddress() Problem

I've been developing a real time Image processing with
QuickCam program.
There are mainly 4 files

RV2.exe(uses rvcommon.dll through import lib and using mfc in dll)

rvcommon.dll(uses mfc in dll the project generated with appwizard using MfcExtension using MFC in dll)

addon1.dll(uses rvcommon.dll through import lib the project generated with appwizard using regular dll using MFC in dll)

addon2.dll(uses rvcommon.dll through import lib the project generated with appwizard using regular dll using MFC in dll)


addon*.dll is where the image processing functions reside.
users can load and unload them at rumtime.

rv2.exe would load addon1.dll and addon2.dll at runtime
using AfxLoadLibrary();

The program works fine under debug build(VC++5.0 sp3).But When I do a release build the program causes GPF whenever there is GetProcAddress() api. I have verified that AfxLoadLibrary() return correct HINSTANCE.

Does anyone got any idea why??


thanks

psksvp@ccs.neu.edu
petersvpAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mnguyen021997Commented:
a lot of times people get confused with ASSERT() and VERIFY().  you wouldn't happen to be doing an

ASSERT(AfxLoadLibrary()) would you?? if so then switch it to VERIFY().  

also initialize your hinstance variable to null prior to calling afxloadlibrary.  unless msoft screwed up it shouldn't be crashing for a null hinstance but may crash for an invalid (random stack value) instance.
0
petersvpAuthor Commented:
The problem is not the AfxLoadLibrary(), I verified it, before
I call GetProcAddress(). GetProcAddress() causes GPF whenever
I call it in a release build. In debug build, my program
works perfectly..without any asserting...

anyhelp would be great

psksvp@ccs.neu.edu
0
JohnWeidnerCommented:
If you load the library with out a full path specification, it could be that there is an old copy of the DLL in the "release" directory that is being loaded.
0
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

dr_funfrockCommented:

  I think you need to use _AFXDLL define in your app or DLL.
0
petersvpAuthor Commented:
When I build(both debug and release), I always have all the
dll(s) and exe, put into a same dir, regradless of release
or debug build.. so there would be only one place where the    dll(s) could be.
0
dustinnCommented:
Can you post a code snippet of the GetProcAddress call that is causing the crash?  Also, include any pertinent code around that general area of the program (specifically, code that modifies any of the parameters to GetProcAddress).
0
petersvpAuthor Commented:
Is this can be the case, I pass and MFC-derived class to a
function in the DLL. I just read an article in KB that MFC app
cannot pass MFC-derived class to RegularDLL..

nayone has any idea, if this is true..
0
dustinnCommented:
In order to pass an MFC class between modules (EXE and DLL or DLL and DLL) you must create an MFC Extension DLL.  A normal DLL will not work.

If you are using VC++ 5.0, AppWizard can create a shell of an MFC Extension DLL for you.  An extension DLL requires certain #defines and other implementation specifics that a regular DLL doesn't.

Check out "Inside VC++" by David Kruglinski for an in-depth discussion of the differences between the two.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
petersvpAuthor Commented:
one last question before I go and fix my code.
If I call the MFC Extension DLL explicitly by using
AfxLoadLibrary(). Does the DLLMain() get called?
Or I need another export function that create
CDynLinkLibrary() ?
Thanks for all yoou helps
psksvp@ccs.neu.edu
0
dustinnCommented:
DllMain() will get called.  You should never have to play with the CDynLinkLibrary object that gets created by your DLL.  You should create the object in your DllMain() with a call to AfxInitExtensionModule() like so:

BOOL WINAPI DllMain(HMODULE hInst, ULONG uReason,
                    LPVOID lpvReserved)
{
    if (uReason == DLL_PROCESS_ATTACH)
    {
        if (!AfxInitExtensionModule(extMyExtension, hInst))
            return 0;
    }

    return 1;

}

And, if you are using AfxLoadLibrary() to load the DLL you should also add the following code to DllMain():

if (uReason == DLL_PROCESS_DETACH)
{
    AfxTermExtensionModule(extMyExtension)
}

This is not necessary, but recommended, otherwise the memory and resources allocated by your call to AfxInitExtensionModule() will not be freed until the calling executable terminates.

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.