UWP 能否通过 oop/winrt 调用以管理员权限运行的 Win32 server？

2026-11-04数据小陈

可以通过桌面辅助进程执行需要管理员权限的操作，但不能将现有 oop/winrt 的自动激活等同于以管理员权限启动。提升后能否继续使用完全相同的 runtimeclass 调用链，现有信息不足以确认，需要结合服务端注册方式、激活机制和通信安全设置判断。

一种较容易保留现有接口的做法是，让当前 Win32 server 继续以普通权限承接 UWP 调用，再由它按需启动管理员辅助进程，并将执行结果返回给 UWP。

full-trust 为什么不等于管理员权限？

runFullTrust 和 UAC 权限提升是两回事。微软文档将这里的 full-trust 应用描述为以 medium integrity level 运行的应用，它不会因此获得管理员令牌。能够访问文件系统也不能证明进程具有管理员权限，因为访问结果还取决于目标文件或目录的权限。应用能力声明说明

目前已验证的是普通权限下的进程外激活和方法调用。执行管理员操作还需要明确的提升入口，并安排提升后的通信。

如何保留现有 UWP 调用方式？

可以按下面的结构拆分职责：

UWP
  → 现有 oop/winrt Win32 server（普通权限）
    → 请求 UAC 提升
      → AdminHelper.exe（管理员权限）
    ← 获取执行结果
  ← 返回 runtimeclass 方法结果

实施时可以分成以下步骤：

保留目前正常工作的 runtimeclass 接口和自动启动逻辑。
将确实需要管理员权限的操作移到独立的 AdminHelper.exe。
在普通权限 Win32 server 中使用 ShellExecuteExW，通过 runas 请求启动辅助进程。
为 server 与辅助进程实现结果返回通道，并处理用户拒绝提升、启动失败和执行失败。

微软的管理员权限开发指南也建议将需要提升的操作放入独立辅助进程，以缩小高权限代码的范围。管理员权限运行指南

Win32 端如何请求管理员权限启动？

下面的 C++ 示例应在普通权限的 Win32 server 或桌面桥接进程中执行：

#include <windows.h>
#include <shellapi.h>

#pragma comment(lib, "Shell32.lib")

DWORD RequestAdminHelper(
    HWND owner,
    const wchar_t* installedHelperPath)
{
    SHELLEXECUTEINFOW info{};
    info.cbSize = sizeof(info);
    info.hwnd = owner;
    info.lpVerb = L"runas";
    info.lpFile = installedHelperPath;
    info.nShow = SW_SHOWNORMAL;

    if (!ShellExecuteExW(&info))
    {
        return GetLastError();
    }

    return ERROR_SUCCESS;
}

installedHelperPath 应指向安装目录中确定的辅助程序。调用方应检查返回值，包括用户取消提升时可能返回的 ERROR_CANCELLED。

runas 会请求以管理员权限运行程序，通常由 UAC 显示同意或凭据提示。这里返回 ERROR_SUCCESS 只表示启动请求成功，并不代表辅助进程已经完成业务操作，也不代表 IPC 已经建立。Shell 启动与 runas 说明

能否直接提升原来的 WinRT server？

提升启动 exe 后，不能据此认定 WinRT 激活会绑定到这个提升后的实例。

传统 COM 提供 Elevation:Administrator!new:{CLSID} 形式的 elevation moniker，但它要求 COM 类具备专门的注册信息，并由客户端显式请求提升。它不是可以直接套在 WinRT runtimeclass 名称上的通用开关，也不能据此认定现有 oop/winrt 激活会自动连接到管理员实例。COM elevation moniker 说明

如果必须提升原 server，需要进一步核对：

server 使用的是哪种 WinRT 或 COM 注册与激活方式。
提升后的实例如何向调用方提供对象，而不是再次启动普通权限实例。
通信权限是否允许来自 UWP AppContainer 或普通权限进程的调用。
用户通过其他管理员账户的凭据完成提升时，通信是否仍然成立。

原问题没有提供 manifest、注册配置或服务端启动代码，因此无法给出保证适用的直接提升配置。

打包和通信还要注意什么？

如果管理员辅助程序位于应用包内，需要核对打包方式是否要求声明 allowElevation。这是一项受限能力，向 Microsoft Store 提交还涉及审批要求。声明该能力不会替代 UAC，也不会让 runtimeclass 自动获得管理员权限。allowElevation 能力说明

辅助进程应只暴露明确的管理操作，并验证调用方和请求参数。选择 IPC 时还要考虑 AppContainer 限制。由普通权限 server 与管理员辅助进程通信，可以让 UWP 继续使用现有接口，但这段新增通信仍需单独实现和验证。