freelibrary fails to unload dll

[Steve_R_2]

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.

For the dll in question I tried doing a FreeLibrary right after the LoadLibrary, and it still fails.

So, what's making the dll so "sticky" and what can I try to fix it?

[Steven_L_Intel1]

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.

[Steve_R_2]

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.

I tried the load/free from a different program, duplicating the code in the first that does the same, but minus the other parts of the main program that have nothing to do with this part, and it works ok. The 2 dll's load and unload fine, and can even perform what they are supposed to do, and still unload. So, there is something, that I have yet to find, that keeps the dll loaded in the one case.

[Steven_L_Intel1]

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?

[Steve_R_2]

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.

[JVanB]

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?

[Steve_R_2]

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.

[Steven_L_Intel1]

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.

[Steve_R_2]

I'm not entirely sure how I write a DllMain in fortran. Do I just do - 

subroutine DllMain

 !DEC$ ATTRIBUTES DLLEXPORT::DllMain

 ...

 return

 end

[Steven_L_Intel1]

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.

[Steve_R_2]

It would appear that the unload request is never received. It logs the load, but not the unload.

[Steven_L_Intel1]

That suggests to me there is an extra reference somewhere. I have no clue as to how to diagnose that.

[jimdempseyatthecove]

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

[Steve_R_2]

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?

[Steven_L_Intel1]

Do you do a COMINITIALIZE and COMUNINITIALIZE in the DLL? (Or is it not your DLL?)

[Steve_R_2]

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.

[Steve_R_2]

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.

[Steven_L_Intel1]

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?

[Steve_R_2]

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.