(Error)The computer has rebooted from a bugcheck. The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff8026be7b9dc, 0xffffd58252fc2600, 0x0000000000000000)

Question

Encountered this error last April 21, 2026. Had 2 sudden reboots after that in 1 week, I'm not sure what's the root cause of this. But I think it's because of the drivers? Maybe someone can help?

Answer 1

Please check to see if your PC is producing any minidump files, I will check those to see if they provide any insight into a potential cause of the system crashes.

Please do not upload a very large Memory.dmp file.

Open Windows File Explorer.

Navigate to C:\Windows\Minidump

Copy any minidump files onto your Desktop, then zip those up.

Upload the zip file to the Cloud (OneDrive... etc.), then choose to share those and get a share link.

Then post the link here to the zip file, so I can take a look for you.

Answer 2

The bugcheck 0x0000003B (SYSTEM_SERVICE_EXCEPTION) indicates that an exception occurred while executing a system service, during a transition from non-privileged (user) code to privileged (kernel) code. In practice, this is commonly associated with:

• Faulty or buggy device drivers (including graphics or other kernel-mode drivers)
• Memory access violations (for example, dereferencing invalid or freed memory)
• Data structure or memory corruption in kernel-mode code

From the parameters in the event:

• Parameter 1 (0xC0000005) is STATUS_ACCESS_VIOLATION, which means a driver or kernel component tried to access invalid memory.
• Parameter 2 is the address of the instruction that caused the fault.
• Parameter 3 is the address of the context record for the exception.

To identify the root cause, the recommended approach is:

1. Analyze the crash dump with WinDbg
   • Open the memory dump (minidump or full dump) in WinDbg.
   • Run !analyze -v to get a detailed analysis of the bugcheck and see if a specific driver is flagged.
   • Use .cxr with parameter 3 (the context record address) and then kb to inspect the call stack around the faulting instruction.
   • Use dx KiBugCheckDriver to see if Windows recorded a specific driver as responsible.
2. Check for problematic or recently changed drivers
   • If a specific driver is identified in the analysis (for example, a graphics driver or storage/network driver), update it to the latest version from the vendor or roll back to a previous stable version.
   • In general troubleshooting, remove or update any device drivers or system services added or changed around the time the crashes started.
   • In Device Manager, look for devices with a warning icon and update or troubleshoot those drivers.
3. Review Event Viewer
   • In Event Viewer → System log, look for critical or error events that occurred at the same time as the bugcheck. These can help pinpoint the device or driver involved.
4. Use Driver Verifier if crashes persist
   • Run verifier from an elevated command prompt to start Driver Verifier Manager.
   • Configure it to monitor non-Microsoft drivers suspected of causing the issue (keep the set as small as possible to reduce overhead).
   • If Driver Verifier forces a reproducible crash, analyze the new dump; it often points more directly at the faulty driver.

If programming-level debugging is available, the faulting module’s source can be used with WinDbg (using .cxr, kb, u, etc.) to identify and fix the exact code path, but for a typical Windows 11 home scenario, focusing on identifying and updating/removing the problematic driver is the practical path.

---

References:

• Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION