- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a couple of fortran dll's (Intel® Parallel Studio XE 2016 Update 1 Composer Edition for Fortran Windows) that get loaded into a c++ program. After they're done I'd like to unload the dll's. One of them unloads fine. The other won't. Even if I put the whole operation on a separate thread, doing the FreeLibrary and closing the thread, still leaves the one dll (and the dll's that it loads) attached to the process.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you read the MSDN description of FreeLibrary, it says that the call "decrements a reference count" and that the library isn't unloaded until the count goes to zero. The article has additional details that may be of interest. There's nothing particularly "sticky" about a Fortran DLL. Perhaps you have some other reference to it in the program. A call to GetModuleHandle before you call LoadLibrary would be instructive.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I was aware of this and have tried various things, like a loop to do multiple frees. I've watched when things get loaded in ProcessMonitor, and kept track of what dll's get loaded etc. so, I know it's only being loaded once.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does any part of the program link against this DLL? Does GetrModuleHandle return a handle to the DLL if you call it at the start of the program?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No. Previously at this point, the program launched what are now dll's as a separate process. But, for various reasons, we're trying to turn what was a program into dll's. But, I checked, and just before the load, GetModuleHandle returns a null.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you invoke FreeLibrary, does it return zero or nonzero? If zero, what does GetLastError say? If zero, have you tried zapping the DLL with UnmapViewOfFile?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FreeLibrary returns true. I've tried UnMapView of file, and the dll disappears from the process. But, then I get exceptions in other places. If I let the dll actually do what it's supposed to do, then even though all files have been explicitly closed, when I use UnMap, several files are still said to be owned by the process and I get an exception using the system routine DeleteDirectory.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried putting in a DllMain entry point that logs the load and unload? It would be interesting to see if the unload request comes through.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not entirely sure how I write a DllMain in fortran. Do I just do -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
function DllMain (hinstDLL, fdwReason, lpvReserved) bind(C,name="DllMain") use IFWINTY integer(BOOL) :: DllMain !DEC$ ATTRIBUTES STDCALL, DLLEXPORT :: DllMain integer(HANDLE), value, intent(IN) :: hinstDLL integer(DWORD), value, intent(IN) :: fdwReason integer(LPVOID), value, intent(IN) :: lpvReserved if (fdwReason == DLL_PROCESS_ATTACH) then ... Loaded else if (fdwReason == DLL_PROCESS_DETACH) then ... Unloaded end if DllMain = TRUE end function DllMain
You'll want to be careful with what you do in this procedure. No Fortran I/O, for example.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would appear that the unload request is never received. It logs the load, but not the unload.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That suggests to me there is an extra reference somewhere. I have no clue as to how to diagnose that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My mind is a little foggy on this, but I seem to recall there is an option (somewhere that escapes me) that you can set (or unset) that causes a pre-load of dependent libraries (IOW at program load time as opposed to at first call). Possibly this is inadvertently set.
Note, if this is set, then, the return stack from Process Attach may indicate that "main" (tmain, ...) is not on stack. ** caviat ** on C++ a static ctor,, which runs before main, may also affect the load. So you will have to discern this too.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried rebuilding the dll that uses these dll's, and things work in debug mode from inside visual studio. But, using the debug dll, or the release version, still doesn't work from outside of VS. One other thing, the dll that uses these is a COM dll. Can you think of a reason this would change things?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you do a COMINITIALIZE and COMUNINITIALIZE in the DLL? (Or is it not your DLL?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I call OleInitialize. Just to make things weirder, if I start the main program, that uses the com dll, to a different folder, things run ok. I checked what's loaded in each instance from process explorer. When I launch from the folder that fails, the process loads userenv.dll and ACGeneral.dll (windows compatibility dll). Otherwise everything that gets loaded is the same. When I check properties of the main program, there are no compatibility settings checked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I might have found the problem. Somehow in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers an IgnoreFreeLibrary<my dll name> had been set for the program. Once I deleted the key, things seem to be working. I have to do more testing of various things, and I have no idea how the key got set, or how to prevent it getting re-set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting. Those flags are usually set by the Application Compatibility Wizard that may appear after a program exits with an error. I once looked for more documentation on them but came up empty. What prompted you to look there?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since ACGeneral was loaded, I thought something must be set that I didn't know about. So, I googled how to clear compatibility info and people talked about this registry key. I looked and there is was. Things seem to be working ok now. But, I wish I knew how it got set in the first place.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page