ProcessID obtained from TProcess is different from the ProcessID in Task Manager lazarus / 34-Windows ---------------------------------------------------------------------- dvigor · 2022-11-08 11:36 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 · 2022-11-08 13:37 Quote from: dvigor on November 08, 2022, 12:36:51 pmThe 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 · 2022-11-08 13:37 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 · 2022-11-08 20:05 Quote from: dvigor on November 08, 2022, 12:36:51 pmThe 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 · 2022-11-09 04:35 Created a test case and a screenshot of its work. I have Windows 10. ---------------------------------------------------------------------- PascalDragon · 2022-11-09 06:21 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 · 2022-11-09 09:15 Yes, I think you are right, thanks. ---------------------------------------------------------------------- balazsszekely · 2022-11-09 09:22 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 · 2022-11-09 13:52 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 · 2022-11-10 10:31 Quote from: PascalDragon on November 09, 2022, 07:21:23 amThus, 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 · 2022-11-10 10:41 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 · 2022-11-10 18:08 Quote from: KodeZwerg on November 10, 2022, 11:41:35 amWhen "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 · 2022-11-10 19:49 Quote from: ASerge on November 09, 2022, 02:52:00 pmIf 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 · 2022-11-10 21:25 Quote from: Remy Lebeau on November 10, 2022, 07:08:02 pmQuote from: KodeZwerg on November 10, 2022, 11:41:35 amWhen "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. Quote from: ASerge on November 10, 2022, 08:49:16 pmQuote from: ASerge on November 09, 2022, 02:52:00 pmIf 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 · 2022-11-11 06:42 Quote from: KodeZwerg on November 10, 2022, 11:31:06 amQuote from: PascalDragon on November 09, 2022, 07:21:23 amThus, 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 Quote from: KodeZwerg on November 10, 2022, 11:41:35 amAnother 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. ---------------------------------------------------------------------- Remy Lebeau · 2022-11-14 21:42 Quote from: KodeZwerg on November 10, 2022, 10:25:16 pmI 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"... No, that is not how parent/child process relationships work.  If spawn #1 exits, its parent does not automatically become spawn #2's new parent.  Spawn #2 will simply not have any active parent anymore.  Though APIs like Process32(First|Next)() will still report spawn #1's PID as the parent of spawn #2. ---------------------------------------------------------------------- KodeZwerg · 2022-11-15 22:45 Quote from: Remy Lebeau on November 14, 2022, 10:42:00 pmQuote from: KodeZwerg on November 10, 2022, 10:25:16 pmI 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"... No, that is not how parent/child process relationships work.  If spawn #1 exits, its parent does not automatically become spawn #2's new parent.  Spawn #2 will simply not have any active parent anymore.  Though APIs like Process32(First|Next)() will still report spawn #1's PID as the parent of spawn #2. I tested now, sorry for waiting, fully agree you (I used NtQuerySystemInformation() to get most fastest results) and calc.exe is a little nasty since calling calc.exe starts more than one other process... I fully agree you that I was wrong with my guess about parent! Now I wonder, not tested, will the "jobs" way produce the correct PID or will it produce an array of "possible" PIDs ? ---------------------------------------------------------------------- Remy Lebeau · 2022-11-16 17:16 Quote from: KodeZwerg on November 15, 2022, 11:45:10 pmNow I wonder, not tested, will the "jobs" way produce the correct PID or will it produce an array of "possible" PIDs ? If you spawn calc.exe and add it to a Job, then the Job will notify you (via an I/O Completion Port) every PID that calc.exe spawns, every PID that those processes spawn, and so on, until every process in the Job has terminated.  So yes, you may see multiple PIDs.  You are likely interested only in the final PID that is reported. ---------------------------------------------------------------------- alaa123456789 · 2022-11-18 17:43 Quote from: ASerge on November 10, 2022, 08:49:16 pm + demo project. demo missing some files ex (LPI) not open in lazarus ---------------------------------------------------------------------- ASerge · 2022-11-18 21:49 Quote from: alaa123456789 on November 18, 2022, 06:43:50 pmdemo missing some files ex (LPI) not open in lazarus Open *.lpr and, when prompted, create GUI application. Many developers use their environment "by default". The *.lpi file contains these "default" settings. Therefore, they prefer to automatically create a file with the desired settings. But if you want, then I have attached. ---------------------------------------------------------------------- KodeZwerg · 2022-11-18 22:23 Quote from: Remy Lebeau on November 16, 2022, 06:16:04 pmQuote from: KodeZwerg on November 15, 2022, 11:45:10 pmNow I wonder, not tested, will the "jobs" way produce the correct PID or will it produce an array of "possible" PIDs ? If you spawn calc.exe and add it to a Job, then the Job will notify you (via an I/O Completion Port) every PID that calc.exe spawns, every PID that those processes spawn, and so on, until every process in the Job has terminated.  So yes, you may see multiple PIDs.  You are likely interested only in the final PID that is reported. Thank you again for answering me, somehow I missed it. So when I do understand all correct, one way would be the "jobs" way, repeat iterate over results of the job to find which PID actual has a window, to have a final PID. At least thats my current thinking, I still havent tested it yet, always forgot or no time  But next week I will be more active on this topic what I am really interesting in.