从剪贴板读取Outlook消息时触发CLIPBRD_E_BAD_DATA异常问题

• 版本兼容断层：老版本Outlook对FileContents剪贴板读取请求没有做严格参数校验，哪怕调用方传的参数不符合Windows Shell剪贴板规范，也会默认返回第一封邮件的流数据，所以旧代码之前可以正常运行。近期Outlook 365桌面版更新（切换WebView2渲染内核后）补全了参数合法性校验，不符合规范的请求直接返回0x800401D3 (CLIPBRD_E_BAD_DATA)错误，无代码变更也会突然失效。
• WPF原生API实现缺陷：触发异常的System.Windows.Clipboard.GetData("FileContents")方法内部构造请求结构体时，硬编码把文件索引参数lindex设为-1，完全不符合Shell文件剪贴板的规范要求——这个参数必须传从0开始的、和FileGroupDescriptor里列出的文件一一对应的索引值，直接触发Outlook的校验逻辑报错。
• 延迟渲染机制限制：新版Outlook复制邮件时，FileContents走延迟渲染逻辑，只在剪贴板里注册格式占位符（所以调用GetFormats()能看到该格式存在），实际数据还存在Outlook自身进程内存里。只有STA线程发起的、参数完全合法的读取请求，才会触发Outlook把实际数据写入流；MTA后台线程发起的请求、未做Shell格式适配的第三方剪贴板库（比如提到的SharpClipboard）都触发不了数据填充，自然读不到有效内容。

• 方案1：手动调用Win32 API实现规范读取（推荐，全版本兼容）
  操作逻辑：
  1. 把所有剪贴板读取逻辑放到STA线程执行，绝对不要在线程池、MTA后台线程调用剪贴板相关接口
  2. 先打开系统剪贴板，读取FileGroupDescriptor格式的流，解析出当前复制的邮件总数量、每封邮件的文件名
  3. 从0开始遍历每个文件的索引，手动构造FORMATETC请求结构体：cfFormat填FileContents对应的剪贴板格式ID，lindex填当前遍历到的索引值，tymed标记为TYMED_ISTREAM | TYMED_HGLOBAL
  4. 调用GetClipboardData传入构造好的结构体，拿到对应邮件的流数据，全部读取完成后调用CloseClipboard释放剪贴板句柄
• 方案2：快速兼容方案，用WinForm剪贴板API绕过WPF缺陷
  如果不想重写底层Win32逻辑，可以给项目加System.Windows.Forms依赖，在STA线程里调用System.Windows.Forms.Clipboard.GetData("FileContents")读取数据。WinForm的剪贴板实现会正确传入lindex参数，绝大多数场景下可以正常读到Outlook复制的邮件流，改造成本极低。
• 方案3：强制剪贴板数据落地
  如果上面两个方案还偶发报错，可以在读取前调用Win32 API OleFlushClipboard，通知所有往剪贴板写数据的应用把延迟渲染的内容实际写入系统剪贴板，再执行读取操作。注意这个API必须在STA线程调用才会生效。

• 同时复制多封邮件时，不要默认读索引0的流，必须和FileGroupDescriptor里解析出的文件条目一一对应，否则会出现文件名和内容不匹配的问题
• 不要用后台轮询、全局钩子的方式读剪贴板，这类运行上下文不是STA线程，必然会触发Outlook的访问校验失败
• 通用第三方剪贴板库基本都没做Shell文件传输格式的全逻辑适配，兼容不了Outlook的延迟渲染机制，处理Outlook邮件复制场景不要依赖这类库。

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