SYSTEM_SERVICE_EXCEPTION Blue Screen 0x3B: Reading the 4 Numbers

SYSTEM_SERVICE_EXCEPTION is Windows stop code 0x0000003B (0x3B). Microsoft defines it as "an exception happened while executing a routine that transitions from non-privileged code to privileged code," in other words while ordinary code was handing a request to the Windows kernel. The first of the four numbers recorded with the crash is the exception code, and that is the most useful clue: 0xC0000005 means a memory access violation, 0x80000003 means a breakpoint was hit with no debugger attached. For people who cannot use a debugger, Microsoft lists four general checks, covered below in its order.

This page is based on the Microsoft Learn article "Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION," read on 12 October 2026 and checked against the Microsoft Docs source file. Microsoft labels it as written for programmers and points customers to https://www.windows.com/stopcode. We separate what a regular user can act on from what needs a debugger.

What happens in a 0x3B crash?

Applications run with limited privileges. When they need the kernel to do something, the request crosses into privileged code through a system service routine. Microsoft's "Cause" section says 0x3B means the code running there had an exception, and "the thread that was below it, is a system thread."

Microsoft then names the usual reasons:

• a NULL pointer was dereferenced, or a random incorrect address was accessed
• which in turn can be caused by memory being freed too early, or by data structure corruption

There is one more historical note on the page that matters for home PCs. Microsoft writes that "in the past, this error has been linked to excessive use of the paged pool, which may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code." That is a pointer towards graphics drivers, but Microsoft frames it as a past association, not a rule.

How do you read the four parameters?

Parameter	Meaning (Microsoft Learn)	What to do with it
1	The exception that caused the bug check	Look it up: 0xC0000005 or 0x80000003 are the common ones
2	The address of the instruction that caused the bug check	Developers map it to a module and function
3	The address of the context record for the exception	Developers pass it to the .cxr command
4	0 (not used)	Nothing

You do not need a debugger to see these values. Microsoft's general page on blue screen data says the bug check event in the Windows system log lists all four parameters; open Event Viewer, then Windows Logs, System, and find the entry at the time of the crash.

The two exception codes Microsoft names

• 0xC0000005, STATUS_ACCESS_VIOLATION: a memory access violation occurred.
• 0x80000003, STATUS_BREAKPOINT: a breakpoint or ASSERT was encountered when no kernel debugger was attached.

Microsoft says the full list of exception codes is in its NTSTATUS values reference and in the ntstatus.h header file that ships with the Windows Driver Kit. If your parameter 1 is something else, that is where to look it up.

Did the blue screen name a driver?

Often it does. Microsoft's page says that when the responsible driver can be identified, "its name is printed on the blue screen." The debugger example on the page shows the file nvlddmkm.sys as the named driver. A file name ending in .sys is the strongest single lead you can get, so photograph the screen before restarting.

The 4 general checks Microsoft lists

In the "Remarks" section, Microsoft gives these suggestions for general troubleshooting of bug check codes. They are in Microsoft's order; we have not added any.

• New drivers or system services. If new device drivers or system services were added recently, try removing or updating them. Try to work out what changed in the system that caused the new bug check code to appear.
• Device Manager. Look for devices marked with an exclamation point (!), which indicates a problem. Review the events log shown in the properties of any faulting device driver, and try updating the related driver.
• Event Viewer, System Log. Look for additional error messages that might help pinpoint the device or driver, particularly critical errors that occurred in the same time window as the blue screen.
• Recently added hardware. If you recently added hardware, try removing or replacing it, or check with the manufacturer to see whether patches are available.

How do these checks fit the exception code?

Microsoft does not link particular checks to particular exception codes, so treat this as a reading aid rather than a rule. An access violation (0xC0000005) is a memory access by code, and the page's causes are code-level: bad pointers, early frees, corrupted structures. That makes "what driver or service changed recently?" and a driver named on the screen the natural first questions. A breakpoint code (0x80000003) means code hit a deliberate stop point with no debugger present, which is a software matter rather than a hardware one. Neither code, on its own, tells you which driver is at fault.

Checklist

• Stop code text and all four parameters, copied exactly
• Parameter 1 looked up: access violation, breakpoint, or something else
• Driver file name from the blue screen, if one was shown
• Drivers, services or graphics software installed or updated before the first crash
• Device Manager checked for exclamation marks
• System Log entries from the same time window
• Hardware added recently, and any manufacturer patches

For developers: Microsoft's debugging path

Microsoft states that finding the specific cause and creating a code fix requires programming experience and access to the source code of the faulting module. The page's suggested route:

• Run .cxr with parameter 3 to set the context record, then kb for a stack backtrace.
• Use !analyze for a summary; the page shows sample output with parameter 1 set to 0xc0000005.
• Show the named driver with dx KiBugCheckDriver.
• Use !error on parameter 1 to decode the exception code.
• Read STACK TEXT, and compare across several dumps if you have them, looking for common code in the stack.
• Use lm t n to list loaded modules, !memusage for general memory state, and !pte and !pool for specific areas.
• If you suspect paged pool overuse, use the pool options in Driver Verifier, started by entering verifier at a command prompt. Microsoft advises verifying as few drivers as possible because verification adds overhead.

Success rates. Microsoft does not say which of its four checks resolves 0x3B most often.

Sources and how to check

• Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x3b--system-service-exception
• Analyze bug check (stop code error) data, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data
• Bug check code reference, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2
• Troubleshoot blue screen errors (for regular users): https://www.windows.com/stopcode
• Source: Microsoft Learn, as of 12 October 2026. Checked against the Microsoft Docs source files (MicrosoftDocs/windows-driver-docs). Microsoft documentation is licensed under Creative Commons Attribution 4.0 (CC BY 4.0); this article adapts and summarises it with credit to Microsoft and links to the originals. Microsoft does not endorse this site.