@PID, ISAPP - don't see system processes

[vefatica]

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?

 

[Joe Caverly]

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?

Would @ISPROC be a possible solution?

Joe

 

[rconn]

Could @PID and ISAPP be made to see system processes?

Not unless Microsoft changes the Windows security model.

 

[vefatica]

Would @ISPROC be a possible solution?

Joe

No, @ISPROC requires a PID.

 

[vefatica]

Not unless Microsoft changes the Windows security model.

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.

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.

v:\> echo %@isapp[svchost.exe]
708
 
v:\> echo %@pid[svchost.exe]
0

 

[Joe Caverly]

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?

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

 

[vefatica]

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?

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.

 

[vefatica]

I was hoping you'd change this behavior. It's easy with CreateToolhelp32Snapshot. Any comment? I did it like this.

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;
}

 

[rconn]

I do not have any plans to change this. (CreateToolhelp32Snapshot works badly in Windows x64.)

 

[vefatica]

I do not have any plans to change this. (CreateToolhelp32Snapshot works badly in Windows x64.)

I can't test it here. I read this.

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.

 

[rconn]

That's not the problem; the issue is that CreateToolhelp32Snapshot in Windows x64 returns sporadically wrong info for 32-bit processes.

 

[vefatica]

That's not the problem; the issue is that CreateToolhelp32Snapshot in Windows x64 returns sporadically wrong info for 32-bit processes.

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".

 

[rconn]

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".

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.)