一个人的 ERP 客户端崩了没退出，拖垮了整台共享服务器
多个用户共享同一台远程桌面服务器（RDS）办公，其中一个用户的 ERP 客户端（SAP Business One）发生崩溃——但崩溃之后并没有正常结束进程，而是持续占用越来越多的内存，而不是释放掉。因为是共享服务器，这一个用户的异常进程，很快就会把服务器整体内存吃紧，进而影响到服务器上其他所有人的使用体验。
想找一个”按会话踢人”的开关，但只有”按进程踢人”的
第一反应是找一种自动化方式，在某个用户的内存占用超过阈值时把它清理掉，而不是每次都靠人工发现、手动结束进程。翻了一圈 Windows 自带工具后发现一个现实的落差：
- Windows 的
taskkill命令，可以按单个进程的内存占用做条件过滤（比如”内存占用超过 1GB 就强制结束”）； - 但如果一个用户会话下同时存在多个进程，每个进程单独看内存占用都不算特别夸张，加总起来却已经很可观——
taskkill这类工具没有直接按”某个用户会话总内存占用”来做条件判断和清理的能力。
工具箱里没有正好对上问题的那把扳手，只能先用手上有的这把
退而求其次：针对已知会异常的具体进程下手
既然找不到”按会话总内存”清理的现成方案，转而采用一个更具体、但足够实用的替代方案：已知这次的异常来源是某个特定的应用进程（ERP 客户端），直接针对这个进程名，设置一条内存占用超过阈值就强制结束的规则：
taskkill /F /FI "memusage gt 1000000" /IM "SAP Business One.exe"这条命令的逻辑是：只要有任何一个名为该进程的实例，内存占用超过约 1GB（1,000,000 KB），就强制结束它。这不是一个通用解法（换成别的应用崩溃导致的内存泄漏，这条规则不会生效），但它精准针对了”这一个已知会闹脾气的进程”，用一条简单规则把原本需要人工巡检才能发现的异常，变成了可以自动清理的情况。
应对方式
把这条 taskkill 规则设置为定期执行的计划任务，作为已知问题应用的自动兜底措施；同时把这个现象反馈给应用厂商，确认该应用崩溃后无法正常释放内存是否是已知缺陷，评估是否有版本更新能从根本上解决。
教训
- 系统自带工具的”过滤维度”，不一定和你实际想解决的问题维度对得上——本例里”进程”和”用户会话”是两个不同的统计单位，工具原生支持前者，但问题的实际归因单位是后者，这类维度不匹配是排查时容易卡住的地方；
- 找不到最理想的解法时，退而求其次、针对已知具体场景的窄解法，也是一种合理的止损方式——不追求一次性解决”所有可能的内存泄漏”，而是先针对”这一个已经反复出现的具体进程”下手，性价比更高；
- 共享型基础设施（多用户共用的服务器）上，一个应用的异常行为会被放大成影响所有人的问题——这类环境下，对单个应用崩溃行为的容忍度应该比独占式桌面环境更低，早点做自动化兜底，能避免”一个人的崩溃变成所有人的事故”。