Regaining Control of a Computer that Has Stopped Responding

By Brien M. Posey, MCSE for TechRepublic.com

Imagine that it's 11:30 on a Friday night. You're wrapping up a hard day's work by putting the finishing touches on a Microsoft® Word document that your boss wants on his desk first thing Monday morning. Without warning, your computer stops responding. You begin to feel nauseated, when you realize that it's been two hours since you last saved your work. The thought of having to stay at the office for two more hours retyping your work is unbearable.

For those of you who are workaholics, this situation may be all too real. Let's face it, contrary to popular myth, computers aren't perfect, and neither are operating systems or application software. Fortunately, if your computer stops responding for no apparent reason and you are running Windows NT® Workstation, there are things you can do to fight back and recover your hard work. In this article, we'll show you what to do if your computer stops responding unexpectedly.

On This Page

Anatomy of a Response Failure
Why Did the Response Failure Happen?
Applications
Memory Management
When the Cause of the Response Failure Isn't Obvious
Loss of Connectivity
A Last Resort
Conclusion

Anatomy of a Response Failure

Before you can understand the recovery procedure for when your computer stops responding, it's important to understand why recovery is possible in the first place. In the days of MS-DOS®, people usually ran only one program at a time. That program ran on top of a relatively simple command interpreter and a limited number of device drivers. If the program stopped responding, it was usually a lost cause because the operating system (MS-DOS) wasn't sophisticated enough to allow you to make any adjustments to the system's memory while your program was running. Therefore, if the situation described at the beginning of this article happened to you while working in an MS-DOS environment, you'd probably lose all of your hard work.

However, Microsoft Windows NT Workstation is much more sophisticated than MS-DOS. The Windows NT operating system consists of one main module called the kernel. The kernel controls dozens of other operating system modules, such as services and device drivers. Each service and device driver must be assigned a specific amount of processing time, or the operating system won't function smoothly. Likewise, Windows NT also assigns a certain amount of processor time to any applications that you may be running.

For Windows NT to completely stop responding, the kernel must malfunction. However, on a computer that conforms to the Windows NT Hardware Compatibility List, kernel-level failures are very rare. More often, one application, device driver, or service will stop responding. Many times, this will give the illusion that the entire system is failing to respond. In these cases, if you can force the code responsible for the failure to terminate, you can regain control of the system.

Your ability to recover from a response failure depends on whether the kernel is malfunctioning. But how can you tell? One good indication is your mouse pointer. Although not a totally reliable test, if you can still move your mouse pointer, chances are good that the kernel is functioning properly.

Why Did the Response Failure Happen?

Once you've determined that the kernel is probably working correctly, you must determine what caused the response failure in the first place. To do so, press CTRL+ALT+DELETE. When you see the Windows NT Security dialog box, click the Task Manager button. When you do, you'll see the Windows NT Task Manager's Processes tab, as shown in Figure A.

Figure A: The Processes tab allows you to see how much processor time is being dedicated to each application and system component.

As you can see in Figure A, you'll see a processor ID number (PID) and percentage of CPU time (CPU) for each module. On a machine that's functioning correctly, the System Idle Process should show a number of 80 or above in the CPU column. This column shows the percentage of each processor cycle that's been dedicated to a specific module. Although it's normal for the System Idle Process to occasionally fall well below 80 percent, the average System Idle Process should remain at or above 80 percent. If your System Idle Process is staying consistently below 80 percent, scroll through the list to see what's occupying your processor time. If you find one particular module that's taking up a lot of processor time, you can terminate it by selecting the application and clicking the End Process button.

When you terminate a process, the process may terminate immediately, or it may wait for 20 seconds and present you with a dialog box asking if you really want to terminate the process. Sometimes a permission problem or an open file may prevent you from terminating a process at all. If this happens, you can use the Kill.exe utility from the Windows NT Resource Kit to force the process to terminate. From the Create New Task dialog box (shown in Figure D) imply use the /F switch and the process' PID number with the KILL command, and you can terminate almost any process. It's important to point out though, that killing some system processes will cause the kernel to crash, resulting in a 'Blue Screen of Death'.

Applications

If you don't find a process that's consuming a large amount of processor time, one of the programs you're running may be locking up the system. To check the status of your applications, click the Windows NT Task Manager's Applications tab, shown in Figure B.

Figure B: The Applications tab shows the status of all running application software.

