Windows Client Common Errors, Boot, Driver, and Update Fixes
Why Windows Client Common Errors Keep Hitting You
I've seen this exact pattern on dozens of machines, you sit down Monday morning, hit the power button, and Windows either hangs at a black screen, throws a cryptic stop code, or boots fine but immediately screams that a driver has failed. Sometimes it's worse: the machine joined to your corporate domain last week just fine, and now it won't pull Group Policy, Windows Update is stuck at 0%, or Device Manager has a wall of yellow exclamation marks.
Here's the thing most IT guides won't tell you: the majority of Windows client common errors don't happen in isolation. Boot failures are often downstream of a bad driver update. Driver failures frequently break the Netlogon service, which then causes domain authentication to fail silently. Windows Update stalls because the very component it needs to write updates, BITS or the Windows Update Medic Service, is itself corrupted. It's a cascade, and Windows' own error messages rarely give you a useful starting point.
The root causes fall into a few buckets. First, there are driver conflicts, a new kernel-mode driver gets installed, clashes with an existing one, and the OS can't reconcile them at boot. Second, there are corrupted system files, often left behind by a failed cumulative update or an interrupted shutdown. Third, and this one trips up a lot of IT admins, there are network-layer failures on domain-joined clients. When a Windows client can't complete the SMB2 handshake to the domain controller or the LDAP bind fails (more on that in the Advanced section), you get errors that look like local OS problems but are actually authentication failures happening at the network layer.
Windows Update errors like 0x80070003, 0x8007000D, 0x800F0922, and 0xC1900101 are among the most reported Windows client common errors in enterprise environments. Stop codes like DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1) and SYSTEM_THREAD_EXCEPTION_NOT_HANDLED are the most common driver-related crashes. And on domain-joined machines, Event IDs 5719, 6702, and 1055 in the System log are your first clue that Netlogon or LDAP connectivity has broken down.
I know this is frustrating, especially when it blocks your work or takes down a whole department's machines after a Patch Tuesday rollout. The good news is that almost every one of these problems is fixable without reinstalling Windows. Let's work through it systematically.
The Quick Fix, Try This First
Before you go deep into logs and registry edits, run through this checklist. I'd say 40% of Windows client common errors, including boot hangs, stuck updates, and driver failures, are resolved right here.
Open an elevated Command Prompt (right-click Start → "Windows Terminal (Admin)" or search for "cmd" and choose "Run as administrator") and run these three commands back to back:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
net stop wuauserv && net start wuauservThe first command contacts Windows Update servers to pull fresh copies of any corrupted system files. The second does a local integrity scan and replaces anything it finds wrong. The third restarts the Windows Update service, which clears many stuck-update states in one shot.
After those finish, and DISM can take 10 to 20 minutes, so be patient, restart the machine. If Windows Update was your issue, open Settings → Windows Update → Check for updates and watch whether it progresses past 0% this time. If a driver crash was your problem, check Device Manager (right-click Start → Device Manager) to see if the yellow exclamation marks cleared.
If you're dealing with a boot loop or a machine that won't reach the desktop at all, boot into Windows Recovery Environment instead. To get there, power the machine off mid-boot three times in a row, Windows will automatically load WinRE on the fourth attempt. From there, go to Troubleshoot → Advanced Options → Startup Repair. Let it run, then try booting normally.
For domain-joined machines showing Netlogon errors (Event ID 5719) right after boot, the quick test is:
nltest /sc_verify:yourdomain.comIf that comes back with "Flags: 0 WRITABLE" and a success status, your secure channel to the domain controller is healthy and the Netlogon issue is transient. If it fails, keep reading, you'll need the domain-specific steps in the Advanced section.
You can't fix what you haven't identified. The first thing I do on any Windows client showing common errors is pull up Event Viewer and the minidump files. Press Win + R, type eventvwr.msc, and hit Enter.
Expand Windows Logs → System. Click "Filter Current Log" on the right panel and filter by Event Level: Critical and Error. Sort by Date and Time descending. You're looking for event sources like Kernel-Power (Event ID 41, unexpected shutdown), Disk (Event IDs 11 and 15, I/O errors that often explain boot hangs), Service Control Manager (Event ID 7034, a service crashed unexpectedly), and NETLOGON (Event IDs 5719 and 5722, domain connectivity failures).
For driver crash stop codes, navigate to Windows Logs → Application and look for source Windows Error Reporting. You'll see the faulting module name right there, that's your suspect driver.
Also check your minidumps. Open File Explorer and navigate to C:\Windows\Minidump. If there are .dmp files in there dated around when the crashes started, that confirms driver-level crashes. Download WinDbg from the Microsoft Store or the Windows SDK and open a dump file. Run !analyze -v in the debugger command line, it will name the exact driver that caused the bugcheck.
If you see stop code 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) or 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED), you have a kernel driver accessing memory it shouldn't. Note the module name from the stop screen or the dump analysis, that's the file you'll be targeting in Step 2.
Once you have a specific error code or faulting module, you're no longer guessing. Every fix from here gets faster.
Driver problems are behind a huge slice of Windows client common errors, especially after Windows Update automatically pushes new hardware drivers. Here's how to deal with them surgically.
Open Device Manager (right-click Start → Device Manager). If you already know the faulting driver from Step 1, expand the relevant category, display adapters, network adapters, storage controllers, or whatever fits. Right-click the device and choose Properties → Driver tab.
If "Roll Back Driver" is available (not grayed out), click it. Windows will restore the previous driver version and ask you why, pick any reason and confirm. Restart the machine. This is the fastest fix when a Windows Update pushed a new driver that broke something.
If Roll Back is grayed out, meaning Windows has no previous version on file, you'll need to either uninstall and reinstall from the manufacturer's site, or use Device Manager's "Update Driver" → "Browse my computer for drivers" to point at a downloaded INF file. For network adapters specifically, get the driver installer on a USB stick from another machine first, because uninstalling the NIC driver will obviously kill your network access.
For display drivers (the most common culprit after Patch Tuesday), use Display Driver Uninstaller (DDU) in Safe Mode for a clean removal before reinstalling. Reboot into Safe Mode via Settings → System → Recovery → Advanced startup → Restart now → Troubleshoot → Advanced Options → Startup Settings → Restart, then press F4.
After the driver reinstall, confirm in Device Manager that the device shows no error code under Properties → General → Device status. "This device is working properly" is what you want to see.
pnputil /enum-drivers | findstr /i "driver"That command lists every third-party driver package currently on the system, handy for auditing after a messy update cycle.
Windows Update errors like 0x80070003 and 0x8007000D are almost always caused by a corrupted download cache or a broken Software Distribution folder, not a network problem, not a firewall issue. Here's the definitive reset sequence.
Open an elevated Command Prompt and stop all Windows Update-related services:
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserverNow rename the two folders Windows Update uses to stage downloads:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.oldRestart those services:
net start wuauserv
net start cryptSvc
net start bits
net start msiserverWindows will recreate both folders fresh when the services start. Now go to Settings → Windows Update → Check for updates. The update client will re-download everything it needs from scratch into the clean folder.
If you're seeing error 0x800F0922, that specifically means the System Reserved partition is too small or the Windows Update agent can't reach the update servers. Check that your System Reserved partition has at least 500 MB free (open Disk Management via diskmgmt.msc), and verify that windowsupdate.microsoft.com is not blocked by a proxy or firewall rule.
Error 0xC1900101 during a feature update (like upgrading to a new Windows 11 build) points almost exclusively to a driver incompatibility with the new build. Check the Windows 11 compatibility hold list for your hardware before pushing the update, Microsoft publishes known driver incompatibility safeguard holds at the Windows Health Dashboard.
After the services restart and a fresh check for updates, you should see the update list populate within 2 to 5 minutes.
If your Windows client isn't reaching the login screen at all, you're seeing a spinning circle that never resolves, a black screen after the manufacturer logo, or a repeated "Automatic Repair" loop, your Boot Configuration Data (BCD) store is likely damaged or your system partition's boot files are missing.
Boot from a Windows installation media (USB or DVD). If you don't have one, create it on another PC using the Media Creation Tool from Microsoft's website. At the installer screen, choose Repair your computer (bottom-left) instead of Install Now. Go to Troubleshoot → Advanced Options → Command Prompt.
Run these commands in order:
bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcdbootrec /rebuildbcd scans all drives for Windows installations and lets you add them to the BCD store. If it finds your Windows installation and you confirm by pressing Y, close the Command Prompt and restart. Most boot failures resolve at this step.
If that still doesn't work and you're on a UEFI system (which is almost everything made after 2012), you may need to repair the EFI system partition directly. In the same Command Prompt, identify the EFI partition:
diskpart
list disk
select disk 0
list partitionFind the partition labeled EFI (usually 100–260 MB on Disk 0, Partition 1). Assign it a drive letter and rebuild:
select partition 1
assign letter=Z
exit
bcdboot C:\Windows /s Z: /f UEFIRestart without the USB. On a healthy system, this brings you straight to the login screen.
This step is specifically for domain-joined Windows clients that boot fine locally but show errors related to Group Policy, domain login, or Netlogon. This is where the official Microsoft network documentation becomes directly relevant.
When a Windows client joins or communicates with a domain, it goes through a specific sequence of network operations. First it opens an SMB2 connection to the domain controller on port 445, authenticates, and accesses the NETLOGON share. Then it makes RPC calls, starting with TCP port 135 to contact the RPC Endpoint Mapper (EPMAP), which hands out dynamic port assignments for the DRSR (Directory Replication Service Remote) and Netlogon services. Finally, it opens an LDAP connection on TCP port 389, performs an unauthenticated search for RootDSE, then authenticates using NTLM SASL (an NTLMSSP_NEGOTIATE / NTLMSSP_CHALLENGE / NTLMSSP_AUTH three-way handshake). After the LDAP bind succeeds, all subsequent LDAP traffic, including the encrypted payloads carrying Group Policy object information, runs under SASL GSS-API Privacy protection, meaning you can't read the content of those packets even in Wireshark.
When any part of that chain breaks, you get Event ID 5719 ("No domain controller was found") or Group Policy errors (Event ID 1055) even though the machine has network connectivity. Here's how to repair it:
First, verify the secure channel:
nltest /sc_verify:yourdomain.comIf that fails, reset it:
netdom resetpwd /server:dc01.yourdomain.com /userd:DOMAIN\adminuser /passwordd:*You'll be prompted for the admin password. This re-establishes the machine account's secure channel with the domain controller without requiring you to remove and re-join the domain.
If LDAP connectivity is the problem (you can see SMB succeeding but LDAP timing out), check that TCP port 389 is reachable from the client:
Test-NetConnection -ComputerName dc01.yourdomain.com -Port 389A failed TCP handshake here points to a firewall rule blocking port 389, or the LDAP service on the DC being down. Check the domain controller's Active Directory Domain Services service status and firewall rules on both sides.
After the secure channel reset, run gpupdate /force on the client. If Group Policy applies cleanly, you're back in business.
Advanced Troubleshooting for Windows Client Common Errors
When the standard steps don't fully resolve the problem, you need to go deeper. Here's what I pull out for stubborn cases.
Group Policy and Registry-Level Fixes
Some Windows client common errors involving Windows Update are caused by stale or conflicting Group Policy settings that block updates at the registry level. Open regedit.exe and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateIf you see values like WUServer or WUStatusServer pointing to an internal WSUS server that's offline or decommissioned, that's why updates are failing, the client is being told to fetch updates from a server that doesn't exist. You can either delete those values (which reverts the machine to Microsoft Update) or update them to point to the correct WSUS server. Make the change, then run gpupdate /force and restart Windows Update.
Event Viewer Deep Dive, The IDs That Matter
Beyond the basics, these are the Event IDs that experienced admins watch for:
- Event ID 41, Source: Kernel-Power, Unexpected shutdown without a proper stop code. Usually points to power supply issues or driver crashes that happen too fast for Windows to write a minidump.
- Event ID 7001, Source: Service Control Manager, A service failed to start because it depends on another service that failed. Always look at what service it depends on, that's the real problem.
- Event ID 1074, Source: USER32, Records every shutdown and restart with the reason code. Useful for confirming whether reboots are happening because of update installs.
- Event ID 5722, Source: NETLOGON, "The session setup from the computer [name] failed to authenticate." On the domain controller side, this tells you exactly which client is failing its Netlogon handshake.
Network Trace Analysis for Domain Join Problems
For enterprise environments where clients keep losing domain connectivity, capturing a network trace during the issue is invaluable. Use the built-in Windows tool:
netsh trace start capture=yes tracefile=C:\temp\domainjoin.etl
:: Reproduce the problem, then:
netsh trace stopOpen the resulting ETL file in Microsoft Message Analyzer or convert it to PCAP format for Wireshark. What you're looking for: does the TCP three-way handshake to port 445 complete? Does the SMB2 session establishment succeed? Does the LDAP connection to port 389 get a SYN-ACK from the domain controller, or does it time out? When the LDAP NTLMSSP_AUTH packet goes out with the user credentials (visible as "User: DOMAIN\username" in unencrypted binds), does the domain controller respond with a success or a failure? Those four checkpoints tell you exactly which layer is broken. Remember that once the LDAP bind succeeds, all the SASL GSS-API Privacy payload packets that follow are encrypted, so if you see those flowing, the authentication is working and the problem is elsewhere.
RPC Failures and Dynamic Port Ranges
The RPC Endpoint Mapper on TCP 135 hands out dynamic port assignments for services like DRSR and Netlogon. If your corporate firewall only allows port 135 but blocks the dynamic range (49152–65535 by default on modern Windows), RPC calls will fail silently after the initial EPMAP contact succeeds. Restrict the dynamic port range to a predictable set using:
netsh int ipv4 set dynamicport tcp start=50000 num=255Then open only that range (50000–50255) in the firewall. This is a documented Microsoft-supported approach for environments where the full dynamic range can't be opened.
C:\Windows\Logs\CBS\CBS.log), your network traces, and your Event Viewer exports ready, they'll ask for all of them.
Prevention & Best Practices for Windows Client Stability
The best fix for Windows client common errors is stopping them before they happen. After years of watching the same problems repeat themselves in enterprise environments, here's what actually works.
Control driver updates separately from OS updates. In Group Policy, go to Computer Configuration → Administrative Templates → Windows Components → Windows Update and enable "Do not include drivers with Windows Updates." This stops Windows Update from automatically pushing manufacturer drivers, which are a major source of post-Patch-Tuesday instability. Deploy driver updates through a separate tested pipeline, Configuration Manager, Intune, or manual IT-controlled deployment.
Defer feature updates, not quality updates. Quality updates (monthly cumulative patches) should be applied within 30 days, they contain security fixes you actually need. Feature updates (annual Windows 11 version upgrades) can safely be deferred up to 365 days on Windows 11. In an enterprise environment, use Windows Update for Business rings: a small Pilot group gets updates first, followed by a broader Early Adopter group a week later, then production. This catches bad updates before they hit everyone.
Monitor Netlogon health proactively. Schedule a daily task on all domain-joined clients that runs nltest /sc_verify:yourdomain.com and logs the output. Alert on any failures. Catching a broken secure channel early, before users try to log in, turns a morning-wide incident into a 5-minute fix.
Keep System Reserved and EFI partitions healthy. Check these periodically with Disk Management (diskmgmt.msc). If your System Reserved partition is at 100% capacity, BCD repairs become harder. The safe minimum is 250 MB free on a 500 MB partition. If it's full of old boot entries, clean them up with bcdedit /enum all and delete stale entries with bcdedit /delete {identifier}.
- Enable Windows Error Reporting and configure it to send reports to your own WER server, you'll catch driver crashes across the fleet before users report them.
- Run
sfc /scannowmonthly as a scheduled task on all clients, catching corruption early prevents cascading failures. - Set a BIOS/UEFI password and disable Secure Boot only when absolutely required by a tested, signed driver, most modern driver stacks are fully Secure Boot compatible.
- Use
Get-WindowsUpdateLogin PowerShell after every Patch Tuesday to parse the ETW update log into a readable format before any issues surface, reviewing it proactively takes 5 minutes and can flag problem updates immediately.
Frequently Asked Questions
Why does my Windows client keep showing "No domain controller available" after rebooting even though the network is fine?
This is almost always a Netlogon timing issue at startup, the machine boots faster than its network stack fully initializes, so the first Netlogon attempt fires before the NIC is ready and fails. The error gets logged as Event ID 5719 even though everything works fine a minute later. To confirm, check whether domain login actually works if you wait 60 seconds after the desktop appears. If it does, the fix is a Group Policy setting under Computer Configuration → Administrative Templates → System → Logon: enable "Always wait for the network at computer startup and logon" and set it to Enabled. This tells Windows to hold the login screen until the network stack confirms domain connectivity before proceeding.
My Windows Update is stuck at 0% downloading. I've waited two hours. What's actually happening?
A stuck download at 0% almost always means the Background Intelligent Transfer Service (BITS) has a corrupted job queue, or the SoftwareDistribution folder has a partially downloaded file that BITS refuses to overwrite. Run the full component reset from Step 3 of this guide, stop the four services, rename SoftwareDistribution and catroot2, then restart the services. That clears the job queue completely. If you're behind a corporate proxy, also verify that the Windows Update client has the correct proxy configuration with netsh winhttp show proxy, if it's blank, you may need to import proxy settings with netsh winhttp import proxy source=ie.
I'm getting a blue screen with stop code DRIVER_IRQL_NOT_LESS_OR_EQUAL. Which driver is causing it?
The stop code itself doesn't name the driver, but the minidump file does. Navigate to C:\Windows\Minidump and grab the most recent .dmp file. Open it in WinDbg (free from the Microsoft Store) and run !analyze -v, within a few seconds it will name the exact faulting module, like nvlddmkm.sys (NVIDIA display driver) or iaStorA.sys (Intel RST storage driver). Once you have the file name, either roll it back via Device Manager or download the latest stable version from the manufacturer's site. For NVIDIA specifically, use DDU in Safe Mode for a clean uninstall before installing the new driver to avoid leftover files causing repeat crashes.
SFC found corrupt files but says it can't fix them. Now what?
This means the component store that SFC pulls replacement files from is itself corrupted, SFC can't fix itself. Run DISM first: DISM /Online /Cleanup-Image /RestoreHealth. This reaches out to Windows Update servers, downloads fresh component files, and repairs the store. After DISM completes successfully (look for "The restore operation completed successfully" at the end), run sfc /scannow again. It should now successfully replace the corrupt files. If DISM itself fails because Windows Update servers aren't reachable, you can mount a Windows ISO and point DISM at it as a source: DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\Sources\install.wim /LimitAccess.
After joining a domain, LDAP keeps disconnecting. I can see SASL GSS-API Privacy packets in my trace but then a TCP RST. What's wrong?
That TCP RST after the LDAP SASL encrypted payload sequence is typically the domain controller closing the connection after the LDAP session completes its work, that's actually normal behavior. The client will open a new TCP connection on a fresh port for the next LDAP operation, which is why you see multiple SYN sequences in a trace of a domain join or authentication event. If the RST is happening mid-session before any payload exchange completes, though, that points to a network appliance (firewall, load balancer, or IDS) that's aggressively timing out idle TCP connections. Check for LDAP TCP idle timeouts on your network equipment and set them to at least 30 minutes for port 389 traffic.
Windows Update error 0xC1900101 keeps blocking my upgrade to the latest Windows 11 build. I've tried three times.
Error 0xC1900101 is specifically a driver rollback failure during the upgrade process, Windows tried to upgrade, a driver didn't survive the transition, and setup rolled back to the previous build. The fix is to identify the incompatible driver before attempting the upgrade. Run the PC Health Check app from Microsoft to see if there are any compatibility holds on your hardware. Also check C:\$WINDOWS.~BT\Sources\Panther\setupact.log and search for "0xC1900101", the lines around that entry name the specific driver that caused the failure. Uninstall or update that driver, delete the C:\$WINDOWS.~BT folder to force a fresh download, then try the upgrade again. Common culprits are older fingerprint reader drivers, third-party antivirus kernel components, and legacy USB host controller drivers.