Windows下捕获未处理异常后，异常过滤函数允许执行哪些操作？

老哥，你这套SetUnhandledExceptionFilter加MiniDumpWriteDump的崩溃捕获方案跑通之后，关心过滤函数里的操作边界太正常了——毕竟程序已经崩了，整个进程环境都处于不稳定状态，得把能做啥、不能做啥搞明白，不然好不容易搞的转储可能都生成失败。下面给你掰扯清楚：

一、理论上允许执行的操作 #

• 分配新资源：理论上可以用HeapAlloc/LocalAlloc或者C++的new分配内存，但有个大前提——当前进程的堆还没被异常搞坏。如果异常是堆破坏导致的（比如缓冲区溢出踩了堆结构），那再分配十有八九会触发二次崩溃，直接把你的过滤函数也带走。
• 向硬盘写数据：完全可行，不管是写崩溃日志、保存临时现场数据，还是你正在做的生成MiniDump都没问题。但尽量用底层的WriteFile这类原生API，别用带缓存的高级IO库（比如C++的fstream）——这类库可能依赖CRT的全局状态，而CRT大概率已经因为异常乱套了。
• 启动其他进程：用CreateProcess就能实现，比如启动一个独立的崩溃上报工具来处理dump文件。只要系统本身没崩，这个操作基本没问题，但别在这时候搞复杂的进程间通信，让新进程自己处理后续就行，别依赖当前崩溃进程的状态。
• 基础系统信息操作：像读取环境变量、调用GetSystemInfo获取系统参数、遍历进程模块这类不依赖进程内部复杂状态的操作，大多是安全的。

二、必须重视的限制 #

• 进程内部状态完全不可靠：这是核心！程序触发未处理异常，说明某个核心环节已经彻底乱了——可能是栈被破坏、堆结构损坏、全局变量被篡改、线程状态异常。任何依赖进程内部稳定状态的操作都可能翻车：比如调用业务逻辑函数（大概率已经挂了）、访问全局缓存数据（可能被污染）、甚至调用某些CRT函数（比如printf，如果它的内部缓冲区已经坏了）。
• 别碰用户态锁：如果异常发生在持有临界区（CRITICAL_SECTION）或互斥量的线程里，这个锁可能永远释放不了。你在过滤函数里再去抢同一个锁，直接就死锁，转储都生成不了。
• 绝对不能递归触发异常：你的过滤函数代码必须“零异常风险”，不能有任何可能抛出异常的操作。比如不小心写了空指针访问，会再次触发未处理异常，这时Windows会直接忽略你的过滤函数，走系统默认的崩溃流程（弹错误框然后终止）。
• 权限约束：如果进程是以低权限运行的，写文件、启动进程这些操作可能因为权限不足失败。比如写C盘根目录可能被UAC拦截，最好提前指定有写入权限的目录（比如用户的AppData文件夹）。

三、关键注意事项 #

• 优先完成核心任务：过滤函数的第一优先级是生成MiniDump，写日志、上报这些都是次要的。别因为搞次要操作导致核心转储失败——比如写日志时触发二次异常，那排查问题的关键线索就丢了。
• 只用系统原生API：别依赖第三方库或自己封装的复杂工具类，就用Windows原生API。比如写文件就用CreateFile+WriteFile，避免因为依赖的库状态异常出问题。
• 别做耗时操作：过滤函数里的代码要尽可能快，别搞网络上传这种耗时活儿。进程已经处于异常状态，长时间停留可能被系统判定为无响应强制终止，或者引发其他线程的问题。如果要做耗时操作，交给新启动的独立进程去干，当前进程写完dump就赶紧退出。
• 测试极端崩溃场景：模拟堆破坏、栈溢出、空指针引用这些常见崩溃情况，看看你的过滤函数能不能扛住。有些操作在普通崩溃下没问题，但在堆破坏场景下直接就炸了，必须提前验证。

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