我的尝试

通过指定/GS-编译器标志和/NoDefaultLib链接器标志，并命名main函数，我使用Microsoft Visual Studio创建了一个最小的，无CRT，依赖关系耗尽的可执行文件mainCRTStartup。该应用程序不会创建其他线程，并且会mainCRTStartup在<5秒后返回，但是终止该过程总共需要30秒。

问题描述

根据我的经验，如果在Windows 10上执行的应用程序仅依赖于默认情况下加载到每个Windows进程中的动态库，则命名为ntdll.dll，KernelBase.dll并且kernel32.dll当主线程从该mainCRTStartup函数返回时，该进程会正常退出。

如果以静态或动态方式（通过调用LoadLibraryW）加载了其他库，则从main函数返回将使该进程保持活动状态：正常运行30秒，在调试器下无限期运行。

语境

在创建进程时，Windows 10进程加载器会创建其他线程以更快地加载动态库，请参阅：

• 为什么Windows 10在我的程序中启动额外的线程？
• Win32控制台应用程序启动时，为什么会有三个意外的辅助线程？

Cylance在Windows 10并行加载细分中提到：

工作线程空闲超时设置为30秒。在30秒以内执行的程序由于ntdll!TppWorkerThreadwaiting进程终止前的空闲超时而似乎挂起。

Microsoft在终止过程中提到：终止过程：

请注意，如果进程的主线程返回，则C运行时库（CRT）的某些实现将调用ExitProcess。

另一方面，Microsoft在ExitProcess：

请注意，从应用程序的主要功能返回会导致对的调用ExitProcess。

测试码

这是我使用过的最低限度的测试代码kernel32!CloseHandle，user32!CloseWindow作为示例，对它们的调用实际上没有执行任何操作：

#include <cstdint>

namespace windows {
    typedef const intptr_t Handle;
    typedef const void *   Module;

    constexpr Handle InvalidHandleValue = -1;

    namespace kernel32 {
        extern "C" uint32_t __stdcall CloseHandle(Handle);
        extern "C" uint32_t __stdcall FreeLibrary(Module);
        extern "C" Module   __stdcall LoadLibraryW(const wchar_t *);
    }

    namespace user32 {
        extern "C" uint32_t __stdcall CloseWindow(Handle);
    }
}

int mainCRTStartup() {
    // 0 seconds
    // windows::kernel32::CloseHandle(windows::InvalidHandleValue);

    // 30 seconds
    // windows::user32::CloseWindow(windows::InvalidHandleValue);

    // 0 seconds
    // windows::kernel32::FreeLibrary(windows::kernel32::LoadLibraryW(L"kernel32.dll"));

    // 30 seconds
    // windows::kernel32::FreeLibrary(windows::kernel32::LoadLibraryW(L"user32.dll"));

    // 0 seconds
    // windows::kernel32::FreeLibrary(windows::kernel32::LoadLibraryW(L""));

    return 0;
}

调试

在mainCRTStartup函数中注释WinAPI的用法将导致上述WinAPI调用的执行时间。

这是在伪C ++中的调试器中跟踪的程序的执行流程：

ntdll.RtlUserThreadStart() {
    kernel32.BaseThreadInitThunk() {
        const auto return_code = test.mainCRTStartup();

        ntdll.RtlExitUserThread(return_code) {
            if (ntdll.NtQueryInformationThread(CURRENT_THREAD, ThreadAmILastThread) != STATUS_SUCCESS || !AmILastThread) {
                // Bad path - for `30 seconds`.

                ntdll.LdrShutdownThread();
                ntdll.TpCheckTerminateWorker(0);
                ntdll.NtTerminateThread(0, return_code);

                // The thread execution does not return from `NtTerminateThread`, but the process still runs.
            } else {
                // Good path - for `0 seconds`.

                ntdll.RtlExitUserProcess(return_code) {
                    ntdll.EtwpShutdownPrivateLoggers();
                    ntdll.LdrpDrainWorkQueue(0);
                    ntdll.LdrpAcquireLoaderLock();
                    ntdll.RtlEnterCriticalSection(ntdll.FastPebLock);
                    ntdll.RtlLockHeap(peb.ProcessHeap);
                    ntdll.NtTerminateProcess(0, return_code);
                    ntdll.RtlUnlockProcessHeapOnProcessTerminate();
                    ntdll.RtlLeaveCriticalSection(ntdll.FastPebLock);
                    ntdll.RtlReportSilentProcessExit(CURRENT_PROCESS, return_code);
                    ntdll.LdrShutdownProcess();
                    ntdll.NtTerminateProcess(CURRENT_PROCESS, return_code);

                    // The thread execution does not return from `NtTerminateProcess` and the process is terminated.
                }
            }
        }
    }
}

预期成绩

我希望该过程如果不创建其他线程并从主函数返回，则将终止。

ExitProcess即使调用WinAPI导致在30秒之前执行，在main函数末尾的调用也会终止该过程。不一定总是可以使用此API，因为有问题的应用程序可能不是我的，而是像这样的第三方应用程序（来自Microsoft）：为什么进程会在RtlExitUserProcess / LdrpDrainWorkQueue中挂起？

在我看来，即使Microsoft进程的行为也不正常，Windows 10进程加载器也已损坏。

1. 有没有解决此问题的解决方案？
2. 如果最后一个用户创建的线程退出，则需要哪些加载器线程？AFAIK目前无法加载任何其他库。