OS Troubleshooting

Use a structured method

Operating system problems are solved the same way as hardware and network problems: identify the problem, form a theory, test it, make a plan, fix, verify, document. The method itself is described in Hardware Troubleshooting and Network Troubleshooting; this page applies it to Windows, with notes on macOS and Linux where they differ.

Two questions solve a surprising share of tickets. First, what changed? An update last night, a new printer driver, a program the user installed, a disk that filled up. Second, who is affected? One user on one computer points to that computer or profile; everyone at once points to the network, a server or a pushed update. Ask both before opening any tool.

Before you change anything that could lose data — a reset, a reinstall, a repair of the disk — make sure the user's files are backed up. See Backup and Recovery.

Common symptoms

The table maps the symptoms a help desk sees most often to their usual causes and the first tools to reach for. The sections below explain each one.

Blue screens

A blue screen is Windows' stop error: the kernel halted because continuing could damage data. What it is and why it happens is covered in Hardware Troubleshooting. From the operating system side:

• Read the stop code, such as DRIVER_IRQL_NOT_LESS_OR_EQUAL or INACCESSIBLE_BOOT_DEVICE. Some screens also show What failed with the name of a driver file (.sys). Ask the user for a photo; the screen is gone after the restart.
• Look for a recent change: a driver or update installed just before the crashes started. Reliability Monitor shows both on one timeline.
• Look for a pattern: the same stop code and driver every time suggests that driver; different codes each time suggest hardware, so run a memory test (Windows Memory Diagnostic, mdsched) and check the disk.

Boot failures

Where the boot stops tells you where to look:

• "No boot device" or "Operating system not found" comes from the firmware, before Windows starts. Check that the firmware sees the disk at all and that the boot order is right (a forgotten USB stick is a classic cause). A disk missing from the firmware is a hardware problem.
• "BOOTMGR is missing" — seen on older computers that boot through legacy Basic Input/Output System (BIOS) firmware and a master boot record (MBR) disk — or an error naming winload.efi or winload.exe means the Windows boot files or boot configuration are damaged. Startup Repair is the first fix.
• INACCESSIBLE_BOOT_DEVICE means Windows started loading but lost access to its own disk — often after a storage controller setting such as AHCI (Advanced Host Controller Interface) versus redundant array of independent disks (RAID) mode was changed in the firmware, or after a storage driver update.
• A boot loop, where the computer restarts over and over or keeps showing Preparing Automatic Repair, often follows a failed update or driver. Use the recovery environment to uninstall the latest update or return to a restore point.

Slow performance

"My computer is slow" needs numbers. Open Task Manager (Ctrl+Shift+Esc), sort the Processes page by central processing unit (CPU), Memory and Disk, and look at the Performance page:

• One process at high CPU for minutes: a stuck program, a malware scan, or Windows Modules Installer Worker installing updates (let it finish). How the operating system shares the processor is explained in CPU Scheduling.
• Memory nearly full with the disk busy: the system is paging to disk. Close programs, find the memory-hungry one, or add memory. See Memory Management.
• Disk at 100% or the system drive nearly full: free space with Storage Sense or Disk Cleanup, and check the drive's health.
• Slow only after sign-in: too many startup programs. Task Manager's Startup apps page shows each program's startup impact and lets you disable it.
• Unexplained activity: run a full malware scan with Microsoft Defender or the organization's security software.

Application crashes

When one program closes unexpectedly or hangs, Event Viewer's Windows Logs → Application records an Application Error event (ID 1000) with the faulting program and the faulting module — the DLL (dynamic-link library) where the crash happened. A faulting module that belongs to an add-in or a printer driver tells you more than the program name. Reliability Monitor shows the same crashes per day. Fixes, from light to heavy: update the program, disable add-ins, use the program's Repair option (Settings → Apps → Installed apps → Advanced options or Modify), reinstall it, and test with another user profile to rule out a damaged profile.

Get-WinEvent -FilterHashtable @{LogName = 'Application'; Id = 1000} -MaxEvents 3

   ProviderName: Application Error

