Saving and Viewing Event Log Files
The act of clearing events from a log is a destructive process. Once you clear them, you can’t retrieve them. Likewise, when old events are overwritten as new ones are added to the log, the old events are lost forever. So, you may want to save event logs to disk. Here’s how:
Select the log that you want to save by clicking either System, Security, or Application on the Log menu.
If you simply want to save the current event log without deleting existing events, click Save As on the Log menu and go to step 5.
On the Log menu, click Clear All Events.
Click Yes to confirm that you want to save the log before clearing it.
In the Save as type list, select Event Log Files (which can be viewed later with Event Viewer), Text Files, or Comma-Delim. Text. Type or select the filename that you want to use and click Save.
Note that binary event log data is dropped from text files.
Tip: If you want a printed copy of a log file for future reference, save it as comma-delimited text and then print that file. If you plan on viewing a log later with Event Viewer, save it in event log format. You can always save it again as text if you want to print it.
To view a saved event log file, click Open on the Log menu, specify the file and click Open. In the Open File Type dialog box, click the type of log that the file represents: System, Security, or Application. The saved file doesn’t include the type of the original log. If you select the wrong type, the detailed descriptions of the events will probably be incorrect.
Employing Dr. Watson
Dr. Watson has been unemployed ever since Sherlock Holmes stopped solving cases. It’s time to put him back to work. Dr. Watson is NT’s post-mortem debugger for Win32 applications. (If you’re familiar with Windows 3.1, its Dr. Watson utility performed a similar function for Win16 applications.) It can be a valuable troubleshooting tool if you’re getting exception conditions in applications supplied with NT, third-party applications, or applications that you’re developing in-house. In the first two cases, it provides valuable information that you can share with product support personnel over the phone or electronically.
Note: Unless you’re proficient with assembly language and Win32 programming, the information supplied by Dr. Watson won’t make much sense to you. It’s valuable, however, to whoever developed the offending Win32 application.
If a Win32 application generates an exception, Dr. Watson will catch it, generate a detailed log file, and log an event in the NT event log. The detailed file, which is stored by default in SystemRoot\DRWTSN32.LOG, includes system configuration information, a list of applications that were running at the time of the exception, details of the exception, and the state of each thread.
Dr. Watson is enabled by default when you install Windows NT, even though it doesn’t appear as an icon on the Task Manager list of processes. It operates completely invisibly until a Win32 application error occurs.
Here’s how to configure Dr. Watson’s diagnostic behavior:
Click Start Run. Type DRWTSN32 and click OK.
You’ll see the Dr. Watson for Windows NT dialog box as shown in Figure 12-10.
In the Log File Path field, type the path of the folder where you want the DRWTSN32.LOG file written.
Tip: The folder into which Dr. Watson writes his logs must be accessible for read and write by all users of the computer. Rather than giving write permissions to the SystemRoot folder to all of your user accounts, I recommend creating a separate folder somewhere for these log files. You can grant read and write permissions to the special Everyone group and configure Dr. Watson to write his log files in the new location. That way, you can protect your SystemRoot directory.
Dr. Watson can optionally create a crash dump file that contains a snapshot of the failed process. This file can be examined by a software engineer using the NT debugger to determine what went wrong with the application. If you want to create a dump file, click to select the Create Crash Dump File checkbox. In the Crash Dump field, type the full path name of the dump file that you want to create. I recommend using the same folder as you did for Log File Path.
Note: If you have a sound card installed and configured in the computer and you click to select the Sound Notification check box, you can type the name of a .WAV file in the Wave File field. Every time that Dr. Watson catches a Win32 application error, the wave file will play. I’ve seen administrators assign screams, trumpets, and the ever popular “Uh-Oh” sounds to these grim events.
In the Number of Instructions field, type the number of assembly language instructions that you want Dr. Watson to disassemble before and after the place in the code where the exception occurred.
In the Number of Errors To Save field, type the number of Win32 application errors that you want saved in the log file.
If the number of errors exceeds this threshold, the oldest error in the log will be discarded.
If you want Dr. Watson to include the symbol table in the log file, click to select the Dump Symbol Table check box.
A symbol table dump can make your log file huge. I recommend avoiding this option, unless the application vendor requests that you include it in the log.
Click to select the Dump All Thread Contexts, Append to Existing Log File, and Visual Notification check boxes.
I recommend selecting each of these options. The log file needs to contain information about what each thread was doing when the exception occurred. It’s always best to append to your existing log file, so that you don’t lose the previous error information. You need to be notified visually, or the offending Win32 application will just quietly disappear.
Under Application Errors in the Dr. Watson for Windows NT dialog box, you can scan though the existing errors in the log. Click View to view the details of individual errors. Click Clear to clear all of the errors from the log.
Dumping Registry Subkeys
There may be times when you need to study the contents of a registry subtree (a key and everything stored under it). You can dump a registry subtree to a text file or to the printer. In Registry Editor (described in Chapter 11), select the key that you want to save or print as text. If you want to save the subtree to a text file, click Save Subtree As on the Registry menu, specify the filename, and click Save. If you want to print the subtree, click Print Subtree on the Registry menu.
Managing Memory Dump Files
As discussed in the Chapter 8 section called “Managing Crash Recovery,” you can cause Windows NT to dump an image of memory to a file when it crashes. The memory dump file can then be analyzed off-line by support personnel to determine what caused the problem. (In Microsoft documentation and other sources, you’ll see many terms used to describe a crash: kernel STOP error, blue screen, Blue Screen of Death, kernel error, and trap.)
Tip: If you take the approach of automatically dumping and immediately restarting the server, be sure to rename the MEMORY.DMP file after each system crash. Otherwise, the next crash will overwrite the existing MEMORY.DMP file, and you’ll lose the information from the previous crash.
The size of a memory dump file is equal to the size of your computer’s physical memory. A 64MB RAM size will produce a 64MB dump file. Transmitting a file of this size can sometimes pose a logistical problem. On the Windows NT Server CD-ROM in the \SUPPORT\DEBUG folder, Microsoft has included some utilities to help manage these huge files. Look in the subfolder that matches your CPU platform for the actual utility files. For example, \SUPPORT\DEBUG\I386 contains the Intel executables.
Before you go to the trouble of analyzing or transmitting a huge dump file, it’s wise to verify that a valid dump file was, in fact, created. You can do this using the DUMPCHK utility. DUMPCHK analyzes all of the addresses in the dump file to make sure that they’re valid. At a Command Prompt, type DUMPCHK /? for its command-line syntax.
Microsoft supplies DUMPEXAM to allow you to analyze memory dump files, generating a summary into a text file that can be used by support personnel to determine the cause of the system crash. (DUMPEXAM sounds to me like a test that you have to pass before you can manage a landfill.) Usually the output of DUMPEXAM provides all of the information that’s needed to diagnose the problem, saving you the hassle of shipping the entire dump file for analysis. It’s easiest to run DUMPEXAM right from the NT Server CD-ROM. At a Command Prompt, type DUMPEXAM /? for command line syntax. This utility collects debug symbol information (API names and global variable names) from symbol files in the SYMBOLS subfolder on the CD-ROM. It uses these symbols to make the dump analysis more meaningful.
If DUMPEXAM’s output doesn’t provide enough information to diagnose the computer’s problems, you may need to ship the entire dump file to support personnel on floppy disks. Believe me, I don’t envy you this tedious procedure. But if you have to do it, at least Microsoft has made the job easier by providing you with the DUMPFLOP utility. It compresses the data as it writes to each floppy, using about half as many disks as would be required for the uncompressed dump file. (That’s a small comfort if you have to create 23 disks for a 64MB computer.) At a Command Prompt, type DUMPFLOP /? for command-line syntax.
The CRASHDUMP Aftermath
When you first boot after a dump is taken, a process called SAVEDUMP will execute. Its job is to save the dump in a file so that, if another crash occurs, the first dump won’t be lost. If your server has lots of RAM, this copy process can take awhile. During this period, the process can eat up huge amounts of memory, and you may get warnings that you’re running low on that commodity. It’s wisest just to let the copy complete before trying to do anything useful on the computer.
Sniffing for Trouble with Network Monitor
Windows NT Server 4.0 is the first version to include a copy of the Network Monitor utility that enables your computer to act as a network sniffer. Network Monitor used to be available only as part Microsoft’s Systems Management Server (SMS).
Teaching you how to interpret the contents of network packets as they fly by on the wire is beyond the scope of this book. If you’re already experienced with network sniffers, you’ll be productive with Network Monitor right away. Even if you don’t have this expertise, though, you can use some of the statistical features of Network Monitor for general troubleshooting.
Here’s how to install Network Monitor from your Windows NT Server 4.0 CD-ROM:
While logged on with administrator privileges, click Start Settings Control Panel. Double-click Network to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Services tab. Then click Add.
Under Network Service, click Network Monitor Tools and Agent. Then click OK.
NCPA asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Insert the NT CD-ROM in your CD-ROM drive. Type the path and click Continue.
On my computer, the path is F:\I386. Type the drive letter of your CD-ROM and the subdirectory corresponding to your CPU platform.
In the Network dialog box, click Close.
Restart your computer as prompted.
After your computer has restarted, you can run Network Monitor by clicking Start Programs Administrative Tools Network Monitor. To see it in action, on the Capture menu, click Start. If there’s much network activity, you’ll see the bar graphs and statistics dynamically change to reflect it, as shown in Figure 12-11.
Network Monitor is a feature-rich tool. You can capture data from the network, save it to a file for later analysis, define a trigger condition to start a capture, and filter both the captured and displayed data. You can even detect other Network Monitor installations on the network.
Like other network sniffers, the tool interprets (or parses) the packets for you, so you don’t necessarily have to translate the individual bytes of the packet. However, you do need to have in-depth knowledge of the information transmitted in each protocol to interpret what you’re seeing successfully, even after it’s been translated. Microsoft includes parsers for a slew of network protocols. You can see a list of them by clicking Options Default Parsers Yes and scrolling through the Enabled Protocol Parsers list. When you’re done looking at the list, click Cancel.
Caution: Don’t disable any of the protocol parsers listed in the Protocol Parsers dialog box, unless you’re absolutely sure what you’re doing. Disabling a parser can have downstream effects on other parsers.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
Settings 
