Another useful utility is dumpexam.exe, which converts the memory file into a readable text
file. You need three files to run dumpexam: dumpexam.exe, imagehlp.dll, and for the Intel platform,
kdextx86.dll (the third file depends on the platform). The three files must be in the same
directory. You can find them on the CD-ROM of the NT Server or the NT Workstation CD-ROM in the
directory \support\debug\<platform>, where platform is i386, alpha, mips, or ppc.
The noninteractive debugging method is ideal for users who don't want to debug the driver, but
just want to figure out which one is at fault. To run dumpexam, you need to load the symbol files,
which contain NT system debugging information. Make sure that the symbol files are for the version
of NT you're running, including any installed service packs. For the Intel version of NT, the symbol
files are in the \support\debug\i386\symbols directory on the NT resource kits' CD-ROMs
Figure 2 shows the syntax for dumpexam. For example, if you want to analyze a dump file for a
computer with NT Workstation 4.0, the symbols are in the directory d:\symbols. The dump file,
server.dmp, is in the directory d:\dump. The command line reads
dumpexam -y d:\symbols d:\dump\server.dmp
The results of the exam will be in %SystemRoot%\MEMORY.TXT.
Interactive debugging. The other method of debugging is interactive debugging.
Device driver developers, rather than systems administrators, usually prefer interactive debugging
because the process requires extensive knowledge of NT internals.
Interactive debugging requires you to have another PC (a host machine) with NT installed and to
run the kernel debugger on the host machine. It must be running the same version of NT as the target
machine. The host machine must be connected to the problem computer via a modem or null cable
connection.
Is the System Safe?
Can you safely use the system after a kernel STOP error? The answer depends on whether you can
isolate what caused the problem. I've seen cases where the error condition happens once, never to
repeat again. In other cases, however, the error occurs after the user has installed or updated a
driver. In this case, you need to remove the driver and start over. When you get the kernel STOP
error, reboot the system, and hit the space bar when you see the Last Known Good text. This action
starts NT with the last known working configuration, without the offending driver. The option of
reverting to the last known working configuration reinforces the wisdom of installing one driver at
a time and making sure that the driver works before you install another driver. If the driver
doesn't work correctly, you can revert to the previous working configuration. If you install two or
more drivers at the same time and one of them causes a problem, you will have trouble determining
which driver caused the problem.
If the problem is not related to a driver, look at new system hardware, such as a new
controller card. To determine whether a controller card is the problem, remove the card and test the
system again. If the problem goes away, check whether the card (or any new hardware you add to your
system) is in the Microsoft Hardware Compatibility List (HCL). TechNet and Microsoft's Web site
(http://www.microsoft.com) have an up-to-date list.
The Bottom Line
I hope that, after reading this article, the blue screen won't intimidate you. Using the
techniques I've explained, you can find out, in general, why you got the screen and perhaps tell
specifically what caused the problem. If you aren't a device driver developer and don't want to deal
with interactive system debugging, noninteractive is the way to go. Your goal is to get your system
up and running as fast as possible. Isolating the problem is the first step. For additional
resources, see the sidebar, "Other Sources of Help."
Other Sources of Help
Microsoft TechNet CD-ROMs
contain the Microsoft Knowledge Base (the same library that Microsoft Product Support
Specialists use), resource kits, and educational materials.
Microsoft Network (MSN) and CompuServe
have several Microsoft forums where you can post questions and obtain answers.
Microsoft Download Library (MSDL)
is an electronic bulletin board system (BBS) from which you can download drivers and other
software. The phone number for MSDL is 206-936-6735.
Microsoft Web Site (http://www.microsoft.com)
contains product information, drivers, service packs, and more.
As the article notes, if the problem driver is a Microsoft driver, you can send the dump file to
Microsoft for analysis. If the driver is from a third-party manufacturer, you can send the memory
file to that manufacturer.
)
Register
The only problem is that much of what they’ll learn from this article is wrong. The article is absolutely rife with technical errors. For example, the second sentence in the section headed “What Does This Weird Screen Mean?” reads, “The kernel STOP may mean that a kernel driver ... has illegally accessed the privileged kernel area.” This statement is very close to meaningless, and any meaning I can attach to it is wrong. Kernel drivers are privileged (i.e., they run in kernel mode) and have full access to the kernel area.<br>
Another example? Let’s take Table 1: Kernel Mode Error Conditions. The first entry for IRQL_NOT_LESS_OR_EQUAL tells the reader, “A process attempted to access pageable memory at a process internal request level (IRQL) that was too high.” That statement is one reason for getting this error. But it’s not the reason.<br>
The text continues, “A process can access only objects that have priorities (IRQL) equal to or lower than its own.” This statement is nonsense. Objects don’t have IRQLs. IRQLs are not typically associated with processes (with one exception). The IRQL indicates the CPU state at any point in time, relative to that CPU’s interruptability, preemptability, and dispatchability. That is, the IRQL identifies which devices can interrupt the CPU, whether at the end of a quantum the current thread will be rescheduled, and whether any scheduling operations at all are allowable.<br>
Yikes! I found plenty of other technical problems in the article, too.<br>
I’ve spent lots of time reading blue screens and debugging drivers, so I recognized the problems with this article. How many of your readers can say the same? <br>
--Peter G. Viscarola<br><br>
<i>Thanks, Peter, for pointing out these problems. We’ll be very careful not to let such errors slip by in the future, and we apologize for any inconvenience these errors may have caused anyone.<br>
--Karen Forster</i>
Peter G. Viscarola August 13, 1999