本地SYSTEM账户下OleClipboard与IDataObject的异常问题排查

基于Raymond Chen的虚拟文件拖拽方案实现远程传输后，普通账户下运行正常，但SYSTEM账户下仅能触发FILEDESCRIPTOR请求、无法获取FILECONTENTS，核心问题集中在SYSTEM账户的会话隔离与COM权限限制上，以下是具体分析和解决方向：

核心原因 #

• 会话隔离限制：SYSTEM账户默认运行在Session 0，而用户交互桌面处于Session 1及以上。跨会话的剪贴板COM对象访问有严格权限管控，用户会话内的目标程序尝试访问SYSTEM进程提供的IStream时，可能因权限不足无法建立连接，从而放弃请求FILECONTENTS。
• COM对象权限与生命周期：你在调用OleSetClipboard后立即释放了IDataObject实例，虽然剪贴板会持有引用，但SYSTEM账户下的COM对象默认ACL可能不允许普通用户账户访问，导致目标程序无法获取FILECONTENTS对应的IStream对象；此外跨场景下引用计数传递可能存在异常，提前释放可能导致对象在请求前就被销毁。

解决方案 #

1. 绑定到用户会话运行
   将SYSTEM账户下的进程切换到目标用户的会话中执行剪贴板操作。可以通过WTSEnumerateSessions枚举当前活跃用户会话，再使用CreateProcessAsUser结合用户令牌启动子进程，在子进程内完成剪贴板设置和粘贴模拟，确保操作处于同一会话，规避跨会话权限问题。

2. 配置COM对象访问权限
   在初始化COM时调用CoInitializeSecurity，设置允许普通用户访问的权限策略；或者在MyDataObject的实现中，显式配置对象的ACL，确保非SYSTEM账户能正常访问该COM对象。

3. 调整IDataObject的释放时机
   临时修改代码，延迟释放IDataObject到消息循环结束后，验证是否是生命周期问题：

if (SUCCEEDED(OleInitialize(NULL))) {
    IDataObject* dtob = new MyDataObject(/*some files info here*/);
    if (dtob) {
        OleSetClipboard(dtob);
        // 此处暂不释放，留到消息循环结束后
    }
    
    // simulate Ctrl-V
    ...
    
    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    
    // 消息循环结束后再释放对象
    if (dtob) {
        dtob->Release();
    }
    OleUninitialize();
}

如果修改后能正常获取FILECONTENTS，说明原释放时机导致对象提前失效，需要确保在粘贴操作完成前保持对象有效。

4. 排查目标程序的安全策略
   部分程序出于安全考虑，会拒绝来自SYSTEM账户的剪贴板数据访问。可以在SYSTEM账户内启动另一个测试程序进行粘贴操作，若能正常获取FILECONTENTS，则问题出在目标程序的安全限制上，需要针对性调整目标程序的权限配置。

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