我很早就发现一个奇怪的现象了，如果你使用任务管理器杀死Explorer.EXE，Windows不会将Explorer.EXE自动唤起，但是如果你自己使用TerminateProcess() 函数结束Explorer.EXE进程，你会发现一个奇怪的现象：被杀死的Explorer.EXE又被Windows自动唤醒了。
在描述具体原因之前，简单介绍一下Explorer.EXE。Explorer.EXE作为Windows Shell的组件之一，主要的用途包括有：
显示桌面、任务栏
提供图形化的文件操作方式（例如大家熟知的资源管理器）
……
总而言之，没有Explorer.EXE的Windows不是不能运作，而是操作很不方便。
作为Windows Shell重要的一环，Explorer.EXE的启动由注册表键值（Windows 2000/XP/Server 2003）：
键：HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
键名：Shell
默认键值：Explorer.EXE
或配置文件system.ini决定（Windows 98/ME）：
[Boot]
Shell=Explorer.EXE
需要注意的是，Windows提供了更换Shell的功能，如果上述的配置点不同，那么Windows会使用其它的Shell，例如把注册表键值更换为cmd.exe，那么启动以后你看到的不是图形化的操作界面而是命令行提示符（很多软件更换Shell就是这样变出来的）。如果上述的配置点出现问题，那么登陆以后你只能看到一个桌面，而桌面上没有任何的图标显示（有部分计算机病毒会这样操作）。
在回顾了Explorer.EXE的功能以后，下面进入正题，说说Explorer.EXE进程杀死的问题。
由于某些特殊原因，我们需要在某些时候杀死Explorer.EXE进程以达到某些效果，但是在使用中发现，很多程序，包括著名的IceSword在杀死Explorer.EXE以后，Explorer.EXE都会被Windows自动唤醒。但是如果使用任务管理器（Taskmgr.EXE）或Process Explorer（http://www.sysinternals.com），则没有这样的现象，为什么呢？
对这2个程序的导入表进行分析和动态跟踪以后，发现这2个程序在结束进程的时候并没有使用 Undocumented API，使用的还是已经公开的API函数TerminateProcess()，这就很奇怪了，为什么我们使用TerminateProcess()去结束Explorer.EXE会出现Explorer.EXE在结束以后被Windows自动唤醒的问题而任务管理器和Process Explorer不会呢？
先研究一下 TerminateProcess() 的调用方式：
以 PROCESS_TERMINATE 方式使用 OpenProcess() API或其他等同方法打开进程句柄
调用 TerminateProcess() API对被打开的句柄执行终止操作
使用 CloseHandel() API关闭句柄。
整个流程非常简单，但是问题到底出在哪里呢？仔细研究所涉及的API的参数，发现在Platform SDK里面并没有对TerminateProcess() API的参数有很相信的解释，特别是第2个参数说的非常模糊。Platform SDK对TerminateProcess() API是这样解释的：
BOOL TerminateProcess(
HANDLE hProcess,
UINT uExitCode
);Parameters
hProcess
[in] Handle to the process to terminate.
The handle must have the PROCESS_TERMINATE access right.
For more information, see Process Security and Access Rights.
uExitCode
[in] Exit code to be used by the process and threads terminated
as a result of this call. Use the GetExitCodeProcess function to
retrieve a process's exit value. Use the GetExitCodeThread function
to retrieve a thread's exit value.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error
information, call GetLastError.
有什么特殊的地方吗？看不出来吧，我也看不出来。但是发现：无论任务管理器还是Process Explorer，在传入第2个参数：uExitCode的时候，传入的值总是1。1有什么特殊的含义吗？我不知道，因为我没法得知Windows是否对1有特殊的处理方式。但是从Platform SDK角度看，没有什么特殊的发现。
于是我试着创建一个了测试工程用于对TerminateProcess() 的参数进行测试，结果令人大吃一惊：如果我把uExitCode的值设置为1，然后去结束Explorer.EXE，会发现Windows并没有自动唤醒Explorer.EXE，但是如果我传入的值是0，则Windows会在Explorer.EXE结束以后自动将Explorer.EXE唤醒。
虽然到目前还是不知道Windows在执行TerminateProcess() 的时候的操作方式（有Windows源代码就可以知道了），但是经过一些尝试，关于TerminateProcess() API的一个隐藏点还是暴露了。
看来Windows隐藏的机密还真的不少啊，要完全解开Windows的所有机密，还是需要源代码的说
