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

@PID, ISAPP - don't see system processes

Discussion in 'Support' started by vefatica, Oct 23, 2012.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    Neither @PID nor the conditional ISAPP seem to be aware of system processes. Is there some built-in way to check for the existence of a system process (besides plowing through the output of TASKLIST)? Could @PID and ISAPP be made to see system processes?
     
  2. Joe Caverly

    Joined:
    Aug 28, 2009
    Messages:
    639
    Likes Received:
    7
    Would @ISPROC be a possible solution?

    Joe
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    Not unless Microsoft changes the Windows security model.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    No, @ISPROC requires a PID.
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    I don't understand. TASKLIST can see system processes and their PIDs. I wrote a little @ISAPP[] plugin (using Toolhelp32Snapshot). It's not much code and if this is a fair test, it's a heck of a lot faster than @PID.
    Code:
    v:\> echo %@isapp[explorer.exe]
    2208
     
    v:\> timer & do i=1 to 1000 (echo %@isapp[explorer.exe] > NUL) & timer
    Timer 1 on: 20:32:30
    Timer 1 off: 20:32:31  Elapsed: 0:00:00.76
     
    v:\> echo %@pid[explorer.exe]
    2208
     
    v:\> timer & do i=1 to 1000 (echo %@pid[explorer.exe] > NUL) & timer
    Timer 1 on: 20:33:00
    Timer 1 off: 20:33:07  Elapsed: 0:00:07.36
    And it sees system processes.
    Code:
    v:\> echo %@isapp[svchost.exe]
    708
     
    v:\> echo %@pid[svchost.exe]
    0
     
  6. Joe Caverly

    Joined:
    Aug 28, 2009
    Messages:
    639
    Likes Received:
    7
    I was looking at the @SERVICE variable function, in the FedUtils plugin, which takes a name, and not a PID. Would this be a possible solution?

    From the FedUtils help file;


    %@service[diskeeper,query] - Running
    %@service[diskeeper,stop] - Stop service diskeeper request sent.
    %@service[diskeeper,query] - Stopped
    %@service[diskeeper,start] - Start service diskeeper request sent.
    %@service[diskeeper,query] - Running
    %@service[mdm,query] - Running
    %@service[clipbook,query] - Not found
    %@service[tcpip,query] - Running
    %@service[msdtc,query] - Stopped
    %@service[fax,query] - Stopped

    Joe
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    No. My original interest was in TASKENG.EXE. Such a process seems to be created whenever a scheduled task is run. That's OK with me but what bugs me is that TASKENG.EXE always runs for five minutes regardless of whether it has anything to do.
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    I was hoping you'd change this behavior. It's easy with CreateToolhelp32Snapshot. Any comment? I did it like this.
    Code:
    DWORD PidFromPartialProcessName(LPWSTR szProcess)
    {
        LPWSTR pSpec = NthArgument(szProcess, 0, NULL, NULL);
        if ( pSpec == NULL )
            return 0;
        StripEnclosingQuotes(pSpec);
     
        DWORD rv = 0;
     
        HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
     
        if ( hSnap == INVALID_HANDLE_VALUE )
            return error(GetLastError(), NULL);
     
        PROCESSENTRY32 pe = {sizeof(PROCESSENTRY32), 0};
     
        if ( Process32First(hSnap, &pe) )
        {
            do
            {
                if ( stristr(pe.szExeFile, pSpec )
                    || !WildcardComparison(pSpec, pe.szExeFile, 0, 1) )
                {
                    rv = pe.th32ProcessID;
                    break;
                }
            }
            while ( Process32Next(hSnap, &pe) );
        }
        CloseHandle(hSnap);
        return rv;
    }
    INT WINAPI f_ISAPP ( LPWSTR psz )
    {
        Sprintf( psz, L"%lu", PidFromPartialProcessName(psz));
        return 0;
    }
    
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    I do not have any plans to change this. (CreateToolhelp32Snapshot works badly in Windows x64.)
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    I can't test it here. I read this.
    Code:
    On x64 you need to change dwFlags in TProcessEntry32 from a DWORD to a ULONG_PTR and then Process32Next will work. its expecting 304 bytes not 300.
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    That's not the problem; the issue is that CreateToolhelp32Snapshot in Windows x64 returns sporadically wrong info for 32-bit processes.
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,794
    Likes Received:
    29
    How do you do TASKLIST? Whatever you do should suffice for @PID and the conditional ISAPP and allow seeing all processes. IMHO, not being able to see all processes with @PID and ISAPP is a significant limitation.

    FWIW, I modified TlHelp32.h according to that tip I quoted, build a 64-bit version of my plugin and got the use of a 64-bit OS (on a bench in the IT dept) today. As a replacement for @PID or ISAPP, the code I posted (@ISAPP) worked OK and still had the huge (9-10 times) speed advantage over @PID and ISAPP.

    I am not convinced that tip is accurate (had you heard it, Rex?). I could find no other mention of it and it seems unlikely that MS wouldn't be aware of such an omission it at this stage of the game. It also seems unlikely that a "dwFlags" parameter would need to be 64 bits considering that the docs say it's "no longer used and is always set to zero".
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    I didn't hear it, I've had several weeks of painful first-hand experience with it. I know Microsoft was aware of it, but they're aware of a lot of things (including at least a couple hundred bugs in the console window handling & APIs that I have tripped over in the past 15 years) that they haven't shown any inclination to fix.

    I haven't looked at it again in the last couple of years; perhaps they've resolved some of the issues in Win7 sp1. Doesn't help with the earlier platforms, and I have zero interest in digging into it again. You're welcome to add it to the suggestion list; if you get a few dozen others to vote for it I'll take another look. (But I suspect that's not going to be very likely.)
     

Share This Page