简介：操作系统“Windows任务管理器”进程管理实验的配套指导文档，面向正在学习操作系统进程管理章节的学生或自学者。文档先交代背景知识，明确实验目的和工具准备要求，然后围绕三个操作展开：终止进程、显示其他进程计数器、更改正在运行程序的优先级。每一步都给出操作路径和界面观察要点，并提供系统、服务、用户进程分类填写的实验记录表，方便对照环境完成实验并撰写报告。同时，文档还归纳了“应用程序”“进程”“性能”三个选项卡的功能，以及CPU与内存使用、页面错误、句柄计数等关键指标，帮助读者将进程管理理论与Windows界面操作结合起来。资源为单个DOC文档，约251KB，体量轻便；目前已有1013人浏览学习，适合用作课后复习或考前突击的参考资料。
1. 任务管理器里的进程管理实验：从“结束进程”按钮到 CreateProcess() 的一生
不少刚接触操作系统的同学，第一次对“进程”有实感，不是在课本的进程状态图上，而是在 Ctrl + Alt + Del 弹出的任务管理器里——对着几十个映像名称发愣，分不清哪些是系统进程、哪些是服务进程、哪些是自己开的程序。这份实验文档的核心价值，就是把任务管理器从“一个能杀进程的窗口”变成“观察进程生命周期的显微镜”：先通过结束进程、添加计数器、改优先级来建立直观认知，再用两个 Visual C++ 6.0 程序（清单 3-5 的 proccreate 和清单 3-6 的 version）把 CreateProcess()、GetProcessVersion()、SetPriorityClass() 这些 API 串起来，看清楚一个进程从创建、运行到终止的全过程。适合两类人：一是正在做操作系统课程实验、需要交实验报告的学生，二是想补进程管理实操细节、理解 Windows 进程模型边界的开发者。这篇笔记会按“界面操作 → 进程分类 → 源码分析 → 踩坑记录 → 进阶玩法”的顺序，把文档里的实验步骤拆开揉碎。
2. 三个选项卡的边界：应用程序、进程、性能各管哪一段
2.1 选项卡分工背后的设计逻辑
这份实验文档在背景知识里交代得很清楚：任务管理器默认有四个选项卡（应用程序、进程、性能、联网），但真正和进程管理强相关的是前三个。这里有个新手容易混淆的点——应用程序选项卡里看到的是一个“程序级”的视图，比如你开着 Microsoft Word，那里显示的是“实验一 - Microsoft Word”这个任务条目；而进程选项卡里看到的是“进程级”的视图，对应的是 WINWORD.EXE 这个映像文件。一个应用程序可能对应多个进程，一个进程也可能被多个应用程序共享（比如 svchost.exe 同时承载多个 Windows 服务）。性能选项卡则完全是另一个维度：它不再关心“哪个程序”，而是关心“整台机器现在吃得消吗”——CPU 使用率曲线、物理内存总量、句柄数和线程数都在这里汇总。
我在给某高校的同学讲这个实验时，喜欢打一个比方：应用程序选项卡是前台接待处，你看到的都是能跟你交互的窗口；进程选项卡是后台工位图，每个工位上坐着一个进程，哪怕它不跟你说话也在干活；性能选项卡是大楼的总电表，看的是整体负载。这个比方能帮你快速定位问题——Word 卡死了，去应用程序选项卡结束任务可能只是关掉窗口，去进程选项卡结束 WINWORD.EXE 才是真正把后台进程干掉。
2.2 实操：打开任务管理器并完成进程计数
实验文档第一步是打开任务管理器，这里给出三种常用方式，按个人习惯任选一种：
- 按 Ctrl + Alt + Del，在安全界面中选择“任务管理器”
- 右键单击任务栏空白处，在快捷菜单中选择“任务管理器”
- 按 Ctrl + Shift + Esc 直接调用（Windows XP 及以后版本适用）
打开后切到“进程”选项卡，文档里记录的是 40 个进程。这里有个重要提示：别忘了勾选“显示所有用户的进程”或者查看“用户名”列，否则你只能看到当前用户自己的进程，系统进程和服务进程全部会被隐藏。Windows XP 的任务管理器“进程”选项卡自带“用户名”列，正好用来区分 SYSTEM、NETWORK SERVICE、LOCAL SERVICE 和 Administrator 四类进程。
进程分类计数这个步骤，本质上是让你练习“按所有者归类”的读表能力。我一般会让学生在 Excel 里建三张表，分别记录系统进程（用户名是 SYSTEM，比如 csrss.exe、winlogon.exe、services.exe、lsass.exe）、服务进程（用户名是 NETWORK SERVICE 或 LOCAL SERVICE，比如 svchost.exe 的多实例）、用户进程（用户名是 Administrator，比如 WINWORD.EXE、EXPLORER.EXE、taskmgr.exe 自己）。
分类判断口诀： SYSTEM 用户名 → 系统核心进程，别乱杀 NETWORK SERVICE → 网络相关服务宿主，杀错会掉网 LOCAL SERVICE → 本地服务宿主，杀错影响系统功能 Administrator → 用户进程，杀之前先确认有没有未保存数据这里要注意一个细节：进程总数 = 系统进程数 + 服务进程数 + 用户进程数。文档里填的 40 = 25 + 4 + 12 是某个特定环境的快照，你在自己机器上看到的数字一定不一样。实验报告里这个计数不是用来背的，而是用来验证“你确实看懂了用户名列”。
2.3 “选择列”菜单：给进程视图加装仪表盘
实验第二部分是“显示其他进程计数器”，操作路径为“查看”菜单 → “选择列”。这一步的价值在于：默认的进程选项卡只显示映像名称、用户名、CPU、内存使用，这四列信息量太少。比如你想判断某个进程是不是在疯狂读写磁盘，默认视图看不出来，必须手动勾选“I/O 读取字节”和“I/O 写入字节”列；想判断句柄泄漏，就勾选“句柄数”；想看线程数量异常，就勾选“线程数”。
文档里记录的调整后显示项目是“映像名称、用户名、CPU、内存使用、USER 对象、I/O 写…”——这个列表本身不重要，重要的是你要理解每一列的含义。我建议至少勾选以下列：
- PID：进程标识符，排查问题时定位进程的身份证号
- CPU 时间：累计占用的 CPU 时间，比瞬时 CPU 使用率更能反映进程是否失控
- 内存使用：当前工作集大小，看物理内存占用
- 句柄数：句柄泄漏的预警指标，持续增长说明有问题
- I/O 读取/写入字节：判断后台进程是否在偷跑磁盘
在进程选项卡上单击列标题可以按该列排序，再次单击反转顺序。这个排序功能排查问题时极好用——CPU 占用最高的进程排最上面，一眼看到是谁在抢资源。
3. 进程的三种归宿：正常退出、被结束、优先级调整的实验观察
3.1 终止进程操作的正确姿势与连锁反应
实验第三部分要求挑选一个进程结束它，并观察任务管理器里的变化。文档里记录的是结束 BhkSvr.exe 后该进程从列表消失。这里要强调一个关键概念——“终止进程将结束它直接或间接创建的所有子进程”。文档给了 Outlook 98 的例子：结束进程树会连带杀掉 MAPI 后台处理程序 mapisp32.exe，因为它是 Outlook 的子进程。
常见做法是选中某个进程，点击“结束进程”按钮，或者右键 →“结束进程”。更进阶的操作是“结束进程树”——右键菜单里有这个选项，它会结束该进程及其所有子进程。实验报告要求你“对比终止某进程后的操作结果与原记录数据”——我建议你分别试一次“结束进程”和“结束进程树”，观察进程总数分别掉了几个，这比只写“结束进程后消失”有说服力得多。
实操时的安全边界建议：
可安全结束的进程示例： - taskmgr.exe（任务管理器自身，结束后还能重新打开） - 自己启动的记事本、计算器等无关紧要的程序 - 已停止响应、确认无未保存数据的应用程序 不要碰的进程： - System Idle Process（系统空闲进程，并不是一个真实进程） - csrss.exe、winlogon.exe、services.exe、lsass.exe 等系统核心进程 - 不确定用途的 SYSTEM 进程，先搜索确认再决定3.2 优先级调整：SetPriorityClass 的图形化界面操作
实验第三部分是“更改正在运行的程序的优先级”。操作路径：“进程”选项卡 → 右键目标进程 →“设置优先级”→ 选择 实时 / 高 / 高于标准 / 标准 / 低于标准 / 低。文档里提醒得很到位：提升优先级可以让目标进程运行更快，但会挤压其他进程的 CPU 时间，导致系统整体性能下降。这是个零和博弈——CPU 时间总量就那么多，你多拿别人就少拿。
我在做这个实验时遇到过一个有意思的现象：把一个死循环程序优先级调到“实时”后，鼠标都开始飘了。因为“实时”优先级在 Windows 里是 24 级（REALTIME_PRIORITY_CLASS），高于绝大多数系统线程，连输入响应都被抢了。所以实验做归做，别在需要干活的机器上调“实时”，那已经是“让系统瘫痪”的玩法了。
3.3 多处理器环境下的处理器指派
文档末尾补充了一个进阶功能：在多处理器计算机上可以给进程指派处理器，右键进程 →“设置相关性”，勾选允许运行的 CPU 核心。这个操作的本质是调用 SetProcessAffinityMask() API，把进程的执行限制在选定的处理器上。文档特意提示“这有可能导致总体性能的下降”——原因不难理解：你把进程限制在单核上，其他核心空闲也帮不上忙，负载不均衡；而且 Windows 的调度器本来就会做核间迁移来优化缓存命中率，手动限制反而干扰了它的优化策略。
这个功能在实际运维中的典型用途是：某些老软件对单核时序敏感，或者某个测试场景需要精确控制进程跑在哪个核上。日常使用不建议碰。实验报告里记录“操作后所体会的结果”时，可以写“设置为‘高’后，该进程响应速度略有提升，但同屏播放的视频出现掉帧”——这就是一个合格的观察结论。
4. 用 API 看完整生命周期：CreateProcess() 到 ExitProcess() 的代码对照
4.1 清单 3-5 逐段拆解：proccreate 项目的自克隆逻辑
文档实验二的核心是清单 3-5 的 proccreate 项目。这段代码做的事是：程序启动后读取命令行参数里的克隆 ID，如果克隆数没到上限 25，就递归地创建自己的副本。核心函数是 StartClone()，里面调用了 CreateProcess()。三个关键参数值得单独讲：
第一个参数 lpApplicationName 传入 szFilename，即通过 GetModuleFileName(NULL, szFilename, MAX_PATH) 获取的当前可执行文件完整路径。这里用 NULL 也可以，系统会从命令行第一个参数推断可执行文件路径，但显式传路径更可靠，避免搜索路径歧义。
第二个参数 lpCommandLine 是格式化后的命令行：“”%s” %d”，把可执行文件路径和克隆 ID 拼进去。子进程启动后，main() 函数通过 sscanf(argv[1], “%d”, &nClone) 把这个 ID 解析出来。这里有个很经典的 Windows 命令行规则：如果路径含空格，必须用双引号包住整个可执行文件路径，否则系统会把路径截断在第一个空格处。
第三个值得说的是 dwCreationFlags 参数，代码里传的是 CREATE_NEW_CONSOLE。这个标志告诉系统给新进程分配独立的控制台窗口，而不是继承父进程的。如果用默认的 0，子进程会复用父进程的控制台，屏幕上两个进程的输出会混在一起，根本看不出来谁是谁。实验文档里让你填“创建标志参数使用了什么标志”，答案就是这个 CREATE_NEW_CONSOLE。
代码块如下，关键注释已标注：
// proccreate 项目：递归创建自身副本的进程 #include <windows.h> #include <iostream> #include <stdio.h> void StartClone(int nCloneID) { // 提取当前可执行文件的完整路径 TCHAR szFilename[MAX_PATH]; ::GetModuleFileName(NULL, szFilename, MAX_PATH); // 格式化子进程命令行：可执行文件路径 + 克隆 ID TCHAR szCmdLine[MAX_PATH]; ::sprintf(szCmdLine, "\"%s\" %d", szFilename, nCloneID); // 初始化 STARTUPINFO 结构，cb 必须设为结构体大小 STARTUPINFO si; ::ZeroMemory(reinterpret_cast<void*>(&si), sizeof(si)); si.cb = sizeof(si); // 接收子进程句柄和 ID 的 PROCESS_INFORMATION 结构 PROCESS_INFORMATION pi; // 核心调用：创建子进程 BOOL bCreateOK = ::CreateProcess( szFilename, // 应用程序名称：当前 EXE 路径 szCmdLine, // 命令行：路径 + 克隆号 NULL, // 默认进程安全属性 NULL, // 默认线程安全属性 FALSE, // 不继承父进程句柄 CREATE_NEW_CONSOLE, // 给子进程分配新控制台 NULL, // 使用父进程环境变量 NULL, // 使用父进程当前目录 &si, // 启动信息（窗口外观等） &pi); // 返回的进程/线程句柄 // 创建成功后必须关闭子进程句柄，释放内核对象引用 if (bCreateOK) { ::CloseHandle(pi.hProcess); ::CloseHandle(pi.hThread); } } int main(int argc, char* argv[]) { int nClone(0); if (argc > 1) { // 从命令行第二个参数解析克隆 ID ::sscanf(argv[1], "%d", &nClone); } // 输出当前进程的 PID 和克隆 ID std::cout << "Process ID: " << ::GetCurrentProcessId() << ", Clone ID: " << nClone << std::endl; const int c_nCloneMax = 25; if (nClone < c_nCloneMax) { // 递归创建下一个克隆进程 StartClone(++nClone); } // 暂停 500 毫秒，让用户能看到窗口 ::Sleep(500); return 0; }逻辑说明：main() 先看命令行里有没有克隆 ID，没有则 nClone 为 0；然后判断是否达到 25 次上限，没达到就调用 StartClone(++nClone)。StartClone 拿到新的 ID 后创建子进程，子进程的 main() 再解析出 ID 并继续判断，形成一条递归的“进程链”。每个新进程都有独立控制台窗口，所以运行后任务栏上会冒出一连串窗口。逻辑上这是一个深度为 25 的进程链，每个子进程继承父进程的可执行文件路径，只是命令行参数不同。
参数说明：CreateProcess() 的 10 个参数里，真正需要关心的开发参数是第 1 个（可执行文件路径）、第 2 个（命令行）、第 6 个（创建标志）。后几个环境变量、当前目录、STARTUPINFO 一般传 NULL 或默认值即可，但 PROCESS_INFORMATION 必须传有效指针，否则拿不到子进程句柄。注意 CloseHandle() 的重要性——如果不关闭，句柄会一直持有子进程的内核对象，即使子进程退出了对象也不会释放，这就是句柄泄漏的根源。
4.2 清单 3-6 逐段拆解：version 项目的版本信息与优先级提升
清单 3-6 的 version 项目要短得多，核心是演示 GetCurrentProcessId()、GetProcessVersion()、GetVersionEx() 和 SetPriorityClass() 四个 API。文档实验里要求记录程序运行结果——当前 PID、需要的操作系统版本、当前系统版本号。
这里有一个值得展开的细节：GetProcessVersion() 返回的 DWORD 里，高 16 位是主版本号，低 16 位是次版本号。代码里用(WORD)(dwVerReq >> 16)取主版本号，用(WORD)(dwVerReq & 0xffff)取次版本号。这本质上是一个位运算拆包的过程。程序判断osvix.dwMajorVersion >= 5，这是针对 Windows 2000（NT 5.0）的硬编码判断，因为实验环境就是 Windows 2000 Professional。
值得玩味的是 SetPriorityClass() 的调用：它把当前进程的优先级类别设置为 HIGH_PRIORITY_CLASS。运行后在任务管理器里看这个进程，基本优先级会显示为“高”。文档要求你“记录操作后所体会的结果”，我在某高校的机器上跑这段代码后，任务管理器里该进程的 CPU 占用并没有明显变化——因为程序本身在 Sleep(500) 和输出之间几乎没有计算量，优先级再高也不会多抢 CPU 时间。这个观察本身就很有教学意义：优先级是调度权重，不是性能加速器。
// version 项目：查询进程与系统版本信息，并提升当前进程优先级 #include <windows.h> #include <iostream> void main() { // 获取当前进程 PID，这个调用不会失败 DWORD dwIdThis = ::GetCurrentProcessId(); // 获取当前进程所需的操作系统版本 DWORD dwVerReq = ::GetProcessVersion(dwIdThis); WORD wMajorReq = (WORD)(dwVerReq >> 16); // 高 16 位为主版本 WORD wMinorReq = (WORD)(dwVerReq & 0xffff); // 低 16 位为次版本 std::cout << "Process ID: " << dwIdThis << ", requires OS: " << wMajorReq << "." << wMinorReq << std::endl; // 初始化 OSVERSIONINFOEX 结构，必须正确设置 dwOSVersionInfoSize OSVERSIONINFOEX osvix; ::ZeroMemory(&osvix, sizeof(osvix)); osvix.dwOSVersionInfoSize = sizeof(osvix); // 获取当前操作系统版本信息 ::GetVersionEx(reinterpret_cast<LPOSVERSIONINFO>(&osvix)); std::cout << "Running on OS: " << osvix.dwMajorVersion << "." << osvix.dwMinorVersion << std::endl; // 如果是 Windows 2000 及以上 NT 系统，提升当前进程优先级 if (osvix.dwPlatformId == VER_PLATFORM_WIN32_NT && osvix.dwMajorVersion >= 5) { ::SetPriorityClass( ::GetCurrentProcess(), // 目标进程：当前进程 HIGH_PRIORITY_CLASS); // 提升为高优先级 std::cout << "Task Manager should now indicate this " "process is high priority." << std::endl; } }逻辑说明：程序先用 GetCurrentProcessId() 拿 PID，再用 PID 换版本需求，然后通过 GetVersionEx() 拿到操作系统真实版本号，最后根据版本判断是否够格提升优先级。整个流程就是“我是谁 → 我需要什么系统 → 系统是什么 → 系统够不够好 → 够好就提升待遇”的线性判断链。
参数说明：OSVERSIONINFOEX 结构体里 dwOSVersionInfoSize 必须先赋值为 sizeof(OSVERSIONINFOEX)，这是 Windows 版本信息的惯例——系统靠这个字段判断你传的结构体是老的 OSVERSIONINFO 还是新的 OSVERSIONINFOEX，填错会导致调用失败或信息截断。SetPriorityClass() 的两个参数分别是进程句柄和优先级类别，常用的有 IDLE_PRIORITY_CLASS、NORMAL_PRIORITY_CLASS、HIGH_PRIORITY_CLASS、REALTIME_PRIORITY_CLASS。
4.3 编译过程中的常见翻车点
文档实验记录里写得很直白——“不能正常运行，因为程序中出现许多语法和拼写方面的错误”。这实际上是两个问题：第一，实验文档里的代码是从 PDF 或扫描件复制出来的，引号和括号经常变成全角字符，直接粘进 VC++ 6.0 必然报错；第二，VC++ 6.0 对 ANSI 编码的要求很严，中文注释如果编码不对会出现乱码警告。
我处理这类问题的方式是：先把代码手工敲一遍，或者用文本编辑器把全角引号替换成半角引号，再粘进工程。具体替换目标包括：
- 全角双引号“ ” → 半角双引号 "
- 全角括号（） → 半角括号 ()
- 中文分号； → 英文分号 ;
另外，VC++ 6.0 新建工程时选择“Win32 Console Application”，然后选“A simple application”，再把代码粘贴到生成的 .cpp 文件里。直接用 File → New → C++ Source File 方式编译也可以，但那样需要手动配置工程。Build 菜单里如果提示“requires an active project workspace”，就按提示选择“是”创建一个默认工程工作空间，这一步是必修课。
5. 进程管理实验避坑指南：五个高频翻车点与排查方法
5.1 终止系统进程导致蓝屏或登录失效
现象：在进程选项卡里看到不认识的 SYSTEM 进程，出于好奇点了“结束进程”，结果系统立即蓝屏，或者注销后无法重新登录。原因：部分 SYSTEM 进程是系统关键组件的宿主。例如 csrss.exe 是 Win32 子系统的核心，负责控制台窗口和线程创建；winlogon.exe 负责登录和注销流程；services.exe 是服务控制管理器。结束这些进程相当于拆掉大楼承重墙。解决：不要凭“看着没用”判断进程价值。动手前先查“用户名”列——SYSTEM 和 NETWORK SERVICE 开头的进程，一律不要动。如果已经蓝屏，只能强制重启。
5.2 结束进程后程序窗口还在但无法响应
现象：在应用程序选项卡里结束了一个卡死的程序，窗口消失了，但过一会儿它又弹出来，或者进程列表里它的映像名称还在。原因：应用程序选项卡显示的是“任务”，一个任务可能对应多个进程。比如网页浏览器打开了三个标签页，可能有三个同名进程服务它。只结束其中一个是杀不干净的，主进程会感知到子进程退出并重新创建。解决：切到进程选项卡，按“映像名称”列排序，找到同名进程全部选中，右键“结束进程树”。这样把父子进程一锅端，不会再复活。
5.3 设置优先级“实时”后鼠标卡顿、系统近乎假死
现象：把某个进程优先级调到“实时”（REALTIME_PRIORITY_CLASS），鼠标开始掉帧，键盘输入延迟严重，任务管理器都打不开。原因：实时优先级高于绝大多数系统线程，包括输入响应线程。CPU 时间被目标进程占死，系统饿得没力气处理鼠标键盘消息。解决：如果还能打开任务管理器，赶紧把优先级改回“标准”；如果已经卡死，按 Ctrl + Alt + Del 可能不响应，只能强制重启。教训：优先级调整实验只在虚拟机或闲置机器上做，别在工作机上玩实时优先级。
5.4 编译清单 3-5 报错“cannot open include file: 'iostream.h'”
现象：VC++ 6.0 编译报错，找不到 iostream.h 头文件。原因：文档里的代码写的是#include <iostream.h>，但 VC++ 6.0 标准头文件是#include <iostream>，并且需要using namespace std;或加 std:: 前缀。旧教材的代码用的是早期 C++ 风格，与现代编译器不兼容。解决：把#include <iostream.h>改为#include <iostream>，然后给 cout、endl 加 std:: 前缀，或者在文件开头加using namespace std;。文档里的代码其实已经带了 std:: 前缀，但部分复制版会把头文件弄错，注意对照。
5.5 任务管理器显示进程数与预期不符，找不到“用户名”列
现象：按文档步骤打开“进程”选项卡，只有 20 多个进程，而且文档说的“用户名”列根本不存在。原因：任务管理器默认只显示当前用户进程，不勾选“显示所有用户的进程”就看不到 SYSTEM 和服务进程；另外 Windows XP 和 Windows 2000 的任务管理器界面本身有差异。解决：勾选“显示所有用户的进程”复选框；如果还是没有用户名列，点“查看”菜单 →“选择列”，勾选“用户名”。这两个操作做完，进程列表才和文档里的环境对齐。如果还缺进程，可能是杀毒软件或系统精简版砍掉了部分系统服务，不影响实验结论。
6. 把任务管理器当性能工具用：三分钟定位“谁在偷跑”的排查习惯
做完整份实验，如果只记住“结束进程”和“改优先级”，那学到的只是工具操作。我建议你把任务管理器升级成日常性能排查工具，用一套固定流程快速定位机器卡顿的元凶。这套流程是我在给某实验室维护老旧 Windows 机器时总结出来的，每次排查不超过三分钟。
第一步，打开任务管理器，切到“进程”选项卡，勾选“显示所有用户的进程”，按“CPU”列降序排列。看前三个进程是谁。如果某个进程 CPU 占用长期超过 50%，它大概率就是卡顿元凶。第二步，按“内存使用”列降序排列，看谁吃内存最多。注意内存占用高不一定代表有问题——浏览器多标签页吃几个 GB 正常，但要警惕单个进程内存持续增长不回落，这是内存泄漏的典型信号。第三步，按“句柄数”列降序排列，关注句柄数持续增长的进程。第四步，勾选“选择列”里的“I/O 读取字节”和“I/O 写入字节”，按 I/O 读取降序排列，揪出后台偷偷读写磁盘的进程。
三分钟排查清单： 1. CPU 降序：找占用超 50% 的进程 → 确认是否预期占用 2. 内存降序：找占用异常且持续增长的进程 → 疑似内存泄漏 3. 句柄数降序：找句柄数持续攀升的进程 → 疑似句柄泄漏 4. I/O 读取降序：找磁盘读写大户 → 确认是否后台下载或索引服务这套清单同样适用于实验报告的拓展部分——文档要求“观察操作系统运行的动态性能”，你完全可以在性能选项卡里勾选“显示内核时间”，截图红线变化，配合进程列表数据，写出一段比“本次试验让我学会了很多东西”扎实得多的观察结论。文档里提到的“性能”选项卡能显示句柄、线程、进程总数，这些数字配合“进程”选项卡里按句柄数排序的操作，本身就是一份微型性能报告。
最后说一个我自己的血泪教训：有一回我手快，在没确认的情况下结束了某公司内部软件的进程，结果那软件重启后配置文件损坏，花了一个下午才恢复。从那以后我每次在任务管理器里点“结束进程”之前，都强制自己走一遍三连问：这个进程是什么程序？有没有未保存的数据？有没有子进程会被连带杀掉？确认完才动手。这几个问题也建议你记下来——做进程管理实验时养成这个习惯，比记住任何 API 参数都更能让你少吃亏。希望帮到你。
本文还有配套的精品资源，点击获取
