vc++ afxloadlibrary

neegotiator

Golden Member
Jan 19, 2006
1,117
1
0
any way I can check reference count on a dll i load using afxloadlibrary in vc++? didn't find anything on google.
 

programmer

Senior member
Mar 12, 2003
412
0
0
Just curious, but can you explain why you would need the reference count? But in answer to your question, no there is no API to get the ref count. You'll need to add a static member var to your process/class/file (depending on where the load/unload occurs). Just ++ each time you successfully call AfxLoadLibrary and -- each time you call AfxFreeLibrary to keep track of it.

From the Visual C++ Developer Center
"Each process maintains a reference count for each loaded library module. This reference count is incremented each time AfxLoadLibrary is called and is decremented each time AfxFreeLibrary is called. When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid."

A real problem can occur if you mismanage the calls to Load/Free by Free'ing more than you've Loaded -- in which case the runtime may unload the module. You still might be holding a handle (now invalid) and when you make a call -- kaboom, process is dead (Access Violation).
 

neegotiator

Golden Member
Jan 19, 2006
1,117
1
0
Originally posted by: programmer
Just curious, but can you explain why you would need the reference count? But in answer to your question, no there is no API to get the ref count. You'll need to add a static member var to your process/class/file (depending on where the load/unload occurs). Just ++ each time you successfully call AfxLoadLibrary and -- each time you call AfxFreeLibrary to keep track of it.

From the Visual C++ Developer Center
"Each process maintains a reference count for each loaded library module. This reference count is incremented each time AfxLoadLibrary is called and is decremented each time AfxFreeLibrary is called. When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid."

A real problem can occur if you mismanage the calls to Load/Free by Free'ing more than you've Loaded -- in which case the runtime may unload the module. You still might be holding a handle (now invalid) and when you make a call -- kaboom, process is dead (Access Violation).


Something like that. I'm breaking in class where I'm loading the DLL, and I seem to be freeing for every load I do. When that class is instantiated again, I'm getting back the same handle I thought I previously unloaded, try to load that invalidated handle and crash, as opposed to the DLL being unloaded and getting a new handle. I just wanted to view refcount just for sanity check. Not sure how I'd be getting back that old handle, I guess there's some process/thread out there still holding on to it.
 

programmer

Senior member
Mar 12, 2003
412
0
0
If the module is already loaded, subsequent calls to LoadLibrary/AfxLoadLibrary will return the handle each time, bumping the refcount. The issue with ref count hitting zero is you never know when, and have no control over if or when, the module *may* unload from the process.

Best thing is to control this yourself. Not knowing your application or class, I cannot comment on when and how to do this, but if this module is often used, its usually just best to load it and keep it (before the class is instantiated)--then use GetModuleHandle/GetModuleHandleEx instead within the class. If its only used by instances of this class, and that is not often, then the class should load/unload.

See
http://msdn2.microsoft.com/en-...y/ms683199(VS.85).aspx

Also, do you cache the handle in a var? Or always call the API for it?

 

neegotiator

Golden Member
Jan 19, 2006
1,117
1
0
Not sure if that's possible in my situation (loading DLL before class instantiation and grabbing handle) but worth looking into. Thanks for the suggestion.

Yeah I assumed that refcount hitting 0 meant unloading the DLL, but I guess that just means the handle is invalidated and not actually unloaded. Guess I might try running a handle stack trace in windbg to see if I can find something still holding onto it.

Each instance of class will call API then cache in var.