TimeCreated                      Id LevelDisplayName Message
-----------                      -- ---------------- -------
10/1/2026 9:14:22 AM           1000 Error            Faulting application name: invoicer.exe, version: 4.2.0.0, t...
9/30/2026 4:51:07 PM           1000 Error            Faulting application name: invoicer.exe, version: 4.2.0.0, t...
9/30/2026 11:02:45 AM          1000 Error            Faulting application name: invoicer.exe, version: 4.2.0.0, t...

No sound and other device problems

Start simple: is the right output device selected (Settings → System → Sound), is it muted, is it the right port? Then open Device Manager (devmgmt.msc). A yellow warning sign marks a device with a driver problem, a down arrow a disabled device. From a device's properties you can update, disable, uninstall or roll back its driver; rolling back is the quickest fix when a device stopped working after a driver update (see Updates, Patches and Drivers).

Profile problems

The message "You've been signed in with a temporary profile" means Windows could not load the user's profile, usually because it is damaged. The user sees an empty desktop, and anything saved there is lost at sign-out. Event Viewer shows User Profile Service errors in the Application log. The safe fix: sign in as another administrator and copy the user's files in C:\Users\<name> elsewhere. Delete the profile under System Properties → Advanced → User Profiles → Settings (this removes the folder and its ProfileList registry entry). Have the user sign in so Windows builds a new profile, then copy the data back. Repairing the profile's entry under the ProfileList key in the registry also works, but back up the registry first; a mistake there makes things worse.

Time drift

A clock that is minutes off causes errors that do not look like time problems: domain sign-in fails because Kerberos, the authentication protocol of Active Directory, by default rejects a clock difference over five minutes; websites report certificate errors; log entries no longer line up. Windows synchronizes its clock with the Network Time Protocol (NTP) — domain computers from a domain controller, other computers from time.windows.com. Why time matters and how NTP works is explained in Operational Services. Check and force synchronization from an elevated Command Prompt:

w32tm /query /status
w32tm /resync

Time that is wrong again after every restart on an older computer can be a flat CMOS (complementary metal-oxide-semiconductor) battery.

Safe mode

Safe mode starts Windows with a minimal set of drivers and services. If a problem disappears in safe mode, it is caused by something that normally loads at startup: a driver, a service or a startup program. It is also a way into a system that crashes too early to repair it normally, for example to uninstall the driver that causes a blue screen.

Pressing F8 during startup no longer works on current Windows. To reach safe mode:

1. Open the Windows Recovery Environment (see below): hold Shift while you click Restart, or go to Settings → System → Recovery → Advanced startup.
2. Choose Troubleshoot → Advanced options → Startup Settings → Restart.
3. Press 4 for Safe Mode, 5 for Safe Mode with Networking, or 6 for Safe Mode with Command Prompt.

System Configuration (msconfig) → Boot → Safe boot also works, but it keeps starting in safe mode until you clear the option again — a common reason for "my computer is stuck in safe mode". On a Mac with Apple silicon, hold the power button to reach the startup options, select the disk, hold Shift and choose Continue in Safe Mode.

The Windows Recovery Environment

The Windows Recovery Environment (WinRE) is a small separate Windows, stored in a recovery partition, with repair tools that work when normal Windows does not start. Windows opens it automatically after repeated failed start attempts. You can also start it with Shift + Restart, from Settings → System → Recovery, with shutdown /r /o, or by booting from Windows installation media and choosing Repair your computer. Under Troubleshoot → Advanced options:

Reset this PC is on the Troubleshoot screen itself; see below.

Startup Repair and manual boot repair

Startup Repair is the automatic repair tool in WinRE. It checks the disk, the boot files and the boot configuration, and fixes what it can; its log is C:\Windows\System32\LogFiles\Srt\SrtTrail.txt. Always try it before repairing the boot by hand. It cannot fix a failed disk or a boot order problem in the firmware.

For manual repair, older guides use bootrec in the WinRE Command Prompt:

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

