调用CreateProcess的遗留Windows应用中Excel文件保存路径异常问题

从你描述的情况来看，问题的核心在于两个CreateProcess调用的时序冲突，以及Excel文件的进程占用干扰：

当method1启动的bat/VBScript还在修改目标Excel文件时，method2立刻通过CreateProcess启动Excel打开同一个文件。这会触发两个关键问题：

• 目标Excel文件被第一个进程（bat关联的VBScript所启动的Excel实例）占用，第二个Excel进程无法获取完整的文件控制权，导致第一个进程的修改无法写入原路径，只能 fallback 到Excel默认的Documents文件夹保存。
• 多个Excel实例同时操作同一文件时，Excel的会话状态会被打乱，默认保存路径被重置为系统默认值。

而你注释掉method2后恢复正常，正好验证了这一点——没有第二个进程干扰，VBScript可以正常将修改写入指定路径。

具体解决方案 #

1. 等待method1的进程完全退出后再执行method2

CreateProcess返回的PROCESS_INFORMATION结构体包含了新进程的句柄，你可以用它等待进程结束，确保Excel文件修改操作完全完成：

void method1() {
    BOOL bResult = ::CreateProcess(
        NULL,
        wctAppPath,
        NULL,
        NULL,
        FALSE,
        NULL,
        NULL,
        NULL,
        &stStatusInfo,
        &stProcInfo
    );

    if (bResult) {
        // 等待进程执行完毕（INFINITE表示无限等待，也可以设置合理的超时时间）
        WaitForSingleObject(stProcInfo.hProcess, INFINITE);
        // 必须关闭进程和线程句柄，避免系统资源泄漏
        CloseHandle(stProcInfo.hProcess);
        CloseHandle(stProcInfo.hThread);
    }
}

这样method2会在method1的bat/VBScript完全完成修改并释放文件后再启动，就不会出现保存路径异常的问题。

2. 确保VBScript完全关闭Excel实例

检查你的VBScript代码，确保修改完成后明确退出Excel并释放COM对象，避免Excel后台驻留占用文件：

' 修改后的VBScript示例
Set objExcel = CreateObject("Excel.Application")
Set objWorkbook = objExcel.Workbooks.Open("..\excel.xls")
' 执行你的修改操作...
objWorkbook.Save
objWorkbook.Close
objExcel.Quit
' 释放COM对象，彻底清除后台残留进程
Set objWorkbook = Nothing
Set objExcel = Nothing

如果VBScript没有正确关闭Excel，即使bat脚本执行结束，Excel进程可能还在后台悄悄占用文件，这也会导致后续method2的操作干扰保存路径。

3. 合并操作流程（可选优化）

如果业务逻辑允许，考虑把method2的逻辑整合到method1的bat脚本中——比如在修改完成后直接让bat启动Excel打开文件，避免分开调用CreateProcess，从根源上消除进程冲突的可能。

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