.NET Framework WaitForExit失效 无法定位svchost.exe承载的任务计划程序PID

等待逻辑失效的核心原因：

• taskschd.msc是MMC（微软管理控制台）的管理单元文件，并非独立可执行程序。通过cmd调用时，系统会通过COM激活方式加载该单元，最终将界面托管到共享svchost进程或已运行的MMC进程中，和你启动的cmd进程无强父子关联。
• process.WaitForExit()仅能等待你直接启动的cmd.exe进程退出，无法追踪跨进程托管的窗口状态，因此会出现cmd已退出、任务计划窗口仍显示的问题。

不需要额外编译独立程序，也不需要枚举svchost进程PID，直接绕开cmd中转和默认文件打开逻辑即可。

方案1：直接启动独立MMC进程加载任务计划单元（推荐） #

直接调用mmc.exe，将taskschd.msc作为启动参数传入，此时系统会创建全新的独立MMC进程承载任务计划窗口，直接等待该MMC进程退出即可，逻辑完全可靠。
实现代码如下：

public static bool RunTaskSchedulerAndWait()
{
    try
    {
        ProcessStartInfo startInfo = new ProcessStartInfo
        {
            FileName = "mmc.exe",
            Verb = "runas", // 申请任务计划所需的管理员权限
            Arguments = "taskschd.msc",
            UseShellExecute = true // 提权操作必须开启ShellExecute
        };

        Process tsProcess = Process.Start(startInfo);
        tsProcess.WaitForExit(); // 窗口关闭时MMC进程会同步退出，等待逻辑直接生效
        return true;
    }
    catch
    {
        // 处理用户拒绝提权等异常场景
        return false;
    }
}

注意两点：

1. 提权场景下Verb = "runas"必须配合UseShellExecute = true使用，你原有代码中该值设为false不符合参数要求。
2. 你原有代码的catch块存在逻辑错误：return false写在throw前，异常永远不会被抛出。

方案2：窗口存在性检测兜底（适配极少数MMC复用场景） #

如果在部分定制化Windows系统上遇到MMC进程复用导致等待失效的情况，可以不用追踪进程PID，直接通过Win32 API检测任务计划窗口的存在状态：

• 任务计划程序主窗口的窗口类名固定为MMCMainFrame
• 中文系统下窗口标题固定为任务计划程序，英文系统下为Task Scheduler
  启动后循环调用FindWindow接口检测对应窗口是否存在，直到窗口从系统中消失，即代表用户已关闭窗口，此时再继续执行主逻辑即可。

你之前传入的几个命令都无法实现等待的原因如下：

• 传入"taskschd.msc"、"C:\windows\system32\taskschd.msc /s"、"control schedtasks"时，都是走系统默认的COM激活逻辑，窗口被托管到共享进程，cmd启动后立刻退出
• 传入"start /wait taskschd.msc /s"时，start /wait只能等待直接启动的初始子进程，无法追踪跨进程托管的窗口，因此依然会提前返回

内容的提问来源于stack exchange，提问作者garciafigueres