These come from the era of BIOS and master boot record disks. /fixmbr rewrites the master boot record code; /rebuildbcd searches for Windows installations and offers to add them to the boot configuration data (BCD). On current computers with Unified Extensible Firmware Interface (UEFI) firmware and GPT (GUID Partition Table) disks, bootrec /fixboot often fails with "Access is denied", and the usual repair is to recreate the boot files on the Extensible Firmware Interface (EFI) system partition with bcdboot, for example bcdboot C:\Windows. Treat manual boot repair as an advanced step, and check which letter the Windows volume has inside WinRE first: it is not always C:.

Repairing system files: DISM and sfc

When Windows components misbehave — built-in apps that do not start, updates that keep failing, errors in Windows' own files — the system files themselves may be damaged. Two tools work together to repair them:

• System File Checker (sfc /scannow) checks every protected Windows file and replaces damaged ones with a good copy from the component store (C:\Windows\WinSxS).
• DISM (Deployment Image Servicing and Management) services Windows images. With /Online /Cleanup-Image /RestoreHealth it checks the component store of the running Windows and repairs it, downloading good files from Windows Update (or from a source you specify).

The order matters. If the component store itself is damaged, sfc copies damaged files and reports that it could not repair everything. So repair the source first with DISM, then let sfc repair the files from that source. Both need an elevated Command Prompt (Run as administrator), and both can take a while.

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Deployment Image Servicing and Management tool
Version: 10.0.26100.1150

Image Version: 10.0.26100.6584

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log. For offline
repairs, details are included in the log file provided by the /OFFLOGFILE flag.

Other results: "did not find any integrity violations" (the files are fine; look elsewhere) and "found corrupt files but was unable to fix some of them" (run DISM again, check the log, or consider a repair install). DISM /Online /Cleanup-Image /ScanHealth only checks without repairing. If the disk itself has errors, file repairs will not last; check it with chkdsk (see Windows Command Line and PowerShell).

Logs, Reliability Monitor and crash dumps

Event Viewer

Event Viewer (eventvwr.msc) is the first place to look for evidence. The System log records drivers, services, disks and unexpected shutdowns (Kernel-Power event 41 after a crash or power loss); the Application log records program errors; the Security log records sign-ins. Filter by level (Critical, Error) and by the time the user noticed the problem. Many warnings are harmless; what matters is what lines up with the symptom.

Reliability Monitor

Reliability Monitor shows the same kind of evidence as a timeline: a stability index from 1 to 10 per day, with icons for application failures, Windows failures, warnings, and informational events such as successful updates and driver installations. That makes it the fastest way to answer "what changed just before the problems started?". Open it with perfmon /rel, or search for "reliability history".

The idea is easy to automate. The program below takes a simplified reliability history, finds the day the crashes started, and lists the changes installed in the three days before:

from collections import Counter
from datetime import date, timedelta

history = [
    (date(2026, 9, 25), "info", "Installed 2026-09 cumulative update"),
    (date(2026, 9, 28), "info", "Installed Contoso Wireless driver 23.40"),
    (date(2026, 9, 28), "windows failure", "DRIVER_IRQL_NOT_LESS_OR_EQUAL (cwlan.sys)"),
    (date(2026, 9, 29), "app failure", "invoicer.exe stopped working"),
    (date(2026, 9, 29), "windows failure", "DRIVER_IRQL_NOT_LESS_OR_EQUAL (cwlan.sys)"),
    (date(2026, 9, 30), "windows failure", "DRIVER_IRQL_NOT_LESS_OR_EQUAL (cwlan.sys)"),
]

crashes = [(day, detail) for day, kind, detail in history if kind == "windows failure"]
first_crash = min(day for day, _ in crashes)
print(f"Blue screens: {len(crashes)}, first on {first_crash}")

for detail, count in Counter(detail for _, detail in crashes).most_common():
    print(f"  {count}x {detail}")

print("Changes in the 3 days before the first crash:")
window_start = first_crash - timedelta(days=3)
for day, kind, detail in history:
    if kind == "info" and window_start <= day <= first_crash:
        print(f"  {day}  {detail}")

Blue screens: 3, first on 2026-09-28
  3x DRIVER_IRQL_NOT_LESS_OR_EQUAL (cwlan.sys)
