企业官网建设流程全解析

线上故障处理最磨人的阶段，永远是“现象已经发生，证据却没留下来”。服务进程像被人关掉电源一样瞬间消失，事件日志翻遍也只有一行“进程已停止工作”，想查 GC 堆、线程栈、锁等待，全都没有。很多 .NET 团队把生成 Dump 想得很简单，真到了要救命的时刻才发现：不是工具不会用，是对“程序怎么死的”没有提前分类，导致抓取时机、抓取工具和转储类型全都不匹配。这篇文章就围绕“万种死法”来拆解，怎么为不同的崩溃形态提前准备好对应的 Dump 方案，构造成一套能反复复用的采集能力。

1. 先想清楚：程序到底是怎么“死”的

1.1 六类常见的“死法”与诊断目标

我在接手的现场里，程序死法再多，基本都能归到下面六类。把它们先分清楚，后面选工具和参数才不会乱。

这六类里，最容易混淆的是“高 CPU”和“挂起”。表面上看都是服务不响应，但前者线程栈会停在某些热点函数上反复循环，后者通常多线程卡在等待某个对象上。抓 Dump 时的策略截然不同，乱抓一份往往只能得到“这段代码确实有问题”的模糊结论，定位不了根因。

1.2 为什么要先分类再决定怎么抓 Dump

Dump 本质是进程某一时刻的内存快照，包括线程栈、托管堆、已加载模块、句柄状态等。它只在“抓取那一刻”有效，进程退出后一切信息都烟消云散。不同“死法”给我们的可操作窗口完全不同：

瞬间崩溃型：进程可能几十毫秒就没了，人工根本来不及介入。只能用提前部署的自动兜底机制，比如运行时崩溃转储、系统级崩溃转储，或者让工具一直盯着进程。

慢慢恶化型：比如内存爬坡、GC 频繁、请求变慢，进程还活着，有充足时间人工去抓。这类反而不需要太依赖自动化，关键是设置好触发阈值，别等到了 OOM 边缘才行动。

半死不活型：进程还占用着内存、端口和数据库连接，但不处理任何新请求。这时候抓 Dump 风险最小，因为线程基本静止，抓到的现场也最真实。

启动期崩溃型：服务进程生命周期极短，常规“等进程起来再 attach”的思路行不通。需要从进程创建那一刻就介入，或者让运行时在崩溃点自行留痕。

这些分类决定了我们每个实战操作里的两个核心参数：抓取时机和转储类型。前面有一段时间我总是不分场景一律用dotnet-dump collect抓托管堆，结果遇到启动即崩溃的案例完全派不上用场，因为进程在 attach 之前就已经没了。后来明显改观，原因不是换了更厉害的工具，而是先把“这次到底属于哪类死法”想清楚了。

2. 抓 Dump 的三种思路和配套工具

先建立一个基础认知：抓 Dump 的工具不是越多越好，关键要能覆盖“主动采集、规则兜底、被动留痕”三种能力。下面我把常用的一线方案拆开看，弄清楚它们在什么场景下非它不可。

2.1 主动采集：进程还活着时，人工从外部抓取

最轻量、最常用的方式是借助 .NET 诊断工具，在目标进程存活期间手动生成转储。比如一个服务出现内存快速上涨、线程数飙升，但还没崩，这时候直接在服务器上执行：

dotnet-dump collect --process-id 12345 --output /data/dumps/order_20240601.dmp

该命令会通过运行时诊断通道和进程通讯，请求运行时挂起线程、记录托管堆和线程状态，然后写入转储文件。整个过程中目标进程会短暂停顿，采集完成后自动恢复。

这套思路最适合“刚刚发现不对劲、进程还活着”的黄金窗口。比如刚看到告警说内存涨到 2GB，立即手动抓一份，这时候抓到的堆状态和现场行为是最接近的。如果拖到进程被杀，就什么都来不及了。注意dotnet-dump要求目标进程所在机器上安装匹配版本的诊断工具，且必须以同一用户或管理员权限运行。

2.2 规则兜底：用系统工具按条件自动触发

手动采集最怕什么？怕异常来得太快，人还没跑到服务器上进程就没了。这时候需要用规则兜底，让工具提前挂在那里，等条件满足就自动生成 Dump。我实际环境下用最多的是系统工具族的 ProcDump 这类进程监控工具，它能根据进程的异常事件、无响应状态、内存阈值、CPU 阈值等条件触发转储。

典型的兜底用法，是盯住某个进程，只要出现未处理异常或进程退出，就立即抓一份完整转储：

procdump -accepteula -ma -e 1 -f "" -w OrderService.exe

命令里的-w表示如果目标进程还没有启动，就等待它启动后再挂接监控。-ma生成完整的内存转储。-e 1是在异常首次发生时触发，-f ""表示不限定异常类型。对于服务刚启动就崩溃、反复重启的现场，这种“提前等待”的方式往往比人工 attach 更可靠。

