1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Problems with ProcessMonitor

Discussion in 'Support' started by cgunhouse, Nov 12, 2010.

  1. cgunhouse

    cgunhouse

    Messages:
    97
    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
  2. cgunhouse

    cgunhouse

    Messages:
    97
    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

    Attached Files:

  3. rconn

    rconn Administrator Staff Member

    Messages:
    6,710
    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!
  4. cgunhouse

    cgunhouse

    Messages:
    97
    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?
  5. rconn

    rconn Administrator Staff Member

    Messages:
    6,710
    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.

  6. cgunhouse

    cgunhouse

    Messages:
    97
    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
  7. rconn

    rconn Administrator Staff Member

    Messages:
    6,710
    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.

Share This Page