Fix SYSTEM_SERVICE_EXCEPTION in Windows 11

SYSTEM_SERVICE_EXCEPTION is bug check 0x0000003B, and short version: it means a driver — usually a third-party one — passed bad data into the Windows kernel while making a system call, and Windows caught the fault before it could corrupt anything further. Microsoft's bug check documentation describes it as an exception occurring in a routine that transitions from non-privileged (user-mode) code to privileged (kernel-mode) code. In plain terms: something asked the kernel to do something, and the handoff broke. If a driver name is printed on the blue screen itself, or shows up in Event Viewer, that's your strongest lead — go there first instead of guessing.

What this error means and doesn't mean

The four parameters Windows shows with this bugcheck (visible in Event Viewer under the "computer has rebooted from a bugcheck" entry) are an NTSTATUS exception code, the address of the instruction that caused it, an exception context record address, and a reserved value. The most common exception code you'll see is 0xC0000005, which is an access violation — code trying to read or write memory it doesn't have permission to touch. This is fundamentally a code-correctness bug, not a hardware failure signal the way WHEA errors are. It can still be triggered by hardware in rare cases (a failing RAM module corrupting data a driver then trusts), but start from the assumption this is software until the checks below tell you otherwise.

Symptom, check, and fix

What you see	Confirming check	Fix
A specific driver name (not ntoskrnl.exe) appears on the BSOD or in the dump	Device Manager → find that device → Driver tab → check version against vendor's current release	Update from the vendor's site directly, not the generic Windows Update version
Crash names ntoskrnl.exe or ntkrnlmp.exe only	No specific third-party driver is implicated yet — this needs Driver Verifier to surface one	Run Driver Verifier targeting non-Microsoft drivers (see below)
Crashes reference WdFilter.sys or FLTMGR.sys	Run `fltmc filters` to list active filesystem filter drivers and check for third-party AV/backup hooks alongside Defender	Update or temporarily remove the conflicting filter driver (usually AV or backup software)
Started right after a specific driver or app install	Reliability Monitor timeline lines up with the install date	Roll back or uninstall that driver/app first
Happens specifically in one game or application	Check whether the app itself has known crash reports tied to this bugcheck	Update the app; if it's a game with anti-cheat, check the anti-cheat vendor's own known-issues page

Check for an already-documented fix first

Before running Driver Verifier or reinstalling anything, check Settings → Windows Update → Update history for a cumulative update installed right before the crashes started, and search that specific KB number on support.microsoft.com. Microsoft publishes known-issue rollback notices for cumulative updates that cause driver-compatibility regressions, and if one applies to your build, applying the documented fix is faster and safer than chasing the driver yourself.

Fix it in this order

Update Windows and every driver Windows Update offers. Settings → Windows Update → Advanced options → Optional updates, and install anything listed under driver updates. This alone resolves a meaningful share of 0x3B crashes because it's so often an out-of-date GPU, storage, or network driver at fault.
If a driver was named, update it directly from the vendor. Don't rely on Windows Update's version for GPUs, audio, or storage controllers — go to the manufacturer's site for the current release. If the crashes started right after that same driver was updated, do the opposite: roll it back via Device Manager → Properties → Driver tab → Roll Back Driver.
Check for third-party filesystem filter drivers if WdFilter.sys or FLTMGR.sys is involved. Run this from an elevated Command Prompt:
```
fltmc filters
```
This lists every filesystem filter driver currently loaded — antivirus, backup software, and encryption tools all hook in here. If you see a third-party entry alongside Microsoft's own filters, that's your suspect: update it first, and if the crashes continue, temporarily uninstall it (not just disable it) to confirm.
Run a clean boot to isolate a startup conflict. Run msconfig, switch to Selective Startup, open the Services tab, check "Hide all Microsoft services," then Disable All. Reboot and use the system normally. If the crashes stop, re-enable services in batches to find the culprit.
Run Driver Verifier if no specific driver has been identified yet. This is the step Microsoft's own documentation points to for exactly this situation — it deliberately stresses driver code paths so a marginal one fails faster and gets named in the resulting dump. Create a System Restore point first, since Verifier can make an unstable system crash more, not less, while it runs:
```
verifier /standard /driver *
```
Or scope it to non-Microsoft drivers only, which is gentler and usually enough:
```
verifier /standard /all
```
Use the system normally for a day or two. If it crashes, the resulting dump should name the offending driver directly. Turn Verifier back off once you have an answer — leave it running longer than necessary and you're adding overhead for no reason:
```
verifier /reset
```
If Verifier itself prevents the system from booting normally, boot into Safe Mode or the Recovery Environment and run verifier /reset from an elevated Command Prompt there.
Check disk and memory only after the driver path is exhausted. Run chkdsk C: /f /r and Windows Memory Diagnostic (mdsched.exe, extended mode) as a final pair of checks. These are documented secondary causes, not the first thing to reach for, since this bugcheck is a code-correctness fault far more often than a hardware one.

What I would not do

Don't reinstall Windows before running Driver Verifier at least once. A clean install often "fixes" this simply by removing the offending third-party driver along with everything else — which means you never actually learn what caused it, and it can come back the moment you reinstall your usual software.
Don't download a random "driver update" utility promising to fix BSODs automatically. These tools frequently install generic, mismatched driver versions that create new problems instead of fixing the one you have.
Don't leave Driver Verifier enabled indefinitely "just to be safe." It adds real overhead and its entire purpose is a bounded diagnostic window, not a permanent setting.
Don't assume a crash naming ntoskrnl.exe means Windows itself is broken. It usually means the actual faulting driver couldn't be identified from the dump, not that the fault originates in Windows.

One thing worth knowing if you're on a laptop with third-party "performance" or "tuning" utilities from the manufacturer (Intel XTU-style overclocking tools are a repeat offender here): these inject kernel-mode components too, and they show up in the same crash patterns as antivirus filter drivers. If you've got one installed and didn't think to consider it a "driver," it belongs on your suspect list before you move to Driver Verifier.

Checked the blue screen and Event Viewer for a named driver before assuming ntoskrnl.exe is the culprit
Ruled out a known-issue Windows Update rollback
Updated or rolled back the specific driver identified
Checked fltmc filters if WdFilter.sys or FLTMGR.sys appeared
Ran a clean boot to isolate third-party startup software
Used Driver Verifier as a bounded diagnostic, then turned it back off
Left chkdsk and memory diagnostics for last, not first