0x0000003B SYSTEM_SERVICE_EXCEPTION
Windows was crossing the boundary from user mode into kernel mode to service a system call, and something threw an exception it could not recover from. The code tells you where the crash happened, not what caused it, which is why the same stop code shows up for a stale graphics driver and for a failing memory stick.
What you are looking at
Your PC ran into a problem and needs to restart.
If you call a support person, give them this info:
Stop code: SYSTEM_SERVICE_EXCEPTION
In Event Viewer the matching entries look like this:
Log Name: System
Source: BugCheck
Event ID: 1001
Level: Error
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff8036a1c4e10, 0xffffb80f9c2a7530, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP.What the error actually means
Windows runs application code in user mode, where a crash only kills the application. Kernel code runs in kernel mode, where a crash takes down the machine. Every time a program asks the operating system to do something privileged, execution crosses that boundary through a system call.
Bugcheck 0x3B fires when an exception is raised inside that transition and no handler deals with it. The kernel has no safe way to continue, so it stops everything and writes a dump.
The practical consequence: the crash location is a busy intersection that almost all software passes through. Finding the driver that actually misbehaved means reading the dump, not reading the stop code.
Reading the parameters
The four numbers in the parentheses are the useful part. The first one in particular narrows the field immediately.
| Parameter | What it holds |
|---|---|
| 1 | The exception code. 0xC0000005 is an access violation - something used a pointer it should not have, and this accounts for the large majority of 0x3B crashes. 0xC0000006 is an in-page error, which points at storage or memory rather than logic. 0x80000003 is a hardcoded breakpoint, normally only seen with a debug build or a driver left in a debug state. |
| 2 | The address of the instruction that raised the exception. On its own it is meaningless, but a debugger resolves it to a module name - and that module name is the whole point of the exercise. |
| 3 | The address of the context record, which holds the CPU register state at the moment of the fault. This is what a debugger reads to reconstruct the call stack. |
| 4 | Reserved. Always zero. Ignore it. |
What actually triggers it
Ranked by what actually turns up in practice rather than by what is theoretically possible.
| Cause | How often | Detail |
|---|---|---|
| Graphics driver | Common | By a wide margin the most frequent culprit, because display drivers are enormous and constantly in the syscall path. nvlddmkm.sys, amdkmdag.sys and igdkmd64.sys are the usual names in the dump. |
| Other third-party drivers | Common | Audio interfaces, network adapters, VPN clients, RGB and fan-control utilities, virtual drive software. Anything that installs a kernel driver can do this, and vendor utilities are often poorly maintained. |
| Filter drivers from security software | Occasional | Anti-virus and anti-cheat products insert themselves into file and process operations by design. When two of them disagree, the fault surfaces here. |
| Unstable memory timings | Occasional | An XMP or EXPO profile that is not genuinely stable produces crashes that look random and move around between stop codes. This is under-diagnosed because people assume an advertised profile must work. |
| Failing RAM | Occasional | A bad cell corrupts whatever happens to live there. If it lands on a kernel pointer you get an access violation in whichever driver read it - so the dump blames an innocent module. |
| Paged pool exhaustion from graphics drivers | Occasional | A documented and under-known cause. Microsoft notes this error has historically been linked to excessive use of the paged pool, occurring when user-mode graphics drivers cross over and pass bad data to kernel code. If the crashes correlate with heavy graphics work and pool usage climbs over time, this is worth pursuing with Driver Verifier's pool options rather than a plain driver reinstall. |
| Corrupt system files | Rare | Real, but over-recommended. Worth ten minutes to rule out, not worth treating as the default explanation. |
| Failing CPU, board or power delivery | Rare | Rare as a first diagnosis, but it is where you end up when nothing else explains the pattern - especially alongside WHEA entries in the same log. |
Narrowing it down
Work through these in order. Each one either eliminates a category or points at the next test, and none of them costs anything.
Read the dump before you change anything
Install WinDbg from the Microsoft Store, open C:\Windows\MEMORY.DMP (or the newest file in C:\Windows\Minidump), and run:
!analyze -vScroll to MODULE_NAME and IMAGE_NAME. That is the single most informative thing you will get all day, and it takes about five minutes.
Two more commands are worth knowing here. Where Windows itself identified a responsible driver, it stores the name in memory and you can print it directly:
dx KiBugCheckDriverAnd to decode the exception code from parameter 1 into a sentence:
!error 00000000c0000005Microsoft's documented route when the stack is unhelpful is .cxr with the parameter 3 address, followed by kb - that rebuilds the register context and gives you a usable backtrace.
A third-party .sys file names your suspect directly. If it says ntoskrnl.exe or ntfs.sys, do not conclude that Windows itself is broken - see the FAQ below, because those are usually the victim rather than the offender.
Check whether the crashes cluster around an activity
Crashes only under 3D load point somewhere very different from crashes while the machine sits idle overnight. Open Event Viewer, filter the System log to Critical and Error, and look at what was happening around each timestamp.
Load-correlated crashes suggest thermals, power delivery or an unstable overclock. Idle crashes suggest link-state and power-management transitions, which more often means hardware or firmware than an application bug.
Look for WHEA entries in the same log
Filter the System log by the source WHEA-Logger. These are hardware errors the machine reported directly, independent of any driver.
Any WHEA entries clustered near your stop errors shift the odds sharply toward hardware, and mean you should stop reinstalling drivers. Start with WHEA-Logger Event 17.
Count how many distinct stop codes you have seen
Go through the reboot history and write down every bugcheck code, not just the most recent one.
One code repeating points at one broken component, usually software. Several unrelated codes - 0x3B, then 0x1E, then 0x50, then a silent reboot - is the signature of memory corruption or a board-level fault, because bad data lands in a different place each time.
Fixes, cheapest first
Ordered by cost and effort. Do not skip to the expensive end; the top three resolve most cases.
Clean-install the graphics driver
An in-place driver update leaves the old files behind, which is exactly the state that produces these crashes. Remove it properly instead.
- Download the current driver from NVIDIA, AMD or Intel directly - not from Windows Update, and not from the laptop vendor unless it is a laptop with hybrid graphics.
- Download Display Driver Uninstaller (DDU) and reboot into Safe Mode.
- Run DDU, choose Clean and restart.
- Install the driver you downloaded. Decline any bundled extras you do not use.
Watch outIf the crashes started after a driver update, install the previous release instead of the newest one. Newer is not automatically better, and regressions in display drivers are common.
Verify system files
Cheap to rule out. Run these from an administrator terminal, in this order, and let each finish.
sfc /scannowDISM /Online /Cleanup-Image /RestoreHealthsfc /scannowonce more, so it can use the repaired component store
Return memory to stock settings
In UEFI, disable XMP, EXPO or any manual memory profile, and clear any CPU overclock or undervolt. This drops performance slightly and costs nothing.
Run the machine that way for a few days. If the crashes stop, the profile was not stable - re-enable it and either loosen the primary timings or raise the memory controller voltage a step, rather than assuming the advertised speed is guaranteed.
Test the RAM properly
Windows Memory Diagnostic is not sensitive enough to trust a pass from it. Use MemTest86 from a USB stick and let it run at least four full passes, ideally overnight.
Watch outA clean pass does not fully exonerate memory - intermittent faults can hide from it - but any error at all is conclusive. If you get errors, re-test one stick at a time to find which one, and test each in the same slot so you are not chasing a bad slot instead.
Strip back third-party drivers
Uninstall anything that runs at kernel level and is not essential: RGB and fan utilities, third-party anti-virus, VPN clients, virtual CD software, old printer packages, anti-cheat services from games you no longer play.
Then perform a clean boot with
msconfigand use the machine normally for a day.Use Driver Verifier as a last software step
Driver Verifier deliberately stresses drivers so a misbehaving one crashes immediately and identifiably rather than randomly. It is the strongest software-side tool available and it is built into Windows.
- Create a system restore point first.
- Run
verifieras administrator, choose Create custom settings, then Select individual settings from a full list. - Enable Special Pool, Force IRQL checking, Pool Tracking and I/O Verification.
- Choose Select driver names from a list and tick only drivers not provided by Microsoft.
- Reboot and use the machine. When it bugchecks, the dump will name the offending driver.
- Turn it off afterwards with
verifier /resetand reboot.
Watch outVerifier deliberately increases crashes and can cause a boot loop. Run
verifier /bootmode resetonbootfailbefore enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed byverifier /reset. Full settings and the escape route are in the Driver Verifier guide.
When it is the hardware, not Windows
At some point the software explanations run out. These are the signals that you have crossed over, and that further reinstalling is wasted effort:
- A clean Windows installation on a freshly formatted drive still crashes.
- Several unrelated bugcheck codes appear over a few weeks rather than one code repeating.
WHEA-Loggerentries appear in the System log, particularly in bursts.- The machine also fails in ways that are not stop errors at all - a display that goes black with the fans still running, or a silent reboot with no dump written.
- Crashes happen at idle, or moments after waking, rather than under load.
- Vendor diagnostics pass. Built-in tests like Dell ePSA run short, synthetic loads and routinely miss intermittent faults, so a pass is weak evidence.
If several of those apply, stop troubleshooting and start documenting. Export the relevant Event Viewer entries, keep the dump files, and write down the date and description of every failure. A support call backed by a crash history and exported logs goes very differently from one that starts with the words it keeps crashing. If the machine is still under warranty, that record is the thing that gets it replaced rather than reimaged.
Frequently asked
The dump names ntoskrnl.exe. Is Windows itself broken?
Almost certainly not. ntoskrnl.exe is the Windows kernel, and it appears because it was executing when the fault surfaced - it is usually the messenger. The same applies to ntfs.sys and dxgkrnl.sys. Look further down the stack in !analyze -v for a third-party driver, and if the kernel really is the only name present, that pattern points more toward memory corruption than a Windows bug.
Will reinstalling Windows fix it?
It fixes it when the cause is a corrupted driver stack or a software conflict, which is a meaningful share of cases. It does nothing for bad memory, a failing board or an unstable overclock. Because a reinstall destroys the evidence you would need for a warranty claim, capture your dumps and Event Viewer entries first - and treat a crash that survives a clean install as strong evidence of hardware.
Can I just ignore it if it only happens once a month?
You can, but track it. The thing that matters is the trend. A fault that arrives once a month, then weekly, then daily is a component degrading, and the useful time to act is while it is still intermittent and still under warranty - not after it fails completely.
No dump file is being written. What now?
Open System Properties, then Advanced, then Startup and Recovery, and set Write debugging information to Automatic memory dump or Small memory dump. Make sure the page file is on the system drive and system-managed. If dumps still never appear despite crashes, that is itself a signal: it usually means the machine is failing before it can write one, which points at hardware.