Troubleshooting Windows 10
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, type reliability 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.