The case of the DLL that was not present in memory despite not being formally unloaded, part 2

21 comments

Discussion is closed. Login to edit/delete existing comments.

• 

  Steve June 30, 2026 2

  Copy link to comment by Steve

  Collapse comment by Steve

  There are several operating system components that exhibit similar bugs, many of which appear to have been introduced relatively recently. One example is the FreeConsole API on Windows 10 and Windows 11 - FreeConsole initially destroys the console/file/pipe etc... handles cached in the undocumented PEB, but it fails to clear the corresponding PEB fields afterward.

  As a result, subsequent console APIs continue to treat these stale handle values as valid. Because Windows aggressively recycles handle identifiers, a completely unrelated object is assigned the same handle value that was previously used by the console. The console subsystem suddenly, and unknowingly resumes using...

  Read more

  There are several operating system components that exhibit similar bugs, many of which appear to have been introduced relatively recently. One example is the FreeConsole API on Windows 10 and Windows 11 – FreeConsole initially destroys the console/file/pipe etc… handles cached in the undocumented PEB, but it fails to clear the corresponding PEB fields afterward.

  As a result, subsequent console APIs continue to treat these stale handle values as valid. Because Windows aggressively recycles handle identifiers, a completely unrelated object is assigned the same handle value that was previously used by the console. The console subsystem suddenly, and unknowingly resumes using this now recycled handle, because everything references the PEB, causing console APIs to read from or write to an unintended object. This causes highly unpredictable behavior, since components start overwriting file content, and any number of other issues now that the console is using a random handle identifier that is anything other than the intended console resource.

  A large number of programs also contain the static CRT and load msvcrt.dll or call various functions during process termination. __acrt_AppPolicyGetProcessTerminationMethodInternal will load msvcrt.dll which then calls into _ioinit and it’ll call GetStdHandle() which returns the dangling handle from the PEB, and throws an exception because GetFileType on the handle returned an unexpected value or because the handle was invalid (processes with mitigation policies for invalid handle references).

  PropertySheetW has similar issues with DPI changes, inflating the window to a huge size when the machine has two monitors with different DPI and using cached handles for objects, Explorer can’t close any program or window when hovering the mouse over the taskbar icon and clicking the X on the thumbnail preview – when the window or propsheet is not visibile and was minimized by the show desktop button near the clock.

  Some kernel changes introduced a number of issues with structures where zeroing was performed by the kernel, and this was removed causing programs to read bogus values etc… and some changes to MSVC prevent diagnostic information from being printed when building with diagnostic output even internally…. Microsoft only documents or mentions Explicit Dependencies: This function requires a handle to a process. and does not document or mention anything about the Implicit Dependency: The function assumes and requires that an earlier, unrelated user-mode component (PEB) has initialized a global value or destroyed a global value – staff make changes unaware they’re violating these implicit dependencies and the result is far more severe than breaking the explicit dependency and nobody is aware of the issue because these things are not mentioned anywhere – More than 50 kernel32 and user32 functions that have been around 20 years generally work fine but recently started to render the OS and programs completely unstable in some cases because of implicit dependencies that have been broken especially on Windows 11.

  Read less
