As they say, stuff happens. That might not be exactly how the famous quote goes, but it’s certainly true whenever hardware and software are involved.
Although Windows has generally become more stable and reliable over time, it will never be perfect. Apps hang (stop responding) or crash (shut down unexpectedly). Once in a while, a feature of Windows walks off the job without warning. And on rare occasions, the grim BSOD (“blue screen of death,” more formally known as a Stop error or bugcheck) arrives, bringing your whole system to a halt.
In a fully debugged, perfect world, such occurrences would never darken your computer screen. But you don’t live there, and neither do we. So the prudent course is to prepare for the unexpected. That starts with making regular backups, of course, along with system restore points. But it also entails learning to use the many tools that Windows provides for diagnosing errors and recovering from problems. Those tools are the subject of this chapter.
- For information about creating regular backups and image backups as well as information about system restore points, see Chapter 16, “Backup, restore, and recovery.”
Getting to know your troubleshooting toolkit
As any detective will tell you, solving a mystery requires evidence. If your mystery involves inexplicably slow performance or crashes, you have several places to look for clues.
The most obvious first step on the road to resolving performance issues is the aptly named Troubleshooting section in the classic Control Panel. By default, it displays a list of the most commonly used troubleshooters included with Windows 10, as shown in Figure 17-1.
Figure 17-1 Each of the troubleshooters included with Windows 10 launches an interactive problem-solving tool that steps you through diagnosis and resolution of common problems.
Click the View All link on the left of the Troubleshooting page to see an expanded list that includes modules for fixing more esoteric problems, such as issues with search and indexing or with the Background Intelligent Transfer Service.
There’s nothing magical about any of these troubleshooters. Their purpose is to ensure that you check the most common causes of problems, including some that might seem obvious (Is the network cable plugged in? Is the printer turned on?). Running a troubleshooter can result in easy fixes for some issues; more importantly, it establishes a baseline for further troubleshooting.
A troubleshooter might lead you through several steps and ask you to check settings or connections. At the end, it displays its results, which include a View Detailed Information link that displays a troubleshooting report similar to the one shown in Figure 17-2.
Figure 17-2 The troubleshooting report lists issues and indicates whether they were fixed. Click the Detection Details link to see more granular information about that item.
Windows Error Reporting
Often an early indication that something is amiss is an error message informing you that an application is “not responding”—as if you hadn’t figured that out already. If the application doesn’t come back to life, you kill the process with Task Manager and move on, ideally without losing any data.
While all that’s happening, the Windows Error Reporting (WER) service runs continuously in the background, keeping track of software and driver installations (successful and otherwise) as well as crashes, hangs, and other system events that indicate a possible problem with Windows. (In fact, although the service and programs that enable the feature are called Windows Error Reporting, the term you’re more likely to see in Windows is problem reporting.) Microsoft provides this diagnostic information to the developers of the program that caused the error (including Microsoft developers when the issue occurs with a feature in Windows, Office, or another Microsoft program). The goal, of course, is to improve quality by identifying problems and delivering fixes through Windows Update.
In previous versions, Windows was downright chatty about reporting crashes, successful updates, and minor speed bumps. In Windows 10, most of these problem reports (including diagnostic reports sent after successful upgrades) are completely silent, but each report is logged. You can use the history of problem reports on a system to review events and to see whether any patterns demand additional troubleshooting.
To open the Problem Reports log, type problem reports in the search box and then click View All Problem Reports. Figure 17-3 shows a portion of the error history for a computer that was upgraded to Windows 10 in the first month after it was available.
Figure 17-3 The list of saved problem reports displays only the two most recent reports in each group; click More to see earlier reports.
If the words Solution Available appear in the Status column for an item, right-click that item and then click View Solution. Note also that the shortcut menu includes commands to group the entries in the list of problem reports by source (the default view, shown in Figure 17-3), summary, date, or status—or you can choose Ungroup to see the entire, uncategorized list. With the list grouped or not, you can sort by any field by clicking the field’s column heading.
You can see a more detailed report about any event in this log by double-clicking the event. The Description field is usually written clearly enough to provide potentially useful information. The rest of the details might or might not be meaningful to you, but they could be helpful to a support technician. Some reports include additional details sent in a text file that you can inspect for yourself. In Figure 17-4, for example, a file called WERInternalMetadata.xml captures information about the Windows installation and its memory use. None of this information is personal or linked to your PC.
Figure 17-4 You can review the contents of a problem report, including any additional information sent as file attachments, before or after it’s sent.
By default, Windows 10 configures your system so that it sends a generous amount of diagnostic and feedback information, including error reports that could inadvertently contain personal information. If you are concerned about data use or privacy, you can dial back the amount of diagnostic information by using the Feedback & Diagnostics page under the Privacy heading in Settings. Figure 17-5 shows the default settings.
Figure 17-5 If you’re concerned about sensitive data leaking out as part of diagnostic reports, consider changing the Diagnostic And Usage Data setting from its default of Full.
The Feedback Frequency setting at the top of this page controls how often Microsoft asks you about your use of features. If you prefer to be left alone, set this to Never.
The second heading, Diagnostic And Usage Data, allows you to specify how much diagnostic information your Windows 10 device sends to Microsoft servers as part of its normal operation. Much of that information is from problem reports, which rarely mean much by themselves but can be tremendously important as part of a larger data set to pinpoint the cause of problems. There are three available settings:
- Basic. This level includes data that is fundamental to the operation of Windows and Windows Update. It includes information about the capabilities of your device, what is installed, and whether Windows is operating correctly (which includes sending basic error reports to Microsoft). No personally identifiable information is included.
- Enhanced. Along with the data sent with the Basic setting, this setting adds data about how you use Windows (how often you use certain features or apps, for example) and collects enhanced diagnostic information, such as the memory state of your device when a system or app crash occurs. Information sent to Microsoft also includes reliability data for devices, the operating system, and apps.
The basic report that Windows Error Reporting transmits typically includes information such as the application name and version, module name and version, exception (error) code, and offset. Hardware reports include Plug and Play IDs, driver versions, and other system details. The likelihood that any of these items will convey personally identifiable information is essentially nil. The process does transmit your IP address to a Microsoft server, but Microsoft’s privacy statement asserts that the IP address is used only to generate aggregate statistics and will not be used to identify you.
In work environments, your network administrators will almost certainly disable the sending of advanced error reports that might inadvertently disclose confidential information.
If privacy is a major concern, you should, of course, read Microsoft’s privacy statement for this feature, which is available at bit.ly/win10-feedback-privacy. Although most people are understandably reluctant to send information to a faceless corporation, remember that this is a two-way street. You’re sending information about a problem, and there’s a good chance that, in return, you’ll receive a solution to the problem, as explained in the next section. (Remember, too, that the engineers who analyze the problem information to develop solutions are not faceless!)
Windows 10 keeps track of a wide range of system events. For a day-by-day inventory of these events, typereliability in the search box and then click the top result, View Reliability History. That opens Reliability Monitor, shown in Figure 17-6.
Figure 17-6 Reliability Monitor rates your system’s stability on a scale of 1 (wear a crash helmet) through 10 (smooth sailing). This PC has had a rough week.
Each column in the graphical display represents events of a particular day (or week, if you click that option in the upper left corner). Each red X along the first three lines below the graph (the various “Failures” lines) indicates a day on which problems occurred. The “Warnings” line describes minor problems unrelated to system reliability, such as a program whose installation process didn’t complete properly. The last line below the graph—the line marked Information—identifies days on which an app or an update was installed or removed. You can see the details about the events of any day by clicking on the graph for that day. Reliability Monitor retains its system stability records for one year, giving you plenty of history to review.
This history is most useful when you begin experiencing a new problem and are trying to track down its cause. Examine the critical events for the period when the problem began, and see whether they correspond with an informational item, such as a program installation. The alignment of these events could be mere coincidence, but it could also represent the first appearance of a long-term problem. Conjunctions of this sort are worth examining. If you think a new software application has destabilized your system, you can try uninstalling it.
Double-clicking any item exposes its contents, which are filled with technical details that are potentially useful, confusing, or both.
Although the various signatures and details for each such incident by themselves are probably just baffling, they’re much more useful in the aggregate. Armed with a collection of similar reports, an engineer can pin down the cause of a problem and deliver a bug fix. If a previously common error suddenly stops appearing in the logs, chances are it was resolved with an update.
Note also that you can click the link in the Action column to take additional steps, such as searching for a solution or viewing the technical details of a particular event.
Technically, we should probably have included Event Viewer (Eventvwr.msc) in the previous section. It is, after all, just another troubleshooting tool. But we think that this, the most powerful of all the diagnostic tools in Windows 10, deserves its own section in this chapter.
In Windows, an event is any occurrence that is potentially noteworthy—to you, to other users, to the operating system, or to an application. Events are recorded by the Windows Event Log service, and their history is preserved in one of several log files, including Application, Security, Setup, System, and Forwarded Events. Event Viewer, a Microsoft Management Console (MMC) snap-in supplied with Windows, allows you to review and archive these event logs, as well as other logs created by the installation of certain applications and services.
You can examine the history of errors on your system by creating a filtered view of the Application log in Event Viewer. Why would you want to do this? The most likely reasons are to troubleshoot problems that have occurred, to keep an eye on your system to forestall problems, and to watch out for security breaches. If a device has failed, a disk has filled close to capacity, a program has crashed repeatedly, or some other critical difficulty has arisen, the information recorded in the event logs can help you—or a technical support specialist—figure out what’s wrong and what corrective steps are required.
To start Event Viewer, find it by searching for event and then click Event Viewer or View Event Logs in the search results. Figure 17-7 offers an overview of Event Viewer.
Figure 17-7 Event Viewer’s console tree (left) lists available logs and views; the details pane (center) displays information from the selected log or view; the Actions pane (right) provides a menu of tasks relevant to the current selection.
When you select the top-level folder in Event Viewer’s console tree, the details pane displays summary information, as shown in Figure 17-7. This view lets you see at a glance whether any significant events that might require your attention have occurred in the past hour, day, or week. You can expand each category to see the sources of events of that event type. Seeing a count of events of various types in various time periods is interesting—but not particularly useful in and of itself. If you see an unusually large number of recent errors from a particular source, for example, you might want to see the full list to determine whether a particular error needs closer examination. Right-click an event type or an event source under Summary Of Administrative Events, and then click View All Instances Of This Event, as shown here.
The resulting filtered list of events is drawn from multiple log files, sparing you from having to search in multiple places. Armed with this information, you can quickly scroll through and examine the details of each one, perhaps identifying a pattern or a common factor that will help you find the cause and, eventually, the cure for whatever is causing the event.
Types of events
As a glance at the console tree confirms, events are recorded in one of several logs. The following default logs are visible under the Windows Logs heading:
- Application. Application events are generated by applications, including programs you install, programs that are preinstalled with Windows, apps from the Windows Store, and operating system services. Program developers decide which events to record in the Application log and which to record in a program-specific log under Applications And Services Logs.
- Security. Security events include sign-in attempts (successful and failed) and attempts to use secured resources, such as an attempt to create, modify, or delete a file.
- Setup. Setup events are generated by application installations.
- System. System events are generated by Windows itself and by installed features, such as device drivers. If a driver fails to load when you start a Windows session, for example, that event is recorded in the System log.
- Forwarded Events. The Forwarded Events log contains events that have been gathered from other computers.
Under the Applications And Services Logs heading, you’ll find logs for individual applications and services. The other logs generally record events that are system-wide in nature, but each log in Applications And Services Logs records the events related only to a particular program or feature. The Applications And Services Logs folder contains a Microsoft\Windows folder, which in turn contains a folder for each of hundreds of features that are part of Windows 10. Each of these folders contains one or more logs.
Viewing logs and events
When you select a log or a custom view from the console tree, the details pane shows a list of associated events, in reverse chronological order, with each event occupying a single line. A preview pane below the list displays the contents of the saved event record. Figure 17-8 shows one such listing from the System log.
Figure 17-8 All the details you need for an individual event are visible in this preview pane. Double-click an event to see those same details in a separate window.
Each event is classified by severity level (more on that shortly) and has a date and time stamp. The Source column reports the application or Windows feature that generated the event, and each entry has an Event ID—a numerical value that you can use as part of the criteria when filtering for similar events or searching for solutions online. The Task Category column is provided for some events but is blank for many others.
Events in most log files are classified by severity, with one of three entries in the Level field: Error, Warning, or Information. Error events represent possible loss of data or functionality. Examples of errors include events related to a malfunctioning network adapter and loss of functionality caused by a device or service that doesn’t load at startup. Warning events represent less significant or less immediate problems than error events. Examples of warning events include a nearly full disk, a timeout by the network redirector, and data errors on local storage. Other events that Windows logs are identified as information events.
The Security log file uses two different icons to classify events: a key icon identifies Audit Success events, and a lock icon identifies Audit Failure events. Both types of events are classified as Information-level events; “Audit Success” and “Audit Failure” are stored in the Keywords field of the Security log file.
The preview pane shows information about the currently selected event. (Drag the split bar between the list and preview pane up to make the preview pane larger so that you can see more details, or double-click the event to open it in a separate dialog box that includes Next and Previous buttons and an option to copy the event to the Clipboard.)
The information you find in Event Viewer is evidence of things that happened in the past. Like any good detective, you have the task of using those clues to help identify possible issues. One hidden helper, located near the bottom of the Event Properties dialog box, is a link to more information online. Clicking this link opens a webpage that might provide more specific and detailed information about this particular combination of event source and event ID, including further action you might want to take in response to the event.
Filtering the log display
As you can see from a cursory look at your System log, events can pile up quickly, obscuring those generated by a particular source or those that occurred at a particular date and time. Sorting and grouping can help you to find that needle in a haystack, but to get the hay out of the way altogether, use filtering. With filtering, you can select events based on multiple criteria; all other events are hidden from view, making it much easier to focus on the items you currently care about.
To filter the currently displayed log or custom view, click Filter Current Log or Filter Current Custom View in the Actions pane on the right. A dialog box like the one shown in Figure 17-9 appears. To fully appreciate the flexibility of filtering, click the arrow by each filter. You can, for example, filter events from the past hour, 12 hours, day, week, month, or any custom time period you specify. In the Event Sources, Task Category, and Keywords boxes, you can type text to filter on (separate multiple items with commas), but you’ll probably find it easier to click the arrow and then click each of the items you want to include in your filtered view. In the Includes/Excludes Event IDs box, you can enter multiple ID numbers and number ranges, separated by commas; to exclude particular event IDs, precede their number with a minus sign.
Figure 17-9 If you don’t select any Event Level check boxes, Event Viewer includes all levels in the filtered results. Similarly, any other field you leave blank includes all events without regard to the value of that property.
Click OK to see the filtered list. If you want to save your criteria for reuse later, click Save Filter To Custom View in the Actions pane on the right. To restore the unfiltered list, in the Event Viewer window, click Clear Filter.