ProcessID obtained from TProcess is different from the ProcessID in Task Manager

[dvigor]

The ProcessID obtained from TProcess is different from the ProcessID in Windows Task Manager.

OS Windows.

Maybe someone came across why this is happening?

Lazarus 2.2.0 (rev lazarus_2_2_0) FPC 3.2.2 i386-win32-win32/win64.

Thanks.

[balazsszekely]

The ProcessID obtained from TProcess is different from the ProcessID in Windows Task Manager.

OS Windows.

Maybe someone came across why this is happening?

Lazarus 2.2.0 (rev lazarus_2_2_0) FPC 3.2.2 i386-win32-win32/win64.

Thanks.

It's working fine at my side.

[marcov]

It is read from the following record that is filled by createprocess.

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-process_information

Do you read it after the execute?

[Remy Lebeau]

The ProcessID obtained from TProcess is different from the ProcessID in Windows Task Manager.

It is possible that the process you are launching in your code is itself short-lived, just starting another process of its own and then exiting immediately.

[dvigor]

Created a test case and a screenshot of its work. I have Windows 10.

[PascalDragon]

calc is a UWP app nowadays. If you look at the Details app of Task Manager you'll see that the process that is running is in fact called Calculator.exe while you did start calc, yet starting Calculator.exe directly inside a command line line window will result in an error. So the process that has been started is - like Remy Lebeau suggested - only a shortlived starter process that starts the real UWP app. Thus, for those kind of apps, there is nothing you can do.

[dvigor]

Yes, I think you are right, thanks.

[balazsszekely]

I managed to catch it with Process Explorer. PE keeps the terminated processes a little bit longer in the list. Calc.exe will start Calculator.exe via svchost, according to PE Calculator.exe is an "Immersive Process", just a fancy way to say modern UI.

[ASerge]

If you want to keep track of the chain of child processes that are generated by the process that you are running, then you can use Jobs.

[KodeZwerg]

Thus, for those kind of apps, there is nothing you can do.

As long you have a little bit of control over you own windows you can very easy get the targets PID by creating a snapshot before calling your target.exe, call target.exe with an terminate check to finally create another snapshot.
Filter out what's new.
In best cases you just have one new PID spawned, in worst cases you have many, it ofc depend on if your system is loading at that time other processes, but the general way like I described above will work.
https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot

[KodeZwerg]

Another way would be, but I can not confirm since I have not tested it yet, again via processes, collect them all after you started via "ShellExecAndWait" method (you need to google for such method, it is not part of pascal).
When "ShellExecAndWait" is finished, it mean that the loader has done its job by finally calling the real_target.exe, now simply compare with the new processes list which have your own application.exe set as parents PID.

[Remy Lebeau]

When "ShellExecAndWait" is finished, it mean that the loader has done its job by finally calling the real_target.exe, now simply compare with the new processes list which have your own application.exe set as parents PID.

In order for that to work, you would have to capture the PID of the EXE that your app is directly launching, and then after the new app is finally running, compare the latest process list looking for a process whose parent PID is the captured PID, not your main app's PID.

Using a Job object is a much more reliable solution, as the OS will actively notify you of ever new process that is added to the Job, and so you can capture the PID of every new process.  When a process is assigned to a Job and it launches a new process, that new process is automatically added to the Job (unless the new process is started with the CREATE_BREAKAWAY_FROM_JOB flag, but you can configure the Job to ignore that flag).

[ASerge]

If you want to keep track of the chain of child processes that are generated by the process that you are running, then you can use Jobs.

+ demo project.

[KodeZwerg]

When "ShellExecAndWait" is finished, it mean that the loader has done its job by finally calling the real_target.exe, now simply compare with the new processes list which have your own application.exe set as parents PID.

In order for that to work, you would have to capture the PID of the EXE that your app is directly launching, and then after the new app is finally running, compare the latest process list looking for a process whose parent PID is the captured PID, not your main app's PID.

Using a Job object is a much more reliable solution, as the OS will actively notify you of ever new process that is added to the Job, and so you can capture the PID of every new process.  When a process is assigned to a Job and it launches a new process, that new process is automatically added to the Job (unless the new process is started with the CREATE_BREAKAWAY_FROM_JOB flag, but you can configure the Job to ignore that flag).

I would have thought that my app spawn a process (has my app has parent) and the spawned create another (has spawn #1 as parent) and spawn #1 close that spawn #2 would get automatical the parent of my app since spawn #1 should be something like "invalid_handle_value"... as said, i havent tested yet.

If you want to keep track of the chain of child processes that are generated by the process that you are running, then you can use Jobs.

+ demo project.

Kudos 

[PascalDragon]

Thus, for those kind of apps, there is nothing you can do.

As long you have a little bit of control over you own windows you can very easy get the targets PID by creating a snapshot before calling your target.exe, call target.exe with an terminate check to finally create another snapshot.
Filter out what's new.
In best cases you just have one new PID spawned, in worst cases you have many, it ofc depend on if your system is loading at that time other processes, but the general way like I described above will work.
https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/nf-tlhelp32-createtoolhelp32snapshot

Another way would be, but I can not confirm since I have not tested it yet, again via processes, collect them all after you started via "ShellExecAndWait" method (you need to google for such method, it is not part of pascal).
When "ShellExecAndWait" is finished, it mean that the loader has done its job by finally calling the real_target.exe, now simply compare with the new processes list which have your own application.exe set as parents PID.

In both cases it depends on when Windows schedules your program again. It could very well happen that the start application used runs very fast (I doubt that for UWP applications, but that isn't the point) and Windows first schedules that instead of returning to your program so your snapshot won't show anything either cause it will be collected after the process has already done its job of spawning its children and left.