My programs already use tasklist run via the system() function.
Here's a snippet from a left over ONGOING ISRUNNING file when 2 instances of HG612_stats.exe attempted to run at the same time:-
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
HG612_stats.exe 2124 0 2,888 K
conhost.exe 6104 0 3,224 K
HG612_stats.exe 8688 0 2,872 K
conhost.exe 8656 0 3,220 K
cmd.exe 2092 0 3,544 K
tasklist.exe 7792 0 5,312 K
cmd.exe 3116 0 3,432 K
IsRunningVB.exe 5672 0 5,432 K
IsRunningVB.exe is RONSKI's program used to simply check for the number of HG612_stats.exe instances, prompting one of them to be exited.
RONSKI is now putting together a small program to include the PIDs of running processes.
My older batch file scripts also (rather unsuccessfully) used taskkill to kill off any 'stuck' processes such as curl etc.
However, neither tasklist or taskkill are included in XP Home versions, so the tasklist/taskkill commands would be simply ignored as 'not found'.
XP Home & Pro do possess tskill though, that can be used with either PID or process name, to kill one or all instances of a given program.
tskill isn't included with W 7 & quite probably not included in Vista.
My programs do determine which Windows version is running though, so it would be relatively easy to use the relevant OS dependent command via the system() function.
I would prefer to code these directly in 'C' though, rather than have to resort to system() calls.
The final issue here is that some PCs seem to occasionally slow down now & then for various reasons.
This can be an issue when generating scheduled daily ongoing and/or 'snapshot' graphs, sometimes still leaving HG612_stats.exe running into the next minute.
On the assumption the older process is the 'stuck' one to kill, the wrong process would be killed & scheduled graphs/data would be lost.
Hence me attempting to discover how to get HG612_stats.exe to trigger the graphing processes & continue to exit cleanly, leaving the graphing processes to do their own thing in their own time.
If that can be achieved, taskkill or its equivalent should then be able to just kill any genuinely 'stuck' instances of HG612_stats.exe before it is run again for the next minute's sample.
I had thought that 'stuck' instances were now a thing of the past in the latest amended programs.
Maybe an issue with DSLStats caused an issue with HG612_stats which caused another issue with DSLStats which caused another issue with HG612_stats which caused another issue with DSLStats....................................
(Or vice-versa)
.