Bug ID 52017
Summary LLDB keeps DLL loaded after FreeLibrary is called.
OS Windows NT
Component All Bugs
CC email@example.com, firstname.lastname@example.org
Created attachment 25307 [details] Test case Repro: * Build a shared library DLL * Create an executable that does not link that DLL * Load a DLL in code using LoadLibrary * Unload the same DLL using FreeLibrary on the HMODULE obtained from the first step * Observe that LLDB does not release its lock on the DLL file, until LLDB is closed. LLDB keeps DLL loaded (and therefore the file locked) even after the FreeLibrary is called. This means that the DLL, and PDB, both remain locked and unable to be modified, even after they are no longer required by LLDB. This can be observed by building the attached test case and running it through LLDB. Once the program is either breakpointed or paused after the FreeLibrary call, you can either attempt to delete the files and observe they cannot be deleted, or use a program such as Process Explorer ([https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer](https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer)) to see the processes that keep a handle to the file. This is only released when LLDB is closed. Debugging the same test case with Visual Studio 2019 (Version 16.9.4) shows that Visual Studio does not keep the DLL or PDB locked after FreeLibrary is called.