Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@ISPROC Issue

It seems to be a problem with running 15.01 and 16 at the same time.

Actually it seems to be with version 16 and not 15.01
 
Last edited:
Part of this is no surprise. Every process actually uses 4 PIDs ... 4n, 4n+1, 4n+2, and 4n+3 for some n; the first of these is the "visible" one. I've read that Windows has it's reasons for this and I don't recall further details.
When I try something like this
Code: 
v:\> do forever (echo %@isproc[2124] %@isproc[2125] %@isproc[2126] %@isproc[2127] & delay 1)
1 1 1 1
1 1 1 1
0 0 0 0
0 0 0 0
the ones change to zeros within a second or two after the monitored process ends. And it seems to be the same with v15 monitoring v16 or with v16 monitoring v15 or with both TCCs monitoring an instance of notepad.exe.
 
I've had it running without changing for almost 10 minutes, at which time I kill the monitoring process. Tasklist also show that the process is gone as well.
 
I detached my process that is being monitored and the process monitoring the other process from TCMD. I then killed the monitored process and the monitoring process kept think that the monitored process was still there until I exitted the TCMD console. I also tried doing it with just TCC and it worked. It almost seems as if _PID is passing back the PID to TCMD instead of the detached TCC.
 
cgunhouse said:
I detached my process that is being monitored and the process monitoring the other process from TCMD. I then killed the monitored process and the monitoring process kept think that the monitored process was still there until I exitted the TCMD console. I also tried doing it with just TCC and it worked. It almost seems as if _PID is passing back the PID to TCMD instead of the detached TCC.
Click to expand...
I'm pretty confident that if you ask TCC to expand %_PID, you'll get TCC's PID. How are you computing your %SMPID? Could there be a flaw there?
 
I think I found the problem, it has to do with the /INV switch on the START command. I have two .BTM files,

Monitored.btm

@echo on
SETLOCAL
ON BREAK GOTO MyExit
ON CLOSE GOTO MyExit

SET MyDelay=15
SET MySMName=Global\MySMst
SET MyPIDOffset=0
SET MyPIDLength=5
SET SMHandle=%@SMOPEN[128,%MySMName]
SET Status=%@SMWRITE[%SMHandle,%MyPIDOffset,a,%_PID]
SET SMPID=%@SMREAD[%SMHandle,%MyPIDOffset,a,%MyPIDLength]
ECHO The PID being monitored is %SMPID
DELAY 2
START /INV Monitoring
DO FOREVER
Echo %_date %_time I am doing something
Delay %MyDelay
ENDDO
:MyExit
SET Dummy=%@SMCLOSE[%SMHandle]
ENDLOCAL
EXIT
​
Monitoring.btm


@echo on
SETLOCAL
ON BREAK GOTO MyExit
ON CLOSE GOTO MyExit

SET MyDelay=15
SET MySMName=Global\MySMst
SET MyPIDOffset=0
SET MyPIDLength=5
SET SMHandle=%@SMOPEN[128,%MySMName]
SET SMPID=%@SMREAD[%SMHandle,%MyPIDOffset,a,%MyPIDLength]
SET Dummy=%@SMCLOSE[%SMHandle]
ECHO The PID that I am monitoring is %SMPID
DO WHILE %@ISPROC[%SMPID]==1
ECHO %_date %_time I am happily monitoring
DELAY %MyDelay
ENDDO

ENDLOCAL
​
From TCMD run "START Monitored", after Monitored loads Monitoring.btm with "START /INV Monitoring" kill the Monitored process. Monitoring.btm keeps running, kill the TCMD that we used to start everything and it stops. I attach Monitoring.btm as a tab to TCMD and then detach it to view it.

In Monitored.btm change "START /INV Monitoring" to "Start Monitoring" and from TCMD run "START Monitored". After Monitoring.btm starts, kill Monitored.btm, this time Monitoring.btm WORKS without having to kill TCMD.
 
Last edited:
I can't even begin to test this. @SMOPEN always returns 0 when I use "Global\".
Code: 
v:\> ver

TCC  16.00.40  Windows 7 [Version 6.1.7601]

v:\> echo %@smopen[128,Global\mymem]
0

It returns non-zero if TCC is elevated. If elevation is required when using "Global\" the help should say so.
 
The problem real isn't with share memory, it seems to be with the /INV switch on the START command, the share memory was just the method I used to pass the PID of Monitored Process to the Monitoring Process.
 
I removed "Global\" and tried your BTM files with /INV. The whole thing seemed to work as intended. The monitored TCC was visible so I did Ctrl-C to break out of the BTM file and then closed it. Then I went to TCMD and attached the hidden (/INV) TCC that was monitoring. It was no longer monitoring; it had exited the BTM file and was sitting at its prompt.

I then put a "BEEP" at the end of MONITORING.BTM and tried it again. A few seconds after exiting MONITORED.BTM and closing TCC, I heard the beep (from the hidden TCC).

I didn't find anything unexpected.
 
Are you expecting the TCC running MONITORING.BTM to exit when it stops monitoring? It won't unless you start it with "/C" or put EXIT in MONITORING.BTM.
 
Initially I was running this on a XP SP3 machine but I just tried it on a Windows 7 Pro 64-Bit and have the same problem.

I guess the important part is to attach the Monitoring.BTM onto the TCMD console, once Monitoring is attached to TCMD as a Tab, detach it, then stop Monitored.btm. I was testing my .BTM files and I need to see what the /INV .BTM was doing, strangely if you don't attach the /INV process to TCMD it seems to work.
 
Last edited:
I changed MONITORING.BTM to:

@echo off
SETLOCAL
ON BREAK GOTO MyExit
ON CLOSE GOTO MyExit

SET MyDelay=15
SET MySMName=Local\MySMst
SET MyPIDOffset=0
SET MyPIDLength=5
SET SMHandle=%@SMOPEN[128,%MySMName]
SET SMPID=%@SMREAD[%SMHandle,%MyPIDOffset,a,%MyPIDLength]
SET Dummy=%@SMCLOSE[%SMHandle]
ECHO The PID that I am monitoring is %SMPID
DO WHILE %@LEN[%@PIDCOMMAND[%SMPID]] ne 0
ECHO %_date %_time I am happily monitoring %SMPID
DELAY %MyDelay
ENDDO

:MyExit
ENDLOCAL

I changed "%@ISPROC[%SMPID]==1" to "%@LEN[%@PIDCOMMAND[%SMPID]] ne 0" because I couldn't get %@ISPROC to work when MONITORING.BTM is attached to TCMD or had been detached from TCMD.
 
You must log in or register to reply here.
Back
Top