Windows doesn't track "sub"processes. Any started process is a peer to all others.

Since circa. Win2000, it can track related process groups--see Job objects and Win32::Job

I know. But just starting a process doesn't automatically associate it with the parent. Process Explorer, which I highly recommend, highlights Jobs in a ochre. They are seldom used. I see trees of processes started by a project build, some programs such as Open Office, the virus checking system, and of course Explorer and the various command shells, and from using git. None of them use Job objects.

—John

PostgresSQL uses a job. If you look at pg_ctl.exe in PE and enable the lower pane to view handles, you'll see

\BaseNamedObjects\PostgreSQL_6932
[download]

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

But just starting a process doesn't automatically associate it with the parent.

From the documentation that was available, that certainly used to be the case, indeed the MSDN used to shy away from using terms like "parent" and "child". Since Win2000 I wouldn't be so sure, although it does depend on what you mean by associate.

The history of Win32 APIs to iterate through processes is checkered, there used to be at least two rival systems, or even browsing HKEY_PERFORMANCE_DATA. However from W2k there was this (code extract from an XS module):

static int getppid(void) {

    HANDLE hToolSnapshot;
    PROCESSENTRY32 Pe32 = {0};
    BOOL bResult;
    DWORD PID;
    DWORD PPID = 0;
    
    PID = GetCurrentProcessId ();

    hToolSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hToolSnapshot == INVALID_HANDLE_VALUE) {
        return 0;
    }

    Pe32.dwSize = sizeof(PROCESSENTRY32); 

    bResult = Process32First(hToolSnapshot, &Pe32); 

    if (!bResult) 
        return 0;
    
    while ( Process32Next(hToolSnapshot, &Pe32) ) {
        if (Pe32.th32ProcessID == PID) {
            PPID = Pe32.th32ParentProcessID;
            break;
        }
    }

    /* Expected */
    if (GetLastError() == ERROR_NO_MORE_FILES) {
        SetLastError(ERROR_SUCCESS);
    }

    return PPID;
}
[download]

Apologies for displaying a foreign language on this site.

How do you tell the program to shut down gracefully? If it's a GUI program, posting the proper message to the main window, or perhaps broadcasting it to be save, is my first step.

The problem is that I don't know anything about the process to be killed. In theory, it could be anything. In practice, it is very often a (non-GUI) C++ application, which has run on a CASSERT, which in turn pops up a message box, and the process waits forever that some kind soul would click the message box away. But this is only the "typical" scenario, not the only one. The reason is that I don't write the applications which run into those processes, so I can't know in advance what they are going to do....

Ah, then you really want to look for popup-killers. There are ways to prevent modal dialog boxes from appearing at all. This is used on services and servers that are sloppy or incorporate parts that were not so-designed.

You can also be more targeted, noticing that the process has a window of the expected Class to be that popup, and feeding it a message. I think some popup-killers work that way, after the fact. Others prevent them from working in the first place.

—John