Computer rebooted from a bug check 0x0000003b.

Question

Hi, in the past week I have received two BSoD and one random reboot. The last BSoD game me some details under the control panel (see image). I built this PC the past summer and the only hardware changes I have made was adding 16GB of identical ram (bringing my total to 32GB) on September 22nd. Last night I took the ram out and put it back in and then ran the MemTest86+ for 12hrs and 3 full passes, but this afternoon is when I received my last BSoD. I am a Software Engineering student so I am comfortable with computers, but I am completely lost at what is causing this issue. Any help is greatly appreciated. 

Answer 1

Hi and thanks for reaching out. My name is William. I'm a Microsoft Windows Certified Professional and Systems Administrator. I'll be happy to help you out today.

0x0000003b is otherwise known as a SYSTEM_SERVICE_EXCEPTION, i.e. an essential Windows service (or even a 3rd party service) cause a fault in the kernel, halting the system.

When your system crashes it will create a dump file(s) in C:\Windows\Minidumps. I can analyze those files for the potential cause of the system halting. Can you upload the .dmp file(s) to OneDrive, Google Drive, Dropbox or some other file sharing service and share the link here?

Answer 2

Yes, there are two dmp files and they are both from today. The second one has happened since making the original post. Here is the link to a google drive folder containing them both: https://drive.google.com/drive/folders/16Zs5o2zNz6a3yheGlRr0JNd6OFdYjhlv?usp=sharing

Answer 3

When you recommend "rolling back to an older build for the GPU" do you mean an older driver version?

Also if you can confidently say that it is Nvidia display driver, does this mean I am not at risk of my BSoDs causing a harddrive malfunction and I loosing all my data? I am currently creating a clone of my disk, but I am nervous about losing all my data.

Answer 4

So both dumps indicate hardware as the cause, but is rarely the case; the WinDbg heuristics engine just does not have enough to go on. Without a conclusive stack trace, I cannot tell you for sure what is causing bugcheck, I can only infer.

I looked at the other dump just now and this is similar to the first in that system halts when doing some access check routines, but in this case this happened while parsing a registry key. Usually, when I see registry key prior to crash, I suspect 3rd party antivirus reg filters. I did not see in the 1st dump, but in this one I see an unloaded module for mcupdate.dll, a McAfee antivirus module. You wouldn't happen to be running McAfee?

Answer 5

The stack trace is not remarkable, no signs of 3rd party drivers. There is some access checking being done on object prior to bugcheck.

11: kd> k

Child-SP RetAddr Call Site

00 ffffba0cafb70c38 fffff80252406469 nt!KeBugCheckEx

01 ffffba0cafb70c40 fffff802524058bc nt!KiBugCheckDispatch+0x69

02 ffffba0cafb70d80 fffff802523fd402 nt!KiSystemServiceHandler+0x7c

03 ffffba0cafb70dc0 fffff80252252d97 nt!RtlpExecuteHandlerForException+0x12

04 ffffba0cafb70df0 fffff802522519a6 nt!RtlDispatchException+0x297

05 ffffba0cafb71510 fffff802524065ac nt!KiDispatchException+0x186

06 ffffba0cafb71bd0 fffff80252402743 nt!KiExceptionDispatch+0x12c

07 ffffba0cafb71db0 fffff802522e8cd8 nt!KiPageFault+0x443

08 ffffba0cafb71f40 fffff802522e73d4 nt!SepAccessCheck+0x6c8

09 ffffba0cafb720b0 fffff802522e5c07 nt!SeAccessCheckWithHintWithAdminlessChecks+0x4f4

0a ffffba0cafb72290 fffff802526f0319 nt!SeAccessCheck+0x67

0b ffffba0cafb72300 fffff802526afbe9 nt!ObpCreateHandle+0x7c9

0c ffffba0cafb724f0 fffff802526ad0c3 nt!ObOpenObjectByPointer+0x1b9

0d ffffba0cafb72770 fffff802526acea3 nt!PsOpenThread+0x213

0e ffffba0cafb72ac0 fffff80252405eb8 nt!NtOpenThread+0x23

0f ffffba0cafb72b00 000002a1f8b0aa34 nt!KiSystemServiceCopyEnd+0x28

10 000000b3ffffc1f8 0000000000000000 0x000002a1`f8b0aa34

The object is likely a driver. Which driver, I cant specifically say, but I can infer from the thread dump it is Nvidia display driver, nvlddmkm.sys:

...

ffffba0cafb70ba8 fffff8025af5dbffUnable to load image \SystemRoot\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_edf184f24a37bacd\nvlddmkm.sys, Win32 error 0n2

*** WARNING: Unable to verify timestamp for nvlddmkm.sys

nvlddmkm+0x1cdbff

ffffba0cafb70bb0 0000000000000001

ffffba0cafb70bb8 0000000000000000

ffffba0cafb70bc0 ffffba0cafb71d08

ffffba0cafb70bc8 ffffba0cafb70e30

ffffba0cafb70bd0 fffff80252000000 nt!VrpRegistryString <PERF> (nt+0x0)

ffffba0cafb70bd8 ffffba0cafb713e0

ffffba0cafb70be0 fffff80252405eb8 nt!KiSystemServiceCopyEnd+0x28

ffffba0cafb70be8 fffff80252405840 nt!KiSystemServiceHandler

ffffba0cafb70bf0 ffffba0cafb71330

ffffba0cafb70bf8 fffff802523f4647 nt!KeBugCheckEx+0x107

ffffba0cafb70c00 0000000000000001

ffffba0cafb70c08 fffff8025ae9c522 nvlddmkm+0x10c522

ffffba0cafb70c10 fffff802520e3868 nt!setjmpexused <PERF> (nt+0xe3868)

ffffba0cafb70c18 0000000000000000

ffffba0cafb70c20 0000000000000000

ffffba0cafb70c28 0000000000000000

ffffba0cafb70c30 0000000000040282

ffffba0cafb70c38 fffff80252406469 nt!KiBugCheckDispatch+0x69

ffffba0cafb70c40 000000000000003b

ffffba0cafb70c48 00000000c0000005

ffffba0cafb70c50 fffff802522e8cd8 nt!SepAccessCheck+0x6c8

ffffba0cafb70c58 ffffba0cafb71540

...

Without another dump to compare tis against, I would recommend rolling back to an older build for the GPU since you are at the current build.

However, if you can reproduce this fairly consistently, then you should enable driver verifer as it may assist with isolating the cause at next crash. To enable driver verifier, see this guide: https://www.sysnative.com/forums/threads/driver...

Note, you do not want to leave driver verifier running for extended times. Because of its invasive nature hooking 3rd party drivers, it can introduce performance issues into the system or crash it out-right on boot if issues are detected with boot drivers.