Multiple loaded DLL problem
-
Hey! Some background first: I've written an app that has a plugin system. Each plugin contains a CDialog. I enumerate all the plugin dll's in a certain folder and init each one, storing their HMODULE handles and other information in an array. Each plugin has an item in the "plugin" menu and a check marks weather the a certain plugin is activated. All of this works great and I have no problems with it. The problem comes from when I want to shutdown one of the plugins. Depending on the order the plugins were loaded, if I shut down one plugin, it does so properly, but all the others dissapear. The other plugins don't get shutdown, their HWND becomes NULL and consequently, their windows vanish. I've traced the code to the point where this all happens, and a FreeLibrary() call seems to be the culprit. As soon as that function is called with the HMODULE of the plugin I want to free, all the others dissapear. Now I do have functions in each plugin that free memory and things like that, but as a rule plugins don't know anything about each other. They should be self-contained ie one plugin shouldn't be able to affect another. That's why I think that there might be some weird stuff happening deep down in MFC or Windows, but I have no idea what. Any suggestions? Steve The Plant
-
Hey! Some background first: I've written an app that has a plugin system. Each plugin contains a CDialog. I enumerate all the plugin dll's in a certain folder and init each one, storing their HMODULE handles and other information in an array. Each plugin has an item in the "plugin" menu and a check marks weather the a certain plugin is activated. All of this works great and I have no problems with it. The problem comes from when I want to shutdown one of the plugins. Depending on the order the plugins were loaded, if I shut down one plugin, it does so properly, but all the others dissapear. The other plugins don't get shutdown, their HWND becomes NULL and consequently, their windows vanish. I've traced the code to the point where this all happens, and a FreeLibrary() call seems to be the culprit. As soon as that function is called with the HMODULE of the plugin I want to free, all the others dissapear. Now I do have functions in each plugin that free memory and things like that, but as a rule plugins don't know anything about each other. They should be self-contained ie one plugin shouldn't be able to affect another. That's why I think that there might be some weird stuff happening deep down in MFC or Windows, but I have no idea what. Any suggestions? Steve The Plant
I have a similar type system for one of my apps although I do not dynamically unload them until the app ends. I would check to see whether its a particular DLL which always causes the problem. Try renaming them so they get loaded in a different order in your app. If the same DLL always causes the problem check to see whether its corrupting memory somehow in your main app. Roger Allen Sonork 100.10016 If I'm not breathing, I'm either dead or holding my breath.
-
I have a similar type system for one of my apps although I do not dynamically unload them until the app ends. I would check to see whether its a particular DLL which always causes the problem. Try renaming them so they get loaded in a different order in your app. If the same DLL always causes the problem check to see whether its corrupting memory somehow in your main app. Roger Allen Sonork 100.10016 If I'm not breathing, I'm either dead or holding my breath.
I've done what you suggested, and It doesn't look like its a particular DLL. I've had them loaded in a different order and the problem persists. Here's another explanation of the problem. Let's say my app loaded four dlls, plugin01 to plugin04. Plugin01 being the first one loaded, plugin02 the second and so on. If I shutdown plugin01, then the other three dissapear. But if I shutdown plugin02, 3 and 4 dissapear but not 1. If I shutdown plugin03, plugin04 dissapears, but not 1 or 2. It doesn't matter which plugins get loaded, a loaded plugin always knocks out the ones loaded after it when shutdown. It's weird. I'm only doing one call to FreeLibrary and I'm passing the HMODULE of the plugin I want to shutdown. But, if all the plugins are loaded, and I shutdown and restart the plugins in the reverse order (4, then 3, etc.) the problem dissapears and I can shutdown and activate plugins at will properly without affecting others. Putting breakpoints in the exit functions (DestroyWindow, ExitInstance, etc.) of the other plugins doesn't work. It doesn't seem that those functions are called when they accidentally dissapear. Steve The Plant
-
I've done what you suggested, and It doesn't look like its a particular DLL. I've had them loaded in a different order and the problem persists. Here's another explanation of the problem. Let's say my app loaded four dlls, plugin01 to plugin04. Plugin01 being the first one loaded, plugin02 the second and so on. If I shutdown plugin01, then the other three dissapear. But if I shutdown plugin02, 3 and 4 dissapear but not 1. If I shutdown plugin03, plugin04 dissapears, but not 1 or 2. It doesn't matter which plugins get loaded, a loaded plugin always knocks out the ones loaded after it when shutdown. It's weird. I'm only doing one call to FreeLibrary and I'm passing the HMODULE of the plugin I want to shutdown. But, if all the plugins are loaded, and I shutdown and restart the plugins in the reverse order (4, then 3, etc.) the problem dissapears and I can shutdown and activate plugins at will properly without affecting others. Putting breakpoints in the exit functions (DestroyWindow, ExitInstance, etc.) of the other plugins doesn't work. It doesn't seem that those functions are called when they accidentally dissapear. Steve The Plant
Do those DLLs do something weird at
DLL_PROCESS_ATTACHorDLL_PROCESS_ATTACHtime, like loading another libraries? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -
I'm not sure. They could very well be. I created those DLLs through the MFC DLL Wizard. DllMain is hidden from me, so I don't know exactly what it's doing. Steve The Plant
If you used the MFC Wizard, that part should be OK. (Wild guessing) Try statically linking MFC (if your DLLs and app used it as a shared DLL). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Do those DLLs do something weird at
DLL_PROCESS_ATTACHorDLL_PROCESS_ATTACHtime, like loading another libraries? Joaquín M López Muñoz Telefónica, Investigación y DesarrolloI'm not sure. They could very well be. I created those DLLs through the MFC DLL Wizard. DllMain is hidden from me, so I don't know exactly what it's doing. Steve The Plant
-
I've done what you suggested, and It doesn't look like its a particular DLL. I've had them loaded in a different order and the problem persists. Here's another explanation of the problem. Let's say my app loaded four dlls, plugin01 to plugin04. Plugin01 being the first one loaded, plugin02 the second and so on. If I shutdown plugin01, then the other three dissapear. But if I shutdown plugin02, 3 and 4 dissapear but not 1. If I shutdown plugin03, plugin04 dissapears, but not 1 or 2. It doesn't matter which plugins get loaded, a loaded plugin always knocks out the ones loaded after it when shutdown. It's weird. I'm only doing one call to FreeLibrary and I'm passing the HMODULE of the plugin I want to shutdown. But, if all the plugins are loaded, and I shutdown and restart the plugins in the reverse order (4, then 3, etc.) the problem dissapears and I can shutdown and activate plugins at will properly without affecting others. Putting breakpoints in the exit functions (DestroyWindow, ExitInstance, etc.) of the other plugins doesn't work. It doesn't seem that those functions are called when they accidentally dissapear. Steve The Plant
Would you be able to post your code for loading and releasing the DLL's. What you are describing sounds weird. The only other things I can think off that would possibly affect you are that because they are extension DLL's they get loaded/released together, or the base address's of the dlls (set in the linker tab of settings) are clashing somehow. Roger Allen Sonork 100.10016 If I'm not breathing, I'm either dead or holding my breath.