规则兜底的核心优势是把“人赶过去”的时间提前到了“程序还没开始运行之前”。运维同事可以在发布前就挂上监控，一旦新版本启动异常，Dump 会在当时自动落到配置好的目录，不用半夜一个个服务器登录。

2.3 被动留痕：让运行时自己在崩溃前留下遗言

有时候连 ProcDump 都来不及，因为崩的层是在非托管代码，或者异常发生得极快。另一种更底层的方式，是启用 .NET 运行时自带的崩溃转储机制。通过环境变量让运行时在句柄未释放、访问违例等致命错误发生时，自己调用底层转储程序生成 Dump。

最常用的几个环境变量：

DOTNET_DbgEnableMiniDump=1 DOTNET_DbgMiniDumpType=4 DOTNET_DbgMiniDumpName=/data/dumps/crash_%p.dmp DOTNET_EnableCrashReport=1

DOTNET_DbgEnableMiniDump=1表示启用崩溃转储；DOTNET_DbgMiniDumpType=4一般用于请求完整转储；DOTNET_DbgMiniDumpName指定转储文件路径，%p会替换成进程 ID。DOTNET_EnableCrashReport=1会额外生成一份 JSON 格式故障报告，包含运行时版本、异常类型、加载的模块等信息。

这套机制的价值在于“触发点最接近崩溃源头”。遇到非常极端的原生层堆损坏，或进程在托管异常处理完成前就终止时，系统外层工具可能捕捉不到准确的崩溃调用栈，但运行时自己知道崩在了哪一帧。很多崩溃循环的复盘最终破局，就是靠这份被动留痕的 Dump。

三种思路的取舍我用一张表总结：

实战中我不会只押一种。线上重点服务通常同时配置“规则兜底”和“被动留痕”，日常巡检时再根据需要手动采集。这样无论程序死得多突然，至少有一个渠道能把现场留下来。

3. 按“死法”逐个落实操作流程

分类和思路都有了，接下来是核心部分：针对每一类实际故障形态，给出我在现场会怎么执行。

3.1 托管异常闪退：用 ProcDump 盯住未处理异常

托管异常闪退在 .NET 服务里发生率最高。它的特点是进程最终会被未处理异常终结，但有些异常生命周期极短，比如在构造阶段就抛出的，人工反应不过来。我通常会先布置 ProcDump 的“异常监听”模式。

procdump -accepteula -ma -e 1 -f "" -w OrderService.exe

当 OrderService.exe 被启动后，ProcDump 立刻挂接。一旦目标进程发生异常，并且满足过滤条件，它就会把包含完整托管堆的转储写到当前目录。生成的文件命名类似OrderService.exe_240601_120000.dmp。

关于-e 1这里容易踩坑。不写参数1时，ProcDump 默认捕捉的是二次机会异常，也就是真正没人处理的最终异常；加了1后，它也会在第一次机会异常时触发。对于排查 .NET 服务崩溃，我建议大多数场景用-e 1 -f ""，因为托管运行时内部会自行消化大量非致命异常，用过滤器-f限定关键异常类型才更有针对性。如果直接不加参数，可能只拿到进程心力衰竭时的结果，丢失第一次异常发生的现场对象。

3.2 启动即崩溃和崩溃循环：提前等待进程出现

启动即崩溃的场景最让人崩溃。服务启动后可能几秒内就退出，手工去dotnet-dump collect完全来不及。这时可以继续用 ProcDump 的-w等待模式。

比如某个 Windows 服务配置成了失败后自动重启，我先起一个常驻监控命令：

procdump -accepteula -ma -e 1 -w OrderService.exe

ProcDump 发现 OrderService.exe 尚不存在时不会退出，而是循环等待。进程一旦创建，它立刻尝试附加。如果崩溃发生在托管异常抛出的瞬间，转储就能被抓住。对进程反复重启的崩溃循环，这个命令可以在每一次新实例上继续生效吗？实际体验是它更多是盯住新进程启动后的第一时间，循环重启场景下需要观察输出日志，确认每次是否重新挂接成功。

如果想更保险，可以同时开启运行时被动留痕。把DOTNET_DbgEnableMiniDump=1和DOTNET_DbgMiniDumpName设置成服务进程可见的环境变量，这样即使 ProcDump 挂接慢了一步，运行时自己也会留下现场。两条路并行，能覆盖绝大多数启动期崩溃案例。

3.3 挂起假死：先看“无响应”再手动采样

挂起类故障的价值在于它不会瞬间消失，留给我们的操作时间相对充裕。首次遇到时，我优先用挂起检测模式，让工具盯着无响应窗口或服务状态：