Changes in the 3 days before the first crash:
  2026-09-25  Installed 2026-09 cumulative update
  2026-09-28  Installed Contoso Wireless driver 23.40

Crash dumps

A crash dump is a file in which Windows saves the contents of memory at the moment of a stop error, so the crash can be analyzed afterward. By default Windows writes an automatic memory dump to C:\Windows\MEMORY.DMP (overwritten by the next crash) and a small memory dump, a minidump, small (usually well under a few megabytes), to C:\Windows\Minidump, one file per crash, named by date. The settings are under System Properties → Advanced → Startup and Recovery; writing a dump needs a page file on the system drive.

Microsoft's debugger WinDbg opens a dump, and its !analyze -v command names the stop code and the most likely driver. For a help desk, a minidump attached to the ticket is the evidence a second-line engineer or the vendor will ask for. Linux and macOS have the same idea: a kernel panic can write a crash dump (on Linux through kdump, where configured), and macOS saves panic reports that you can view in the Console app.

Restore, reset or reimage

When a repair does not work, the remaining options each undo more. Choose the least invasive one that fixes the problem.

System Restore

System Restore returns system files, drivers, installed programs and the registry to a restore point, without touching personal files. It is the right step when a driver or program installation broke Windows and uninstalling it is not possible or not enough. It only helps if restore points exist; see System Restore and restore points.

Reset this PC

Reset this PC (Settings → System → Recovery, or from WinRE) reinstalls Windows. It asks two questions:

• Keep my files reinstalls Windows and keeps the users' personal files, but removes installed apps and resets settings. Remove everything also deletes all personal files, and can additionally clean the drive so the data is hard to recover — the choice before handing a computer to someone else.
• Cloud download fetches fresh Windows files from Microsoft; Local reinstall rebuilds Windows from the files already on the computer. Cloud download helps when the local files are themselves damaged.

Even with Keep my files, back up first. A list of the removed apps is saved to the desktop, and every one of them must be reinstalled and configured.

When to reimage

In an organization with a standard image and data stored on servers or in the cloud, reimaging — wiping the computer and deploying the standard image again — is often faster and more predictable than repairing. Reimage when:

• the troubleshooting time is already longer than a rebuild would take;
• the computer was infected with malware: after an infection you cannot be sure a cleaned system is clean, so policy usually says reimage;
• the problem keeps coming back after repairs, or several unrelated problems appear at once.

Worked scenario: from ticket to resolution

A ticket arrives: "Laptop shows a blue screen several times a day since Monday. I lose my work every time."

1. Identify the problem. You call the user. The crashes happen at random moments, often after the laptop wakes up or joins the Wi-Fi. The user's photo of the screen shows DRIVER_IRQL_NOT_LESS_OR_EQUAL, What failed: cwlan.sys. Only this laptop is affected. You check that the user's documents are stored on the file server, which is backed up.
2. Gather evidence. Reliability Monitor shows no problems until Monday, then several Windows failures a day, all with the same stop code. On Monday morning, just before the first crash, it lists a successful driver installation: a new version of the Contoso Wireless adapter driver, delivered by Windows Update. The minidumps in C:\Windows\Minidump name the same driver file.
3. Theory. The new wireless driver causes the crashes. The pattern (same code, same driver, starting right after the install) points to software, not to failing memory.
4. Test and plan. In Device Manager, under Network adapters, the wireless adapter's Driver tab offers Roll Back Driver. You tell the user the laptop will lose Wi-Fi briefly and restart, then roll back to the previous version.
5. Prevent a repeat. Windows Update would reinstall the same driver. You report it to the team that manages updates so the driver version is held back for this model, and check the laptop manufacturer's site for a fixed version.
6. Verify. After three working days, Reliability Monitor shows no new Windows failures and the stability index is rising. The user confirms.
7. Document. The ticket records the symptom, the stop code, the driver versions (bad and good), the evidence, the fix and the follow-up with the update team — so the next technician who sees cwlan.sys on this model finds the answer in minutes.