Welcome!

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

SignUp Now!

Problems with ProcessMonitor

Dec
233
2
I created two simple BTM files to demo the problem, Monitor.btm and Monitor2.btm. In Monitor.btm the HUNG option for PROCESSMONITOR just doesn't work, PROCESSMONITOR thinks the program is always hung while Monitor2.btm does not. In both .BTM work fine. I noticed for Monitor2 there is an extra copy of TCC loaded (see the attached JPG files).

I also notice that for HUNG _processcount does not get created, see the output files (CrashFromMonitor.txt and CrashFromMonitor2.txt). When the program crashes _processname and _processpid seem to get lost but _processcount is available. I used SetLocal/EndLocal in the .BTM but if removed the same issues occur.

View attachment Crashed.BTM

View attachment CrashFromMonitor2.txt

View attachment CrashFromMonitor.txt

View attachment Hung.btm

View attachment Monitor2.btm

I'll attach more in next message.

Craig
 
More Files

The Test program is just

#include "stdafx.h"
#include <iostream>
using namespace std ;
int _tmain(int argc, _TCHAR* argv[])
{
unsigned long i = 0 ;
while (true)
{
cout << i++ << " " ;
}
}


I used to Ctrl-C to crash it.

Craig
 

Attachments

  • Monitor.btm
    274 bytes · Views: 215
  • Monitor..JPG
    Monitor..JPG
    8.3 KB · Views: 203
  • Monitor2..JPG
    Monitor2..JPG
    9.9 KB · Views: 212
I created two simple BTM files to demo the problem, Monitor.btm and Monitor2.btm. In Monitor.btm the HUNG option for PROCESSMONITOR just doesn't work, PROCESSMONITOR thinks the program is always hung while Monitor2.btm does not. In both .BTM work fine. I noticed for Monitor2 there is an extra copy of TCC loaded (see the attached JPG files).

I also notice that for HUNG _processcount does not get created, see the output files (CrashFromMonitor.txt and CrashFromMonitor2.txt). When the program crashes _processname and _processpid seem to get lost but _processcount is available. I used SetLocal/EndLocal in the .BTM but if removed the same issues occur.

No bugs here.

First, the HUNG option *does* work, but the way it works is by querying the app (via a SendMessageTimeout WM_NULL), and if it doesn't respond in 5 seconds, PROCESSMONITOR assumes it's hung. In your sample, you generated a console app with an infinite loop which never responds to anything in its message queue, so Windows gets no response and assumes it's hung.

In the case of MONITOR2.BTM, the reason it doesn't appear hung is your START statement *requires* a second TCC (to handle the internal commands in your command group), and PROCESSMONITOR is querying TCC (which does respond to messages), not your infinitely-looping-and-never-responding console app.

For STARTED and HUNG, the _processcount variable is not created, because it would always be 1.

I presume when you say "crashed" you actually mean "ENDED" (which is what a ^C will do). %_processname and %_processpid do not get created on an "ENDED" because, well, the process has ended and it has no name or pid!
 
No bugs here.

First, the HUNG option *does* work, but the way it works is by querying the app (via a SendMessageTimeout WM_NULL), and if it doesn't respond in 5 seconds, PROCESSMONITOR assumes it's hung. In your sample, you generated a console app with an infinite loop which never responds to anything in its message queue, so Windows gets no response and assumes it's hung.

In the case of MONITOR2.BTM, the reason it doesn't appear hung is your START statement *requires* a second TCC (to handle the internal commands in your command group), and PROCESSMONITOR is querying TCC (which does respond to messages), not your infinitely-looping-and-never-responding console app.

For STARTED and HUNG, the _processcount variable is not created, because it would always be 1.

I presume when you say "crashed" you actually mean "ENDED" (which is what a ^C will do). %_processname and %_processpid do not get created on an "ENDED" because, well, the process has ended and it has no name or pid!

The test program was a demo program for another issue. I have four server console processes that I am monitoring that have this same problem. I do have access to the source for these process, what would I have to add to their message handling, so that they could respond to TCMD query?
 
The test program was a demo program for another issue. I have four server console processes that I am monitoring that have this same problem. I do have access to the source for these process, what would I have to add to their message handling, so that they could respond to TCMD query?

The key is in the documentation for PROCESSMONITOR:

"HUNG will test the process's main window to see if it is still responding to messages".

Your average console app does not have a main window -- the window is owned by the Windows console manager, and it does all of the message handling.

I can think of three possible workarounds -- one is to change the console apps to GUI apps (with a hidden window & a message loop). A second is to convert them to hybrid apps (i.e., console apps with a window or GUI apps with a console -- this is what TCC does). Third, you could create a message hook and intercept & respond to the WM_NULL message.

 
The key is in the documentation for PROCESSMONITOR:

"HUNG will test the process's main window to see if it is still responding to messages".

Your average console app does not have a main window -- the window is owned by the Windows console manager, and it does all of the message handling.

I can think of three possible workarounds -- one is to change the console apps to GUI apps (with a hidden window & a message loop). A second is to convert them to hybrid apps (i.e., console apps with a window or GUI apps with a console -- this is what TCC does). Third, you could create a message hook and intercept & respond to the WM_NULL message.


So when earlier, I mentioned two version where one seemed to work, the second copy on TCC was acting as the console manager and was responding to the requests made from the other TCC session that had called PROCESSMONITOR. So how does this relationshilp work PROCESSMONITOR syntax uses the executables name for defining the process that it monitor and in this case it was TEST.EXE. If PROCESSMONITOR doesn't find a Console Manager is the current process does it the look in the parent process? Would console manager copy of TCC know if child process has hung, it seem to know that it terminates?

Craig
 
So when earlier, I mentioned two version where one seemed to work, the second copy on TCC was acting as the console manager and was responding to the requests made from the other TCC session that had called PROCESSMONITOR. So how does this relationshilp work PROCESSMONITOR syntax uses the executables name for defining the process that it monitor and in this case it was TEST.EXE. If PROCESSMONITOR doesn't find a Console Manager is the current process does it the look in the parent process? Would console manager copy of TCC know if child process has hung, it seem to know that it terminates?

The console manager is part of Windows, not part of any other app (including TCC or TCMD).

PROCESSMONITOR isn't looking for a console manager, it's looking for the owner of the main window of the process (which in this case is a console process owned by the console manager).

As I said before, the HUNG option is intended for GUI apps, not console apps (which generally do not process any messages, and which do not have access to their message queues). There is no documented way in Windows to determine whether console apps have hung.
 

Similar threads

Back
Top