procdump -accepteula -ma -h OrderService.exe

-h模式适合判断 Windows 窗口和服务是否长时间无响应。一旦检测到目标进程处于无响应状态，立即生成 Dump。

但实际更常见的场景是：服务不对外响应请求，但系统的“无响应”判定还没触发。这时窗口状态并不能准确反映业务挂起，我就会手动生成 Dump，并保存两份样本：

dotnet-dump collect --process-id 12345 --output /data/dumps/hang_20240601_1.dmp

隔 5 到 10 秒再抓一份，分析时对比两份转储的线程栈。如果线程在同一个等待位置上纹丝不动，基本就是锁等待或阻塞；若线程栈在不同调用之间缓慢移动，可能是 I/O 或数据库导致的假死。一次 Dump 是“拍照片”，多份 Dump 才是“录视频”，挂起类分析尤其依赖这种对比。

3.4 内存持续增长：阈值触发代替人工盯梢

内存问题往往不是一夜之间发生的，而是缓慢爬坡几天后突然 OOM。如果一直人工盯着进程内存曲线，效率太低。我的习惯是按进程内存使用量设阈值，让 ProcDump 自动触发。

procdump -accepteula -ma -m 1200 OrderService.exe

上面的-m 1200表示当目标进程内存提交量超过 1200MB 时，生成一次完整转储。阈值怎么设？建议先看监控系统里的历史峰值，在峰值之上留 10%~20% 的缓冲，再设定一个“还没有到 OOM 但已经很危险”的值。比如平时稳定在 800MB，偶尔到 1GB，那我可能把阈值设在 1.2GB，这样抓到的堆已经明显膨胀，但进程还撑得住。

这里有个容易忽略的细节：如果进程内存已经快到极限，才触发转储，页面调度和磁盘 I/O 压力都会剧增，反而可能把进程直接拖垮。宁可阈值偏低，多抓几份，也别等到最后一刻。

3.5 高 CPU 死循环：连续多份瞬时采样找热点

高 CPU 类故障只要进程活着，手动抓 Dump 就来得及，但单份收获有限。死循环栈上的函数几乎不变，单看一份只能看出“它在这一行执行”，无法区分是偶发还是持续。我习惯在短时间内连续抓多份：

dotnet-dump collect --process-id 12345 --output /data/dumps/cpu_20240601_1.dmp sleep 5 dotnet-dump collect --process-id 12345 --output /data/dumps/cpu_20240601_2.dmp sleep 5 dotnet-dump collect --process-id 12345 --output /data/dumps/cpu_20240601_3.dmp

等三份都落到磁盘，再做栈对比。如果三份样本中，某个函数所在的线程始终在同一位置，几乎可以锁定死循环热点。如果热点线程有切换，说明有多个线程在争抢资源或调度异常。

需要提醒的是，抓取动作本身会短暂挂起进程。对 CPU 已经吃满的服务来说，这个停顿基本不影响判断；但对线上高并发请求，连续三次完整转储可能导致请求超时。我会把采集间隔拉长到 10 秒左右，并挑请求量相对低的时间段。

3.6 非托管崩溃与容器环境：运行时自动转储兜底

最后这类最容易被忽略。.NET 程序并不只有托管代码，还会通过 P/Invoke、原生插件等方式触碰非托管区域。一旦发生访问违例、栈溢出、GC 堆损坏等，托管的未处理异常机制未必能接手，常规 ProcDump 不一定能捕获准确的崩溃点。这时就需要启用运行时自身的内置转储能力。

在 Linux 容器或 Windows 服务启动前，预先设置环境变量：

DOTNET_DbgEnableMiniDump=1 DOTNET_DbgMiniDumpType=4 DOTNET_DbgMiniDumpName=/app/dumps/crash_%p.dmp

当运行时检测到不可恢复的原生错误时，会调用内置转储生成器，按指定路径留下完整转储。排查和分析时，这份 Dump 里不仅包含托管线程栈，还包含原生帧和加载模块状态，定位边界问题非常有用。

容器环境还有个独特点：宿主机上的进程和容器内的进程不是一个视角。必须在容器内设置这些环境变量，并把转储目录通过挂载卷暴露到宿主机，否则容器一重启，Dump 文件就随着容器文件系统一起没了。我之前在这上面吃过亏，抓到了崩溃现场，但因为容器没有挂载目录，还没来得及同步转储就被调度器重启了，等于白忙一场。

4. 生成阶段最容易踩的坑与验证方法

工具参数用对了，不代表最后一定能拿到可用的 Dump。生成阶段还有不少雷，这里挑几个我实践里反复踩过的讲。

4.1 抓回来一个“无法分析”的转储

这是最让人沮丧的情况。文件很大，双击也能打开，但一分析全是“无符号”“保留的内存不可用”，等于废纸。原因通常有三个：

