When a process is created in Windows (or Unix for that matter) it has a system wide unique identifier called Process ID (PID). The same thing happens for each and every thread in the system. Each thread ends up with a system wide unique identifier referred to as Thread ID (TID). PID/TIDs come from the same pool of identifiers in Windows. In other words once a number is used as PID of a process, the same number cannot be used as TID of another thread and vice versa.
In 32 bit platforms PID/TIDs are 32-bit numbers and in 64-bit they are 64-bit numbers and should be treated as such. When we launch Task Manager or Process Explorer on a typical system, we rarely see huge numbers for PID/TIDs even on servers that have been up for months together. So how does one can create high PID/TID process/thread on a system ? Another related question was just how does the system pick the next PID/TID and when does it reuse a PID (ie. reassign the PID of a dead process to a new process) ? Historically there have been exploits of predictable PID/TID picking in Windows.
So HighPid was born. HighPid can generate a high (more than 2^16 or 65535) PID and/or TID command shell (cmd.exe) or an executable of your choice. Here is a dump of all the options it supports.
The logic HighPid uses is pretty simple. It launches the specified app or cmd.exe (by calling Win32 API CreateProcess) in a loop and leaks the process and thread handles returned intentionally. This forces the system into a smaller and smaller pool of PID/TIDs to assign to new processes/threads on the system thereby leading to high PIDs.
When the /h option is specified HighPid creates the launched process with the leaked process and thread handles and therefore makes the system use high PIDs as long as the launched process is active. Once the launched process is closed, system enumerates all open handles in the process (including the leaked process and thread handles) and closes them. Then all the PID/TIDs claimed are effectively free to be potentially reused by the system.
The last 2 bits of PID/TIDs are always zero making them divisible by 4. PID 0 has always been the pseudo idle process (the process that is “running” when no other process is). PID 4/8 is the System process which hosts all kernel mode only threads. So on a 32 bit Vista system, there are 2^30-1 or 1,073,741,823 possible IDs for user mode processes and threads. That is a whole lot of IDs and the system is going to surely hit hardware limitations before it gets there. To retain system stability after HighPid runs, the line was drawn at 16-bits.
If one runs HighPid (with modifications) to look for 24 bit highs, the system may not recover unless HighPid is interrupted by a control+C or taskkill. CreateProcess may start to fail with ERROR_NO_SYSTEM_RESOURCES (Error 1450). Understandably HighPid would perhaps need a different design to get to those ranges. It would be an interesting challenge for sure.
PS: I have seen HighPid causing PIDs in excess of 300000 with HDD thrashing like crazy. Your mileage may vary.