I've just finished debugging some process tree killing code for one of my clients and came across this gremlin. Here's what can happen:-
The following information was garnered from the toolhelp32 API from Microsoft, however the same information comes back when using WMI.
e.g.
Process name = explorer.exe
PID = 666
Parent PID = 600
(using Process Explorer it's clear that explorer.exe has no parent).
PID 600 doesn't exist on the system, big deal you might be thinking. Well for starters that means you can't programatically determinte which processes have no parent (i.e. in this case Parent PID should be 0 / etc). Worse still, if you're building a hash / etc of parent and children relationships (so you can kill all spawned processes of a particular process for example), then you're also stuffed! Here's why:-
As above, let's say explorer.exe is listed as PID 666 with parent PID as 600. However 600 no longer exists (i.e. the process that spawned it has ended).
Each time you run your process the OS gives you a new PID, eventually your PID will end up being PID 600. Your process has spawned two others (488 and 520); your tree building code finds 488 and 520 by examing their parent PID and determining it's your proc (600). However, the code also thinks explorer.exe is a descendant of your process (due to the historic data still held by the OS / kernel). BOOM!
