• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

vc++ afxloadlibrary

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).
 
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.
 
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?

 
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.
 
Back
Top