Under normal circumstances, all programs shown on the Applications tab should show a status of Running. If an application shows a status of Not Responding, it's probably the cause of your problem. You can select this application and click the End Task button. Again, the task may end immediately, or it may wait for 20 seconds and present you with a confirmation dialog box.

Keep in mind that when you terminate an application, you'll lose any unsaved data that may be open within the application. Therefore, if the program that's not responding is the one that you're trying to salvage data from, you should try a few more options before terminating it.

Memory Management

Before terminating an application containing unsaved data, you should hunt for clues as to why the application may not be responding. The best place to initially check is the Windows NT Task Manager's Performance tab, shown in Figure C.

Figure C: The Performance tab provides clues to your computer's memory and processor usage.

Notice in Figure C that our CPU Usage is excessively high. In this particular example, the usage is only high because of the overhead involved in obtaining the screen capture. You can see this by looking at the CPU Usage History. Our CPU Usage History shows very low average processor use until it suddenly increased when we obtained the screen capture, shown on the very far right of the CPU Usage History graph. Had our average processor use been high though, it would be a good indication that perhaps the program in question isn't actually locked up, but rather is performing a complex function that will complete in time, or is caught in an infinite loop.

You can also check the MEM Usage and the Memory Usage History for excessively high memory usage. If your computer seems to be using an unreasonable amount of memory, your page file may be too small, or you may be low on hard disk space on the volume containing the page file.

When the Cause of the Response Failure Isn't Obvious

If you still haven't resolved the response failure problem, you may have a general idea of what's wrong but are unsure of the next step. Or, you may still be clueless as to why your computer has stopped responding. For example, you might suspect that the computer has run critically low on hard disk space but aren't sure how to verify it, since your desktop still fails to respond.

The key to proceeding beyond this point is to regain limited control over your system and then work to resolve the response failure on the rest of your computer. Doing so is easier than you might think. Simply go to the Windows NT Task Manager, and select the New Task (Run) command from the File menu. When you do, you'll see the Create New Task dialog box, shown in Figure D.

Figure D: The Create New Task dialog box allows you to run programs—even when Windows Explorer isn't functioning correctly.

In many cases, even if Windows Explorer isn't correctly functioning, you can launch a program from this dialog box. For example, earlier we mentioned that sometimes it might be necessary to use the Kill.exe program to terminate a process. If your system is locked up, there's a good chance that you can still run the Kill.exe program via the Create New Task dialog box.

Needless to say, the ability to run new programs is invaluable during response failure situations. For example, suppose you suspected that a certain service was causing your problem. You could type control and press Enter at the command prompt to launch Control Panel. You could then use the Control Panel to access the Service Control Manager and determine which service was causing your problem.

Loss of Connectivity

It's important to point out that if a program stops responding, or starts behaving erratically, it's not always caused by a problem with your computer. A loss of network connectivity can cause such problems. For example, a program may appear to stop responding or malfunction if you're trying to edit a file that's stored on a network share if the server containing the file has gone offline. If you have partial control over a program but can't save your data, try saving to an alternate location, such as your hard disk, a floppy disk, or other removable media. If you still have difficulty saving, keep in mind that the permissions set on the local workstation may prevent you from saving to the hard disk. You should try saving to removable media since it's rarely restricted.

A Last Resort

In spite of the techniques that we've shown you, sometimes it's impossible to recover from a response failure. Fortunately, there are steps you can take to prevent data loss in such situations. For example, the Microsoft Office 97 suite contains options for automatic recovery.

Auto recovery saves a backup copy of your work at intervals that you specify. For example, suppose you set the automatic recovery threshold to five minutes. By doing so, Office would back up your work every five minutes. In the event of a power failure, response failure, or system crash, you'd never lose more than five minutes worth of work.

To set the automatic recovery option, select the Options command from the Tools menu in any Microsoft Office 97 product. When you see the Options properties sheet, click the Save tab. Next, simply set the options shown in Figure E.

Figure E: Microsoft Office's automatic recovery feature can prevent you from losing work in the event of an unrecoverable system failure.

Many other software applications offer similar automatic recovery options. For information on the existence and use of such a feature, consult the user's manuals that came with your software applications.

Conclusion

Although it's impossible to recover from some system failures, if your mouse pointer still moves, there's a good chance that you may be able to revive your system without data loss. In this article, we've demonstrated steps you can take when your system stops responding unexpectedly.

Brien M. Posey is an MCSE and a freelance technical writer. He also works as a network engineer for the Department of Defense. You can contact him at Brien_Posey@xpressions.com. (Because of the large volume of e-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.