UnitTests fail intermittently on MacOS with references to kernel32.dll

[tig]

CoPilot says:

The failing job was caused by a crash during test execution. The logs show this key error:

Error in Peek: Unable to load shared library 'kernel32.dll' or one of its dependencies.
The active Test Run was aborted because the host process exited unexpectedly.
The test running when the crash occurred:
Terminal.Gui.ViewsTests.ViewDisposalTest.TestViewsDisposeCorrectly

Note, this does NOT mean TestViewsDisposeCorrectly caused the crash.

Root Cause

• The attempt to load 'kernel32.dll' failed. This DLL is only available on Windows, but the runner is using macOS (based on file paths like /Users/runner/).
• The crash appears during test execution, likely when code attempts to use Windows-specific functionality or P/Invoke to 'kernel32.dll'.
• These classes depend on kernel32.dll:

• Terminal.Gui.Drivers.WindowsConsole — Terminal.Gui/Drivers/WindowsDriver/WindowsConsole.cs
• Terminal.Gui.Drivers.WindowsOutput — Terminal.Gui/Drivers/WindowsDriver/WindowsOutput.cs
• Terminal.Gui.Drivers.NetWinVTConsole — Terminal.Gui/Drivers/DotNetDriver/NetWinVTConsole.cs
• Terminal.Gui.Drivers.WindowsClipboard — Terminal.Gui/Drivers/WindowsDriver/ClipboardImpl.cs

Note: DotNetDriver’s I/O surface (NetInput/NetOutput) itself doesn’t P/Invoke kernel32, but NetWinVTConsole (used by NetInput on Windows) does.

Solution

Not sure. Not sure why its intermittent.

Need to analiyze all tests in UnitTests looking for something that is not forcing FakeDriver or FakeClipboard.

One may might be to put an #ifdef MacOs in the Application.Init codepath that checks to see if anything but fake driver is being loaded.

Another idea would be to create a specific github action that makes it easier to focus just on MacoS failures so that test runs don't take so long.

Originally posted by @tig in #4287 (comment)