Something wrong with @PID

#1
In debugging a GUI app, heartbeat.exe, I successfully used the "TASKEND /F %@pid[heartbeat.exe]" many times (in the same instance of TCC). Then, for no apparent reason,
Code:
l:\projects\heartbeat\release> taskend /f %@pid[heartbeat.exe]
Cannot end process #9448 [audiodg]
For emphasis:
Code:
l:\projects\heartbeat\release> tasklist
    0  [System Process]
**** SNIP ****
9552  conhost
7132  vcpkgsrv
25952* tcc              13.04  [25952]  l:\projects\heartbeat\release
54660  conhost
9448  audiodg
17444  heartbeat
27836  taskmgr          Windows Task Manager
 
l:\projects\heartbeat\release> echo %@pid[heartbeat.exe]
9448
Later (same TCC session) when audiodg.exe had stopped and was restarted with a new PID, things started working correctly again.

I have no clue how to try to debug this except to try, appropriately, to kill the task which follows audiodg.exe in the TASKLIST. I'll keep my eyes open.
 
#3
It was easy enough to do with v14 ... exactly the same thing. Here it is with v14 and another app.
Code:
l:\projects\heartbeat\release> tasklist
    0  [System Process]
**** SNIP ****
42968* tcc              14.03  [42968]  l:\projects\heartbeat\release
35988  conhost
40516  audiodg
56232  vcpkgsrv
10176  firefox          Something wrong with @PID | Take Command Windows command processor - Mozilla Firefox
3652  heartbeat
 
l:\projects\heartbeat\release> taskend /f %@pid[vcpkgsrv.exe]
Cannot end process #40516 [audiodg]
 
#4
Here's another showing @PID getting it wrong.
Code:
l:\projects\heartbeat\release> ver
 
TCC  14.03.53  Windows 7 [Version 6.1.7601]
 
l:\projects\heartbeat\release> tasklist | grep audiodg
  564  audiodg
 
l:\projects\heartbeat\release> echo %@pid[audiodg.exe]
0
 
l:\projects\heartbeat\release> echo %@isapp[audiodg.exe]  (plugin)
564
 
l:\projects\heartbeat\release> tasklist | grep audiodg
  564  audiodg
 
#6
WAD -- you don't have the necessary rights to query that process.
What do you mean with necessary rights? Isn't "run as admin" enough?
Code:
(system)  C:\...\TCMD14x64 >ver
 
TCC  14.03.52 x64  Windows 7 [Version 6.1.7601]
 
(system)  C:\...\TCMD14x64 >echo %_elevated
1
 
(system)  C:\...\TCMD14x64 >tasklist | findstr /i audiodg
4860  audiodg
 
(system)  C:\...\TCMD14x64 >echo %@pid[audiodg]
0
 
(system)  C:\...\TCMD14x64 >echo %@pid[audiodg.exe]
0
So I have a result which I don't understand, too.
 
#7
I've tried for two days and have been unable to make it fail.
WAD -- you don't have the necessary rights to query that process.
If you have a reproducible failcase (with something other than "audiodg", which you can't access) I'll take another look.
Did you read my first post carefully. I wasn't trying to access audiodg.exe. I tried to end a task to which I do have access and @PID returned the wrong PID; simple as that. I doubt I can give you something **you** can readily reproduce because I have no control over how your (or my) system assigns PIDs. And it would seem, the problem **requires** audiodg.exe.

l:\projects\heartbeat\release> taskend /f %@pid[heartbeat.exe]
Cannot end process #9448 [audiodg]

l:\projects\heartbeat\release> tasklist
0 [System Process]
**** SNIP ****
9552 conhost
7132 vcpkgsrv
25952* tcc 13.04 [25952] l:\projects\heartbeat\release
54660 conhost
9448 audiodg
17444 heartbeat
27836 taskmgr Windows Task Manager

l:\projects\heartbeat\release> echo %@pid[heartbeat.exe]
9448
 
#8
FWIW, on Win7/32, elevated or not, I cannot open audiodg's PID with PROCESS_QUERY_INFORMATION but I can open it with PROCESS_QUERY_LIMITED_INFORMATION.

That audiodg (run by LOCAL_SERVICE) can be opened with PROCESS_QUERY_LIMITED_INFORMATION when **not elevated** is different from the behavior of all other processes not running as the logged-on user.

That may explain Frank's anomaly but I don't think it will help with @PID returning the wrong PID.
 

rconn

Administrator
Staff member
May 14, 2008
10,532
94
#10
Did you read my first post carefully. I wasn't trying to access audiodg.exe. I tried to end a task to which I do have access and @PID returned the wrong PID; simple as that. I doubt I can give you something **you** can readily reproduce because I have no control over how your (or my) system assigns PIDs. And it would seem, the problem **requires** audiodg.exe.
Yes, I read your first post carefully; I do have "audiodg", and (as I said) I am completely unable to reproduce your problem with @PID returning the wrong process ID.

The only way that could happen is if the Windows API involved is returning the wrong information.