Concurrency任务异常为何会影响后续::ShellExecuteEx()调用？

在某C应用中，我通过托管C实现了按文件名打开文件的逻辑：先用Concurrency::create_task调用异步API打开文件，但该逻辑抛出了异常；捕获异常后我改用::ShellExecuteEx()作为替代方案，却发现这个调用失败了，还触发了ppltasks.h中的_REPORT_PPLTASK_UNOBSERVED_EXCEPTION()。移除Concurrency::create_task相关逻辑后，::ShellExecuteEx()就能正常工作，而且这个问题只出现在Release构建中。请问为什么Concurrency::create_task会影响后续的::ShellExecuteEx()调用？

1. Release模式下PPL未观察异常的副作用 #

Debug模式下，PPL对未观察的任务异常会做调试友好处理（比如直接抛出或保留完整上下文），但Release模式下，未被正确等待/捕获的任务异常会被PPL调度器标记为“未观察”，触发_REPORT_PPLTASK_UNOBSERVED_EXCEPTION()。更严重的是，这类未处理异常可能破坏进程内部状态——比如堆内存损坏、线程本地存储（TLS）的错误标记残留，甚至改变线程的COM上下文，直接干扰后续ShellExecuteEx这类系统调用的执行环境。

2. 异步任务的异常未被彻底处理 #

你虽然捕获了异步API抛出的异常，但如果create_task创建的任务没有被正确等待（比如没调用.get()，也没通过.then()链处理异常），PPL会把异常保留在任务对象中，直到任务销毁。Release模式下，任务销毁时的未观察异常处理逻辑可能修改进程全局错误状态（比如覆盖SetLastError的结果），导致ShellExecuteEx调用时读取到错误的错误码，最终执行失败。

3. ShellExecuteEx对线程上下文的依赖 #

ShellExecuteEx依赖当前线程的COM初始化状态，尤其要求线程处于单线程单元（STA）模式。如果Concurrency::create_task将任务调度到多线程单元（MTA）的线程池线程执行，异常处理过程中没恢复原线程的COM上下文，后续在原线程调用ShellExecuteEx时，COM状态异常会导致调用失败。而Debug模式下线程池的COM上下文管理更宽松，不会触发该问题。

解决建议 #

• 确保任务异常被完全观察：捕获异步API异常后，务必等待任务完成（调用.get()），或通过.then()添加异常处理分支，避免PPL将任务标记为未观察异常状态。
• 恢复线程COM上下文：如果原线程是STA模式，调用create_task前后显式管理COM上下文（比如调用CoInitializeEx/CoUninitialize），确保上下文正确。
• 清除错误状态：调用ShellExecuteEx前，执行SetLastError(0)清除之前的错误状态，避免PPL异常处理残留的错误码干扰系统调用的结果判断。

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