20

What is the maximum process id I can get by calling DWORD GetProcessId(HANDLE) or DWORD GetCurrentProcessId()? It is not documented on the API's documentation page.

GIZ
  • 4,409
  • 1
  • 24
  • 43
Shinjikun
  • 590
  • 1
  • 5
  • 13

2 Answers2

20

According to the Pushing the Limits of Windows: Processes and Threads blog post by Mark Russinovich number of processes is limited only by available memory. So theoretically maximum process id is DWORD_MAX aligned to 4: 0xFFFFFFFC (as pid/tid values are aligned to 4 on Windows).

Nuno André
  • 4,739
  • 1
  • 33
  • 46
Sergey Podobry
  • 7,101
  • 1
  • 41
  • 51
  • 3
    But where did you get the notion that a PID is a DWORD? “PIDs are divisible on 4” is confusing and vague. If you mean that they are divisible *by* four, then your assumption that they are DWORDs is baseless because any number is divisible by four. If you mean they are DWORD *aligned* in memory, then again, it is a specious assumption because even a char can be DWORD-aligned. – Synetech Nov 21 '13 at 03:28
  • 4
    I wanted to say that you need to align DWORD_MAX (0xFFFFFFFF) to 4. So the maximum PID is 0xFFFFFFFC. – Sergey Podobry Nov 21 '13 at 15:28
  • But where did your get DWORD from? The word “DWORD” is not present anywhere in the article you linked to. Is there a doc somewhere that says PIDs are DWORDs? – Synetech Nov 21 '13 at 20:19
  • 2
    You can look at GetProcessId function. It returns PID as DWORD. – Sergey Podobry Nov 23 '13 at 09:20
  • Like [I said](http://stackoverflow.com/questions/17868218/17868538?noredirect=1#comment29969056_17868515), that doesn’t mean it actually *uses* the whole range of a DWORD. For example, some API return an `int` or a `DWORD`, but have a smaller range of *valid* values such as `0` and `1` (or `0` and `non-zero`). They round the type up something that can hold the valid range, even if that means there’s too much space that is left unused. – Synetech Nov 24 '13 at 03:20
  • 2
    Just a note that you shouldn't rely on PIDs being [divisible by four](http://blogs.msdn.com/b/oldnewthing/archive/2008/02/28/7925962.aspx). It's purely coincidence. – icabod Jun 04 '14 at 15:36
  • should have given an actual value instead of "near DWORD_MAX or anything". What if someone answers others by:" the meaning of this word? please go to dictionary p.342" – Near Jun 08 '20 at 08:16
  • @Near I added more details to the answer. Thanks for your comment. – Sergey Podobry Jun 18 '20 at 10:32
5

I couldn't find an official statement on it but since it's stored and returned as a DWORD you should assume it can use the entire 32-bit range. In practical systems I've never seen a PID large than ~200,000 though - since Windows will reuse PIDs they rarely get larger.

HerrJoebob
  • 2,264
  • 16
  • 25
  • 39
    I've seen PIDs in the 4 billion range. But I've been around a while. – Raymond Chen Jul 25 '13 at 20:52
  • 1
    @RaymondChen :) Thanks for that, new one on me. – HerrJoebob Jul 25 '13 at 20:54
  • 1
    I believe Win9x used pointers into the kernel as PIDs, so they were generally high in the range of DWORDs. – Gabe Jul 25 '13 at 21:13
  • 1
    Just because PID related functions return a DWORD does not necessarily mean that they are DWORDs; many functions return a type larger than the maximum actual value. I’m not sure why, but I’ve always had the idea that PIDs were 16-bit. A quick search will find that at least *nix systems (even 64-bit ones) apparently do limit PIDs to 32,768, however I have seen some people mention PIDs in Windows over 100,000, so I’m not sure and am searching for some definitive information. – Synetech Nov 21 '13 at 03:32
  • 2
    I've seen much larger process Id's (in the 10's of millions) on systems with applications that have handle leaks, and the process Id's are not made available for re-use. – Greg Askew Mar 12 '17 at 19:04