Free Troubleshoot Common Windows OS Issues practice questions

A driver conflict introduced by the OS update is the most likely cause because drivers sit close to the hardware, and OS updates can replace or break driver components, which commonly causes printers and other devices to disappear or stop working after patching. Insufficient disk space typically prevents an update from downloading or completing, showing symptoms like an installation stuck at a certain percentage, rather than a device vanishing after a successful update. A feature update that changed the user interface would alter menus, layouts, or the OS version experience, but it would not specifically remove a printer. The Microsoft Store failing to update built-in apps affects app functionality such as Mail or Photos, not printer connectivity that relies on system drivers. When a peripheral disappears immediately after patching, review the update history, check Device Manager for the affected hardware, and consider rolling back or reinstalling the driver.

When an application crashes only on one specific task, such as opening a single file, the cause is usually tied to that file or a feature-specific dependency like a file handler, plug-in, or corruption. A quick test is to open a different file or create a new blank file to determine whether the original file is corrupt. A system running out of physical RAM would cause freezing and crashes across many heavy tasks, not a failure isolated to one file. A failing power supply would produce random shutdowns, reboots, or a system that will not power on, not a clean crash-to-desktop limited to a single document. An outdated network adapter driver would affect connectivity or online features rather than local file opening. Matching the crash trigger to the symptom is central to efficient troubleshooting: a crash tied to one file points at that file or the app's handling of it, while a crash tied to sign-in points at profile or startup items, and a crash after an update points at compatibility or drivers.

A hard fault occurs when Windows must fetch a needed memory page from disk because it was not present in RAM. A few hard faults are normal, but a steady high value while the system feels laggy is a strong indicator that the system is heavily paging to disk, which is a classic sign of memory pressure. CPU thermal throttling would show up as reduced clock speeds and sustained high CPU temperatures, not as hard faults in the Memory tab. GPU video memory exhaustion typically causes graphics glitches, black screens, or game crashes and is monitored through GPU metrics rather than hard faults per second. Network packet loss relates to connectivity issues and would appear in networking counters, not memory paging statistics. Recognizing hard faults as a paging signal helps a technician confirm whether closing the top memory consumer, reducing startup load, or freeing disk space will restore responsiveness, rather than guessing that more RAM is the only answer.

A 'Not Responding' message with a grayed-out window and spinning cursor describes a hang, which often stems from resource pressure or a deadlock where the app is waiting and cannot recover. The first clue to capture is what action triggered the freeze. A crash-to-desktop is different because the app closes suddenly and disappears, often with a popup error or Windows error report rather than freezing on screen. A file association error would prevent a file from opening in the correct program or produce an error dialog, not a grayed-out frozen window. A permissions or access rights error typically causes the app to fail when opening a protected resource and exit, which looks more like a sudden close than a lingering hang. Correctly classifying the symptom matters because a hang may be resolved by ending the task in Task Manager and relaunching, while reducing resource pressure by closing background apps or rebooting addresses the underlying cause.

For a modern Windows or Microsoft Store app, the least invasive next step is to open Settings, go to Apps and Installed apps, and choose Repair. Repair attempts to fix the app without removing user data. Following a least-invasive-first order means you try Repair before Reset, and Reset before a full reinstall. Running sfc /scannow repairs protected Windows system files, which is a broader system-level action better suited to crashes affecting multiple apps or evidence of system file corruption, not a single misbehaving Store app. Reset this PC is a last-resort recovery option that reinstalls Windows and should only be considered after backing up data and exhausting app-level and targeted system repairs. Rolling back the display adapter driver is appropriate only when evidence points to a GPU driver issue, such as graphics apps failing after a driver update, and there is no indication of that here. Following the escalation order minimizes risk to user data while resolving the most common causes first.

When a low memory warning matches user behavior such as opening too many tabs and extensions, the fastest low-risk fix is to close the worst offender or reduce the number of open tabs and extensions, which immediately releases memory. This one-time spike is driven by workload, so addressing the workload solves it quickly. Adding physical RAM is a valid long-term capacity fix, but it requires hardware, downtime, and cost, and it is not the first step for a behavior-driven spike. Setting a custom fixed-size page file is a specialized adjustment that risks mis-sizing and is generally reserved for stable workstations that cannot get a RAM upgrade, not a quick fix for heavy browsing. Replacing the hard drive with an SSD reduces paging pain but does not replace RAM and is again a hardware change rather than an immediate remedy. The troubleshooting principle is to apply the fastest low-risk action first, restore usability, and only escalate to settings changes or hardware when the evidence supports it.

Committed represents the total memory Windows has promised to applications, shown as used versus limit, where the limit is RAM plus the page file. When Committed approaches its limit even though some RAM still looks Available, the system is hitting a virtual memory commit ceiling. Windows cannot promise more committed memory, so this often points to page file sizing or low disk space rather than a raw shortage of RAM. A high Cached value is not automatically bad because Windows uses cache to speed up work; the more meaningful red flag is Available staying low while the system remains sluggish. CPU thread scheduling relates to processor load, not to committed memory, and would appear as high CPU utilization rather than a commit limit. GPU dedicated video memory exhaustion is tracked through GPU metrics and typically causes graphics artifacts or game crashes, not a system commit ceiling. Understanding the difference between true RAM pressure and virtual memory pressure guides the correct fix, such as freeing disk space or reviewing page file settings when the commit limit is the constraint.

Steady memory growth in a single process over hours, especially returning after each sleep cycle and beginning right after a driver update, describes a memory leak tied to that change. The most appropriate action is to roll back the driver as a test to see whether the growth stops, since the timeline points directly to the update as the cause. Disabling the page file is dangerous and usually makes low memory warnings worse, because Windows expects a page file to back virtual memory and disabling it can cause crashes and failed crash dumps. Performing a full Reset this PC is a drastic last-resort action that reinstalls Windows and is unjustified when a targeted driver rollback can resolve the issue. Setting the page file maximum to its lowest value would reduce available virtual memory and likely bring the low memory warnings back rather than fix them. When evidence such as Reliability Monitor or a clean timestamp ties instability to a specific driver or update, rolling back that change is the correct, low-risk response instead of random cleanup or capacity changes.

Code 12 is a resource-allocation error: Windows could not give the device the resources it needs because another device, or a ghost entry for a device that is no longer attached, is still claiming them. The fix is to show hidden devices in Device Manager and remove stale entries, check BIOS/UEFI settings, and update the chipset drivers that govern how resources are assigned. A damaged cable or an under-powered hub produces a device that disconnects, is not recognized, or reports a Code 43 "device reported a problem" status rather than a resource message. Selective suspend causes devices to drop out after sleep and does not produce a Device Manager error code. A miswired front-panel header stops the front ports from detecting anything at all, so the device would never appear in Device Manager with a status code.

When instability begins immediately after a specific change, the fastest and safest fix is to reverse that change. Because the crashes started right after the graphics driver update, rolling back the driver in Device Manager restores the previously working package and confirms whether the driver was the cause. Running CHKDSK checks the file system for logical errors and bad sectors, but nothing in this scenario points to disk corruption; the timing points squarely at the driver. Performing a clean installation of Windows is a drastic, high-impact step that destroys the current environment and is never appropriate before trying low-risk isolation and rollback options. Increasing the page file addresses memory pressure and swapping-related hangs, not a driver-induced blue screen. The guiding principle is to match the fix to what changed: a crash that follows a driver install is a strong software suspect, and driver rollback is the targeted, reversible response that gathers useful evidence with minimal risk.