In-depth analysis process PID is the same mystery to:
http://www.xfocus.net/articles/200504/792.html
Created: 2005-04-13 Updated: 2005-04-14
Article attribute: original
Article submission:
SUNWEAR (BTWLU_AT_163.COM)
In-depth analysis process PID the same mystery
Author: sunwear
Shellcoder@163.com
April 2005
Is different processes really have the same PID? I believe that most people will say, this is impossible, because the PID is the uniqueness indicator of the process in the operating system, so it is impossible to have different processes have the same PID, otherwise it will appear when the system is scheduled. . But is it true? There is such a program XXXX, when we use the XXX tool to observe the PID in the system. We found that when this program is running, there are different processes in the system have the same PID. Why is that? Our understanding has a contradiction with the phenomenon we see.
Let us first let us know the EPRocess structure. Each Windows 2000 process is represented by a executor process (eProcess) block, that is, in the kernel, the process is recognized by EPRocess. The following is the structural definition of EPRocess
Typedef struct _eprocess {
KPROCESS PCB;
NTSTATUS EXITSTATUS;
Kevent Lockevent;
Ulong lockcount;
Large_integer createtime;
Large_integer exittime;
PKTHREAD LOCKOWNER;
Handle uniqueprocessid;
List_entry ActiveProcessLinks;
SIZE_T QuotapeakPoolusage [2];
SIZE_T Quotapoolusage [2];
SIZE_T PAGEFILEUSAGE;
Size_t commitcharge;
SIZE_T PeakpageFileusage;
SIZE_T PeakVirtualsize;
SIZE_T Virtualsize;
MMSupport VM;
List_entry sessionProcessLinks;
PVOID Debugport;
PVOID EXCETIONPORT;
Phandle_Table ObjectTable;
Paccess_token token;
Fast_Mutex WorkingSetlock;
PFN_NUMBER WORKINGSETPAGE;
Boolean processoutswapenabled;
Boolean processoutswapped;
Uchar addresssspaceinitialized;
Boolean AddressSpacedeeted;
Fast_Mutex AddressCreationLock;
KSPIN_LOCK HYPERSPACELOCK;
Struct_thread * forkinprogress;
Ushort vmoperty;
Uchar forkwassuccessful;
Uchar mmagressivewstrimmask;
PKEVENT VMOPERATIONEVENT;
PVOID PAETOP;
Ulong lastfaultcount;
Ulong modifiedPageCount;
PVOID VADROOT;
Pvoid Vadhint;
Pvoid cloneroot;
PFN_NUMBER NUMBEROFPRIVATEPAGES;
PFN_NUMBER NUMBEROFLOCKEDPAGES;
Ushort nextPageColor; Boolean EXITPROCALLED;
Boolean createProcessReport;
Handle sectionhandle;
PPEB PEB;
PVOID SectionBaseAddress;
PeProcess_quota_block quotablock;
NTSTATUS LastthReadexitstatus;
Ppagefault_history workingsetwatch;
Handle Win32windowStation;
Handle inheritedFromunique;
Access_mask grantedAccess;
Ulong defaultharderrorprocessing;
PVOID LDTINFORMATION;
Pvoid vadfreehint;
PVOID VDMOBJECTS;
PVOID DeviceMap;
Ulong sessionid;
List_entry physicalvadlist;
Union {
Hardware_pte pagedirectorypte;
Ulonglong filler;
}
Ulong PaePageDirectoryPage;
Uchar imagefilename [16];
Ulong VmtrimfaultValue;
Boolean setTimerResolution;
Uchar priorityclass;
Union {
Struct {
Uchar subsystemminorversion;
Uchar subsisystemmajorversion;
}
Ushort subsisystemversion;
}
PVOID WIN32PROCESS;
Struct_ejob * job;
Ulong JobStatus;
List_entry Joblinks;
Pvoid LockedPageSlist;
PVOID SecurityPort;
PWOW64_PROCESS WOW64PROCESS;
Large_integer readopertod;
Large_integer writeoprationcount;
Large_integer otherperationcount;
Large_integer readtransfercount;
Large_integer WriteTransferCount;
Large_integer OthersferCount;
SIZE_T COMMITCHARGELIMIT;
Size_t commitchargepeaf;
List_entry threadlisthead;
PRTL_bitmap vadphysicalpagesbitmap;
Ulong_ptr vadphysicalpages;
KSPIN_LOCK AWELOCK;
Eprocess;
Each Windows process is labeled by an EPROCESS block in the system space. One of the uniqueProcessid's properties store the only process ID in the system space, that is, the PID we often say.
Let's take a look at the creation of the process. As the article began to start, a parent process constantly creates a child process, the child process ends, but the Win32 Subsystem Process (CSRSS) continuously creates a new process.
Process creation procedures can be found by tracking analysis of CreateProcess. I simply say.
First CreateProcess finds the execution program object after the Win32 mapping executor corresponds to the execution program.
The first is to set the EPROCESS block which includes the process and session ID to store the process and session ID to the corresponding field, set the process exit status, and create an access token.
Then create the initial address space and the settings of the kernel process block and the address space and the setting of the PEB. Create a thread and stack environment.
One of the following is to deliver information to the Win32 subsystem, including the newly created process thread handle. Create an item in the flag and ID and confirm that it belongs to the Win32 application. Behind the initialization thread and complete the initialization of the entire process.
Let's take a look at the procedure to exit.
The EXITPROCESS function does not release the data in the memory when the process is completed, causing the process to end, but Eprocess still exists.
Through the above analysis, you can know that the eProcess of the child process does not disappear with the process, because Eprocess must wait until all Handle shutdown will only be closed. That is to say, EPRocess will be closed when the eProcess Handle Count is 0. To put it bluntly, once the process has an eProcess handle, even if the process exits, Eprocess will not be cleared in memory until all Handle is turned off, it will be cleared. The process mentioned above is closed and the Handle is not closed. It is called Tombie Process. In this case, the Win32 subsystem cannot be aware that some processes have become zombies.
The general view of the process information calls the NTQuerySystemInformation function to display the information of the process.
NTSTATUS
NTQuerySystemInformation
In system_information_class systeminformationclass,
Out pvoid systemInformation,
In Ulong SystemInformationLength,
OUT Pulong ReturnLength Optional
)
The category of SystemInformationClassClass information, SystemInformation a pointer to the function output buffer, SystemInformationLength is the length of this buffer, ReturnLength is the number of write bytes.
The NTQuerySystemInformation function is a direct enumeration EPRocess, so if you pass the NTQuerySystemInformation enumeration process, there will be some same PID. The reason is that CSRSS does not consider the dead process.
This is also possible to understand that the EPRocess will appear before the process is released from the memory.
If there is a mistake or shortcoming in the text, please inform the author's sunwear shellcoder@163.com :)
