typedef struct _PROCESS_INFORMATION {
HANDLE hProcess; // 存放每个对象的与进程相关的句柄
HANDLE hThread; // 返回的线程句柄
DWORD dwProcessId; // 用来存放进程ID号
DWORD dwThreadId; // 用来存放线程ID号
} PROCESS_INFORMATION, *PPROCESS_INFORMATION, *LPPROCESS_INFORMATION;
调用Createprocess()函数后，会自动地对该结构进行填充。
创建新进程可使系统建立一个进程内核对象和一个线程内核对象。在创建进程的时候，系统为每个对象赋予一个初始使用计数值1 。然后，在createProcess返回之前，该函数打开进程对象和线程对象，并将每个对象的与进程相关的句柄放入PROCESS_INFORMATION结构的hProcess和hThread成员中。当CreateProcess在内部打开这些对象时，每个对象的使用计数就变为2。
这意味着在系统能够释放进程对象前，该进程必须终止运行(将使用计数递减为1)，并且父进程必须调用CloseHandle(再将使用计数递减1，使之变为0)。同样，若要释放线程对象，该线程必须终止运行，父进程必须关闭线程对象的句柄。
注意，必须关闭子进程和它的主线程的句柄，以避免在应用程序运行时泄漏资源。当然，当进程终止运行时，系统会自动消除这些泄漏现象。但是，当进程不再需要访问子进程和它的线程时，编写得较好的软件能够显式关闭这些句柄(通过调用CloseHandle 函数来关闭)。不能关闭这些句柄是开发人员最常犯的错误之一。
由于某些原因，许多开发人员认为，关闭进程或线程的句柄，会促使系统撤消该进程或线程。实际情况并非如此。关闭句柄只是告诉系统，你对进程或线程的统计数据不感兴趣。进程或线程将继续运行，直到它自己终止运行。
当进程内核对象创建后，系统赋予该对象一个独一无二的标识号，系统中的其他任何进程内核对象都不能使用这个相同的ID号。线程内核对象的情况也一样。当一个线程内核对象创建时，该对象被赋予一个独一无二的、系统范围的ID号。进程ID和线程ID共享相同的号码池。这意味着进程和线程不可能拥有相同的ID。另外，对象绝不会被赋予0作为其ID。在CreateProcess返回之前，它要用这些ID填入PROCESS_INFORMATION结构的dwProcessId和dwThreadId成员中。ID使你能够非常容易地识别系统中的进程和线程。一些实用工具(如Task Manager)对ID使用得最多，而高效率的应用程序则使用得很少。由于这个原因，大多数应用程序完全忽略ID。
如果应用程序使用ID来跟踪进程和线程，必须懂得系统会立即复用进程ID和线程ID。例如，当一个进程被创建时，系统为它指定一个进程对象，并为它赋予ID值122。如果创建了一个新进程对象，系统不会将相同的ID赋予给它。但是，如果第一个进程对象被释放，系统就可以将122赋予创建的下一个进程对象。记住这一点后，就能避免编写引用不正确的进程对象或线程对象的代码。获取进程ID是很容易的，保存该ID也不难，但是，接下来你应该知道，该ID标识的进程已被释放，新进程被创建并被赋予相同的ID。当使用已经保存的进程ID时，最终操作的是新进程，而不是原先获得ID的进程。
有时，运行的应用程序想要确定它的父进程。首先应该知道只有在生成子进程时，才存在进程之间的父子关系。在子进程开始执行代码前，Windows不再考虑存在什么父子关系。较早的Windows 版本没有提供让进程查询其父进程的函数。现在，ToolHelp函数通过PROCESSENTRY32结构使得这种查询成为可能。在这个结构中有一个th32ParentProcess ID成员，根据文档的说明，它能返回进程的父进程的ID。
系统无法记住每个进程的父进程的ID，但是，由于ID是被立即重复使用的，因此，等到获得父进程的ID时，该ID可能标识了系统中一个完全不同的进程。父进程可能已经终止运行。如果应用程序想要与它的“创建者”进行通信，最好不要使用ID。应该定义一个持久性更好的机制，比如内核对象和窗口句柄等。
若要确保进程ID或线程ID不被重复使用，唯一的方法是保证进程或线程的内核对象不会被撤消。如果刚刚创建了一个新进程或线程，只要不关闭这些对象的句柄，就能够保证进程对象不被撤消。一旦应用程序结束使用该ID，那么调用CloseHandle就可以释放内核对象，要记住，这时使用或依赖进程ID，对父进程来说将不再安全。如果使用的是子进程，将无法保证父进程或父线程的有效性，除非父进程复制了它自己的进程对象或线程对象的句柄，并让子进程继承这些句柄。
转载自：http://blog.csdn.net/akof1314/archive/2010/04/11/5471768.aspx