Of course, you can get this same information from the blue screen dump, if the user remembered to write it down. But, if the user didn’t take notes, the most important informational sources are the MajorVersion, MinorVersion, MachineImageType, Number of Processors, BugCheckCode, and the four parameters (BugCheckParameter1 through BugCheckParameter4). This information can tell you what version of NT is in use, what platform NT is running on, what the stop code was, and the stop code parameters. In the preceding example, the error is a 0x0000007a/KERNEL_DATA_INPAGE_ ERROR. The first parameter is the address of the PTE, the second parameter is an I/O status code, the third parameter is the current process of the PTE, and the fourth parameter is the virtual address that could not be read.

If you are a Windows NT developer and familiar with the Windows NT APIs, you can use the Windows NT kernel debugger to examine the memory dump file. For an Intel processor, the kernel debugger is called I386KD.EXE, for an Alpha processor it is called ALPHAKD.EXE, for a MIPS processor it is called MIPSKD.EXE, and for a PowerPC processor it is called PPCKD.EXE. Before you can use the kernel debugger, you have to set an environment variable to inform the debugger where the symbol files are located. You can accomplish this with the command

SET_NT_SYMBOL_PATH=C:\WINNT\SYMBOLS

if you installed the symbols into the default path. Otherwise, you will need to change the path for the set command. Once you have done this, you can load the dump file using the command

I386KD –z Path\Memory.DMP

where Path is the drive and path to the MEMORY.DMP file. I’m not going to go into all the gory details on how to examine a core dump, because, for most people, this type of work far exceeds the desire to accomplish it. Only the most technical-minded developers ever bother with a core dump. The main reason for discussing the core dump thus far is to obtain the stop error code and to prepare a dump file to be sent out to your technical support personnel. This technical support contact might be a hotshot device driver developer within your own organization, or it might be a member of the Microsoft Product Support Service (PSS) group. In either case, you can save a great deal of time and effort by verifying the dump file before you send it out.

---

One reference I have found quite useful for those with a desire to dig into the core dump can be found at the Microsoft Web site. For example, check out the Knowledge Base article Q148661, which can be found at www.microsoft.com/kb/articles/q148/6/61.htm This is a basic article on how to use the kernel debugger to examine a stack trace.

---

Summary

This chapter might have been too much for you, but I hope you gained at least a little more familiarity with the “Blue Screen Of Death.” Hopefully, you learned a bit about how to interpret a stop error code and make meaningful sense out of it. With the large listing of the more common error codes, you should be able to gain some insight into what might have caused a stop error in the first place. You also learned how to verify a memory dump file in preparation to send it off to your technical support personnel. The information presented in this chapter can help even the most technically challenged administrators to perform their jobs a little better and demystify the bunk behind the “Blue Screen Of Death.” But, most of all, keep in mind that a bit of humor in a Blue Screen situation can help you cope with the problem.