• 

  Yexuan Xiao June 29, 2026 2

  Copy link to comment by Yexuan Xiao

  Collapse comment by Yexuan Xiao

  I think the problem lies in UnbindCrtHandles. Console handles are not managed by the CRT, and the CRT does not change their state. Therefore, if UnbindCrtHandles destroys the handles, FreeConsole will fail. You can reach out to the Windows Console team at github.com/microsoft/terminal, they don’t own the UCRT, but they do own the console host, the driver, and FreeConsole.

  • 

    Todd Bandrowsky June 30, 2026 · Edited 0

    Copy link to comment by Todd Bandrowsky

    Collapse comment by Todd Bandrowsky

    Thank you, your insights have been awesome and I appreciate you!

    UnbindCrtHandles comes from MS example. So at a high level, I have this console handle that I get from somewhere, attach it to the CRT, and the CRT, when I go to unattach it, deletes the handles. Is freopen_s not the thing to do here?

    Or maybe is it this approach of attaching and unattaching handles is simply wrong.

    Like I thought C file handles were like a structure somewhere of a fixed size, and you could just plop in your OS handle into that, or, set it to null,...

    Read more

    Thank you, your insights have been awesome and I appreciate you!

    UnbindCrtHandles comes from MS example. So at a high level, I have this console handle that I get from somewhere, attach it to the CRT, and the CRT, when I go to unattach it, deletes the handles. Is freopen_s not the thing to do here?

    Or maybe is it this approach of attaching and unattaching handles is simply wrong.

    Like I thought C file handles were like a structure somewhere of a fixed size, and you could just plop in your OS handle into that, or, set it to null, knowing that, you don’t want the CRT to free these handles because FreeConsole will do it, AND, FreeConsole is supposed to do it.

    (edited to remove something very stupid that I wrote…”just put a flag on FreeConsole that says don’t delete the handles”, which is absurd.

    
    	void UnbindCrtHandles(bool bindStdIn, bool bindStdOut)
    	{
    		// Re-initialize the C runtime "FILE" handles with clean handles bound to "nul". We do this because it has been
    		// observed that the file number of our standard handle file objects can be assigned internally to a value of -2
    		// when not bound to a valid target, which represents some kind of unknown internal invalid state. In this state our
    		// call to "_dup2" fails, as it specifically tests to ensure that the target file number isn't equal to this value
    		// before allowing the operation to continue. We can resolve this issue by first "re-opening" the target files to
    		// use the "nul" device, which will place them into a valid state, after which we can redirect them to our target
    		// using the "_dup2" function.
    
    		if (bindStdIn)
    		{
    			FILE* dummyFile;
    			freopen_s(&dummyFile, "nul", "r", stdin);
    		}
    		if (bindStdOut)
    		{
    			FILE* dummyFile;
    			freopen_s(&dummyFile, "nul", "w", stdout);
    		}
    	}

    Read less
    • 

      Yexuan Xiao July 1, 2026 0

      Copy link to comment by Yexuan Xiao

      Collapse comment by Yexuan Xiao

      I have read some materials and guess that you used freopen("CONOUT$", "w", stdout);. Perhaps the issue lies in the management of "CONOUT$", or in how the CRT handles stdin. In fact, Microsoft has open-sourced part of the UCRT, which fully includes the implementations related to fd and FILE*. You can find them at github.com/huangqinjin/ucrt and investigate how the UCRT manages these to determine whether the UCRT is the root cause.

      Regardless of the reason, I believe the UCRT really messed up on this matter. It should have provided proper initialization and uninitialization functions for stdin/stdout/stderr directly, rather than leaving users to...

      Read more

      I have read some materials and guess that you used freopen(“CONOUT$”, “w”, stdout);. Perhaps the issue lies in the management of “CONOUT$”, or in how the CRT handles stdin. In fact, Microsoft has open-sourced part of the UCRT, which fully includes the implementations related to fd and FILE*. You can find them at github.com/huangqinjin/ucrt and investigate how the UCRT manages these to determine whether the UCRT is the root cause.

      Regardless of the reason, I believe the UCRT really messed up on this matter. It should have provided proper initialization and uninitialization functions for stdin/stdout/stderr directly, rather than leaving users to use freopen to work around the issue.

      Read less
• 

  Eric Brown June 29, 2026 0

  Copy link to comment by Eric Brown

  Collapse comment by Eric Brown

  No. If you have dependencies on DLLs that have complex dependencies of their own, the only reliable way to shut down is to manage the cleanup yourself.

  Relying on the C runtime does not guarantee that things get cleaned up in the right order.

• 

  Todd Bandrowsky June 29, 2026 · Edited 1

  Copy link to comment by Todd Bandrowsky

  Collapse comment by Todd Bandrowsky

  I think is the console, or perhaps, the stdin,stdout file handles on the console. Probably all the recent changes that made the console not suck on Windows, which I love and adore and bless Microsoft for, may have broken this.

  I have a few steps that can reliably reproduce this kind of problem.

  I have an application that is a Windows Desktop application, using WinMain, in C++.
  My main window gets a DirectX surface, which, may or may not be relevant.
  Then I have a Console, which I create like so.

  <code>

  Now I do all my Windows and DirectX stuff and it...

  Read more

  I think is the console, or perhaps, the stdin,stdout file handles on the console. Probably all the recent changes that made the console not suck on Windows, which I love and adore and bless Microsoft for, may have broken this.

  I have a few steps that can reliably reproduce this kind of problem.

  I have an application that is a Windows Desktop application, using WinMain, in C++.
  My main window gets a DirectX surface, which, may or may not be relevant.
  Then I have a Console, which I create like so.

  		AllocConsole();
  		BindCrtHandlesToStdHandles(true, true);
  

  Now I do all my Windows and DirectX stuff and it is great, but, if I shut down the console like so, then, FreeConsole goes boom.

  		UnbindCrtHandles(true, true);
  		FreeConsole();

  Shows up fairly consistently in the debugger with the stack trace exhibiting similar behavior.

  I’ve experimented with the lifetime of having the console managed with the Windows. I’ve tried monkeying with file handles a bit going into the console, and more about the lifetime, like, creating a console within the lifespan of the main window, or without it.

  But the console shutdown doesn’t work, failing in the way you describe, and it complains about a file handle, which might be tripping up the DLL cleanup, like, if I have a calling application and the EXE/DLL gets unlinked and it has a file handle with it, and if there is some confusion about what happens with file handles when unloading an EXE vs a DLL, that something gets jacked in that.

  Read less