Tlist and Kill pick up where Task Manager leaves off
I often notice that Windows 9x has many benefits over Windows NT. For example, Win9x lets you easily handle PC Cards and PCI cards; in fact, you can handle most hardware more easily in Win9x than you can in NT. In addition, most popular games don't run under NT, and those that do run badly. Yet, most applications that run on NT also run on Win9x. So occasionally I ask myself why I use NT.
Then I remember why. NT is far better at multitasking and is more stable than Win9x. NT gives me more control over my system. And when a process goes awry, NT lets me use Task Manager to kill the process.
In my experience, Task Manager successfully ends troubled processes more often than does Win9x, which frequently locks up the system. But sometimes even Task Manager can't stop a process, presenting instead a dialog box saying The operation could not be completed. Access denied. As a systems administrator, I resent the system denying me access, so when Task Manager can't stop a process, I use the Microsoft Windows NT 4.0 Resource Kit's Tlist and Kill utilities.
Tlist and Kill have been around since the very first resource kit, so you might be familiar with the utilities. Tlist is a command-line utility that lists all tasks running on the computer on which you carry out the command. (To show the processes running on a different computer, you need to use the Pulist utility.) Run Tlist without options to list all the processes running, as well as the process identifier (PID). You need to use the PID to sic the Kill utility on a process.
Kill ends all instances of the process you specify. In its simplest form, Kill uses the syntax kill PID.
To end a process, first run Tlist to reveal the names and PIDs of all processes running on the server. Then run Kill, specifying the PID for the process you want to end. For example, to end a locked-up process named dbserver.exe, type
tlist
and determine Dbserver's PID. Assuming the PID is 306, you then type
kill 306
to stop the process.
Occasionally, Kill reports that it can't stop a process. In that case, you can bring out the big guns and add the -f option (i.e., kill -f PID). In my experience, the -f option always ends a process.
Kill's documentation explains that instead of providing a PID, you can simply specify the application's name, such as kill notepad.exe or even kill note*. However, Kill behaves a bit oddly when you kill a process by name rather than by PID. For example, when you specify the PID to kill a copy of Notepad that contains unsaved text, Notepad ends immediately. But if you type kill notepad.exe to kill Notepad, Notepad presents a dialog box asking you to confirm that you don't want to save the text before exiting. In this case, you can type kill -f notepad.exe to force Kill to ignore the message, and Notepad will shut down without a peep.
You can also use options with Tlist. The utility's -t option dumps process trees in addition to processes. For example, the -t option shows that the Windows Explorer process started the Microsoft Outlook process. You can also type
tlist <PID>
to list specific information about the specified process, such as how much memory it uses, which DLLs it employs, and the number of threads it has spawned.
Before the Task Manager became available in NT 4.0, Tlist and Kill were the only tools you could use to end a wayward process. Sometimes the oldest tools are the best tools.
End of Article
Register
- You can use the TLIST -t syntax to view process hierarchy. Some services run several processes and TLIST -t shows them. When the service and/or these processes encounters an error, the processes are not managed by the Service Control Manager. They are "orphean", and you cannot stop them without a KILL. The environment of the processes is visible (service's processes are under 'System'; interactive (i.e. in a user session) are under your shell process, i.e. Explorer)
- You can see, when multiple instances of the same EXE are running, which one is to kill, by viewing the the processe's command line
For example:
System Process (0)
System (2)
smss.exe (20)
csrss.exe (26)
WINLOGON.EXE (34)
SERVICES.EXE (40)
SPOOLSS.EXE (67)
RPCSS.EXE (88)
LSASS.EXE (43)
NDDEAGNT.EXE (102)
explorer.exe (105) Program Manager
CMD.EXE (115) cmd - tlist -t
TLIST.EXE (214)
OUTLOOK.EXE (116) Bo¯te de rÚception - Microsoft Outlook
MAPISP32.EXE (221)
CMD.EXE (120) cmd
USRMGR.EXE (236) User Manager - MEDERIC
I launched USRMGR in a command line: the second CMD process PID 220.
- the KILL command is sometimes ineffective: a dialog box (i.e. a handle or a thread) makes impossible to kill the process. You have to close the dialog box on the desktop interface.
- Many server (in the client-server meaning) processes uses 1 thread by client connection. It's useful to see if a user is still connected to this application. If a batch job uses the REMOTECMD service (Res. Kit), the folowing command let's you manage jobs (= not shuting down the remotecmd) that are likely to run in the same time
- OH and NTHandle are 2 good tools more precise than TLIST to see handles, and by the way, locks on files or other resources. PULIST may help too, it gives you a remote process' list.
A sample batch:
rcmd \\myserver c:\admin\oh -t file myprocess>>c:\temp\result.txt
set rcm_state=
rcmd \\myserver "c:\admin\tlist rcmdsvc | FINDSTR NumberOfThreads" > nb_thread
findstr /C:"NumberOfThreads: 3" nb_thread
if %ERRORLEVEL%==0 set rcm_state=in_use
if "%rcm_state%"=="in_use" (sc \\neui3 query remotecmd) & (echo service remotecmd stopped))
if "%rcm_state%"=="" echo An other job is running, remotecmd stay running
RCMD, REMOTECMD (process rcmdsvc.exe), PULIST and OH are Resource Kit tools.
Long life to W2000 Mag!
David Davant April 06, 2000