in reply to Re^2: killing on win32
in thread killing on win32

When I want to kill processes manualy on w2003, I drop down to the command line and play with wmic process list (you could get started with wmic process list /?). At least one form of the output provides the ppid (parent process) as well as the real pid and the full command line. This makes me think you could walk up or down the tree of all pids and be pretty sure of identifying those that are yours and kill things from the bottom up.

I haven't used it, but Win32::Process::Info::WMI seems to have the ability to query wmi programmatically to get this information. If that works, then all you'd have to worry about is how patched the particular win32 you're dealing with is and whether it has an up-to-date WMI.


I humbly seek wisdom.

Replies are listed 'Best First'.
Re^4: killing on win32
by BrowserUk (Patriarch) on Sep 06, 2007 at 14:52 UTC

    Yes. You could produce a list of all process IDs in the system and then go killing them that way, but how are you going to work out which (system) process IDs relate to processes your daemon started?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      When I'm doing it manually I rely heaviliy on the CommandLine info I get back from WMI, since I know what I started and with which arguments. That might work here.

      In this case I was thinking about using the real pid you said came from the forking open and identifying my own from chaining real pid to real ppid.


      I humbly seek wisdom.
        I rely heaviliy on the CommandLine info I get back from WMI, since I know what I started and with which arguments. That might work here.

        It would at best be a heuristic. Ie. an informed guess. For exampe, if he needed to run two copies of the daemon concurrently, there would be no way to distinguish between the essentially identical processes started by the two copies. It is also a very expensive way to allow him to continue to use fork.

        In this case I was thinking about using the real pid you said came from the forking open and identifying my own from chaining real pid to real ppid.

        Once he moves away from using fork and starts using some other mechanism that gives him the real pids--the two I mentioned, or even Win32::Process::Create() etc.--then he will already have a list of real process IDs and can use kill to kill them, so there is no need for WMI or Win32::Process::KillProcess().


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.