The SYSTEM_SERVICE_EXCEPTION bug check has a value of 0x0000003B. This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.
This topic is for programmers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
The exception that caused the bug check.
The address of the instruction that caused the bug check
The address of the context record for the exception that caused the bug check
This stop code indicates that executing code had an exception, and the thread that was below it is a system thread.
The exception information that is returned in parameter 1 is described in NTSTATUS values. The exception codes are defined in ntstatus.h, a header file provided by the Windows Driver Kit. (For more info, see Header files in the Windows Driver Kit).
Common exception codes include:
A breakpoint or ASSERT was encountered when no kernel debugger was attached to the system.
A memory access violation occurred. (Parameter 4 of the bug check is the address that the driver attempted to access.)
To debug this problem, use the .cxr (display context record) command with Parameter 3, and then use kb (display stack backtrace). You can also set a breakpoint in the code that precedes this stop code and attempt to single-step forward into the faulting code. Use the u, ub, uu (unassemble) commands to see the assembly program code.
The !analyze debugger extension displays information about the bug check and can be helpful in determining the root cause. The following example is output from !analyze.
SYSTEM_SERVICE_EXCEPTION (3b) An exception happened while executing a system service routine. Arguments: Arg1: 00000000c0000005, Exception code that caused the bugcheck Arg2: fffff802328375b0, Address of the instruction which caused the bugcheck Arg3: ffff9c0a746c2330, Address of the context record for the exception that caused the bugcheck Arg4: 0000000000000000, zero. ...
For more information about WinDbg and !analyze, see the following topics:
Identify the driver
If a driver that is responsible for the error can be identified, its name is printed on the blue screen and stored in memory at the location (PUNICODE_STRING) KiBugCheckDriver. You can use dx (display debugger object model expression), a debugger command, to display this:
Use the !error extension to display information about the exception code in parameter 1. Following is an example of output from !error.
2: kd> !error 00000000c0000005 Error code: (NTSTATUS) 0xc0000005 (3221225477) - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
Look at the STACK TEXT output from WinDbg for clues about what was running when the failure occurred. If multiple dump files are available, compare their information to look for common code that is in the stack. Use debugger commands like kb (display stack backtrace) to investigate the faulting code.
Use the following command to list modules that are loaded in memory: lm t n
Use !memusage to examine the general state of the system memory. You can also use the commands !pte and !pool to examine specific areas of memory.
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. If you suspect this is the case, use the pool options in Driver Verifier to gather additional information.
Driver Verifier is a tool that runs in real time to examine the behavior of drivers. For example, Driver Verifier checks the use of memory resources, such as memory pools. If it identifies errors in the execution of driver code, it proactively creates an exception to allow that part of the driver code to be further scrutinized. Driver Verifier Manager is built into Windows and is available on all Windows PCs.
To start Driver Verifier Manager, enter verifier at a command prompt. You can configure which drivers to verify. The code that verifies drivers adds overhead as it runs, so try to verify the smallest number of drivers possible. For more information, see Driver Verifier.
For general troubleshooting of Windows bug check codes, follow these suggestions:
If new device drivers or system services have been added recently, try removing or updating them. Try to determine what changed in the system that caused the new bug check code to appear.
Look in Device Manager to see if any devices are marked with an exclamation point (!), which indicates a problem. Review the events log displayed in the properties for any faulting device driver. Try to update the related driver.
Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. Look for critical errors in the system log that occurred in the same time window as the blue screen.
If you recently added hardware to the system, try removing or replacing it. Or check with the manufacturer to see if any patches are available.
For additional general troubleshooting information, see Blue screen data.
About “What is” service
Many of users are faced with the problem of interpreting errors that occur during the work of operating systems. In some cases, the operating system reports that an error has occurred and displays only an integer error code value. Often it is difficult to even roughly understand the cause of the error from the information given out. Our “what is” service contains a database of errors in Windows, Linux, Macos and Solaris operating systems. The database contains tens of thousands of values. In most cases, the online service will be able to help with the definition of the short name of the error and its detailed description.
Current version of service supports following types of error and status codes:
|NTSTATUS||Many kernel-mode standard driver routines and driver support routines use the NTSTATUS type for return values. Additionally, drivers provide an NTSTATUS-typed value in an IRP’s IO_STATUS_BLOCK structure when completing IRPs. The NTSTATUS type is defined in Ntdef.h, and system-supplied status codes are defined in Ntstatus.h.|
|Win32 error||Win32 error codes MUST be in the range 0x0000 to 0xFFFF, although Win32 error codes can be used both in 16-bit fields (such as within the HRESULT type specified in section 2.1) as well as 32-bit fields. Most values also have a default message defined, which can be used to map the value to a human-readable text message; when this is done, the Win32 error code is also known as a message identifier.|
|HRESULT||HRESULT is a data type used in Windows operating systems, and the earlier IBM/Microsoft OS/2 operating system, to represent error conditions, and warning conditions.|
The original purpose of HRESULTs was to formally lay out ranges of error codes for both public and Microsoft internal use in order to prevent collisions between error codes in different subsystems of the OS/2 operating system.
HRESULTs are numerical error codes. Various bits within an HRESULT encode information about the nature of the error code, and where it came from.
HRESULT error codes are most commonly encountered in COM programming, where they form the basis for a standardized COM error handling convention.
|HTTP Status Code||Hypertext Transfer Protocol (HTTP) response status codes. Status codes are issued by a server in response to a client’s request made to the server. It includes codes from IETF Request for Comments (RFCs), other specifications, and some additional codes used in some common applications of the HTTP. The first digit of the status code specifies one of five standard classes of responses. The message phrases shown are typical, but any human-readable alternative may be provided.|
|errno||Integer value, which is returned by system calls and some library functions in the event of an error to indicate what went wrong. errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. errno is thread-local; setting it in one thread does not affect its value in any other thread.|
|Kern Return||Apple Kernel return codes.|
|Ipp Status||The IppStatus constant enumerates the status values returned by the Intel IPP functions, indicating|
whether the operation is error-free.
The service is based on the open source library AllStat. Its sources are available on our git server. We will be grateful for your participation in the finalization of the library and ideas for the development of the service. You can also download ErrorLookup libraries and utilities from our site.