让我来帮你拆解这个问题——你遇到的情况其实是权限启动场景中常见的细节问题，咱们一步步来看可能的原因：

1. WinForms程序自身未明确声明管理员权限需求 #

如果你的WinForms程序没有在它自己的app.manifest文件中设置requestedExecutionLevel为requireAdministrator，那么即使你通过runas verb启动它，程序在执行高权限操作时可能依然会因为权限上下文的问题失败。

对比快捷方式的情况：当你给快捷方式勾选“以管理员身份运行”时，系统会强制绕过程序自身的manifest设置，直接以管理员权限启动它；但通过代码runas启动时，如果程序自身manifest是默认的asInvoker，虽然会触发UAC弹窗，但程序运行时的权限继承逻辑可能存在漏洞，导致关键操作依然没有足够权限。

解决方法：打开WinForms项目的app.manifest（如果没有就添加一个），找到这段代码并修改：

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

2. 工作目录不匹配导致的权限问题 #

快捷方式通常会设置目标程序所在的目录为工作目录，但你的代码启动WinForms程序时，默认的工作目录是WPF程序的运行目录，而不是WinForms EXE所在的C:\Program Files (x86)\目录。

如果WinForms程序中有依赖工作目录的操作（比如写入配置文件、读取本地资源），即使程序以管理员运行，错误的工作目录可能导致它试图写入没有权限的路径（比如WPF程序的用户级目录），从而崩溃。

解决方法：在procStartInfo中显式设置工作目录：

With procStartInfo
    .UseShellExecute = True
    .FileName = "C:\Program Files (x86)\myTestProgram.exe"
    .WindowStyle = ProcessWindowStyle.Normal
    .Verb = "runas"
    .WorkingDirectory = "C:\Program Files (x86)\" ' 添加这一行
End With

3. UseShellExecute的隐性限制 #

当UseShellExecute = True时，runas verb确实会触发UAC提升，但如果你的WPF程序本身不是以管理员权限运行，提升后的WinForms程序会运行在一个独立的权限会话中，可能无法继承某些上下文（比如环境变量、用户配置）。不过这种情况较少见，但可以尝试验证：

先手动以管理员身份启动你的WPF程序，再用代码启动WinForms程序，如果此时能正常运行，说明WPF程序的权限上下文影响了启动逻辑。

4. 64位/32位兼容性问题 #

如果你的WPF程序是32位的，而WinForms程序是64位的（反之亦然），通过runas启动时可能会出现权限重定向问题。比如32位程序访问Program Files会被系统重定向到Program Files (x86)，但如果WinForms程序是64位的，这种重定向可能导致启动的程序权限异常。

解决方法：确保两个程序的目标平台一致（都设为x86或都设为x64），或者在代码中明确使用正确的路径（比如64位程序用C:\Program Files\，32位用C:\Program Files (x86)\）。

你可以先从第1和第2点入手排查，这两个是最常见的原因。另外，建议在WinForms程序的崩溃点添加日志，记录具体的异常信息（比如权限拒绝的路径、错误代码），这会帮你更快定位问题。

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