第一，架构不匹配。用 64 位工具去分析 32 位进程的转储，或者反过来，都会导致栈回溯异常。抓取时务必确认目标进程位数和转储工具的位数一致。

第二，运行时版本不匹配。.NET 运行时的 SOS 调试器扩展必须和目标进程使用的运行时版本匹配。分析时如果提示找不到对应运行时，就要去下载匹配版本的诊断工具或调试扩展。

第三，转储类型不对。有些场景用的是 MiniDump，只有线程栈没有托管堆，看不到对象详情。对于托管分析，我基本只认 Full Dump，也就是-ma或DOTNET_DbgMiniDumpType=4生成的完整转储。

拿到转储后我做的第一件事不是立刻深挖，而是先确认现场状态：

dotnet-dump analyze /data/dumps/crash_20240601.dmp

在交互环境执行clrstack或dumpheap -stat，如果能正常输出托管栈和对象统计，说明转储可用；如果输出异常或提示内存不可读，就要回头检查上面的几项配置。

4.2 转储期间把服务“冻”了好几十秒

生成完整转储不是免费操作。抓取过程要把大量内存写入磁盘，期间目标进程会停顿。对于内存占几 GB 的服务进程，完整转储可能产生相同量级的文件，写盘时间常常以十秒甚至几十秒计。

这带来一个很难受的副作用：云环境中健康检查超时，服务被判定异常然后被重启；或者线上请求大规模堆积。我的建议是：不要把抓取动作放在业务高峰期；把转储目录放到独立磁盘，避开系统盘和共享存储；如果只需要排查特定问题，优先考虑控制转储大小，而不是无脑全量。

在非必须使用完整转储的场景，我也用过只抓线程栈的轻量转储方式，但这里必须先说实话：对 .NET 大多数问题，没有托管堆数据等于没抓到，所以我极少降低转储规格。更好的方案是提前用独立磁盘、低峰窗口、压缩上传三件事来减轻影响。

4.3 多个同名实例时抓错了进程

服务器上同名进程多个实例并存非常常见。比如同一台机器上部署了两个相似的业务进程，都叫WorkerService.exe。用进程名去触发转储时，工具可能把几个实例的转储一起生成，或者抓到了和不相关的那一个。

最稳妥的做法是用 PID 精确指定。

dotnet-dump collect --process-id 12345

先通过dotnet-counters ps或任务管理器确认目标进程的 PID，再执行采集。如果服务正在重启，PID 可能变化，这时就得用进程名配合启动时间戳来筛选。一个反直觉的经验是：宁可多花一分钟确认 PID，也不要事后发现分析时完全看不出是哪个实例。

4.4 容器里的转储和宿主机看到的不是一回事

前面提过容器环境，这里单独再展开。容器里跑 .NET 时，PID 命名空间、文件系统、环境变量都和宿主隔离。在宿主机上直接抓取容器进程的内存，拿到的转储往往包含宿主视角的地址信息，脱离容器内运行时状态后很难分析。

正确做法是进入容器内部再执行采集工具。转储文件的保存路径必须经过挂载卷映射到宿主机，容器退役后数据才不会丢。

另外，Linux 下进程退出后的容器常常会被编排系统立刻重启，转储还没写完容器就没了。遇到必须保留现场的崩溃循环，可以考虑给容器关掉自动重启策略，或者在优雅退出前先暂停调度，等 Dump 落盘。

4.5 开启自动转储带来的隐性成本

不要在所有机器上全年无休地开着DOTNET_DbgEnableMiniDump=1。运行时每碰到一次异常都要评估是否该转储，会影响关键路径性能。更重要的是，崩溃转储生成本身会引起进程停顿，在高频请求量大的服务上，这种停顿可能反而引发次生故障。

我的习惯是：给核心服务在发布或演练窗口内临时开启自动转储，结束后立即关闭；长期稳定运行的实例只保留低开销的事件日志和性能计数器采集，等出现异常苗头再手动上工具。这样既保证了关键时刻有现场，又避免了把兜底机制做成日常负担。

最后再分享一个习惯

很多人问我，你处理这么多线上死法，到底靠什么稳定复现 Dump？我的答案是“提前做一套最简单的组合拳”。服务发布前，最少要确认三件事：转储目录存在且磁盘空间充足；ProcDump 或同类工具已经以等待模式挂接好；运行时崩溃转储环境变量已设置。平时尽量别关掉它们，遇到问题时先手动抓一份完整转储，再让自动兜底补第二份，两份现场对照着看。这套组合不一定每次都能一击命中，但能让你在“万种死法”里至少保底一份可用现场。生成 Dump 只是第一步，后续怎么结合转储定位线程死锁、内存泄漏和高 CPU 热点，就是下一个阶段要聊的了。