15

My computer running Windows 7 x64 crushes time to time. Could you please advise how to analyze the memory dump or point out possible cause and further troubleshooting steps?

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff96000015de8, 0xfffff88007db9fb0, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 080210-24819-01.

The quotation from the result of WinDbg run

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

...

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: explorer.exe

...

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

Is there any way to understand which particular driver has a problem?

1

3 Answers 3

19

I would use Microsoft's debugging tool: WinDbg. It can read and automatically analyze memory dumps like yours. (The WinDbg command is aptly named: !analyze)

The tool is powerful, but quite complex. Here is a detailed HOW TO guide.

The same forum suggests BlueScreenView. I have not tried it; it's probably simpler to use, but does not give as detailed information.


update:

Is there any way to understand which particular driver has a problem?

After !analyze run k or kd. This will show the stack trace right before the crash. The stack trace is the list of function calls made right before the crash, with the most recent one at the top. You should at least be able to learn the filenames of the modules (DLL's) involved.

I suggest sharing the full results of !analyze and/or the memory dump with people who are are skilled at WinDbg and are interested in helping. The previously linked MajorGeeks forum looks like a good place.

3
  • Thanks! Do you have any ideas what is next step? I added results of WinDbg run
    – bublegumm
    Aug 4, 2010 at 0:03
  • 1
    That MajorGeeks Forum thread is great, offers a pretty good step by step on how to read a memory.dmp file.
    – russds
    Oct 1, 2015 at 15:11
  • Without some in-depth knowledge trying to make sense alone of the !analyze -v output (and BlueScreenView offers mostly that), is almost pointless. Suggesting to look at the call stack may be sensible on StackOverflow, but is a bit silly here. Besides, I've done my share of post-mortem Windows driver debugging and many of the cases are by far not as clear-cut as you make it sound. Apr 16, 2018 at 9:25
1

There is a free tool called BlueScreenView it will analyze the dump files from c:\windows\minidump and will show a graphical windows ,so user can identify the errors

-1

This may be causing it http://support.microsoft.com/kb/980932 (Use "View and request hotfix downloads" at the top of the page to request the hotfix, do not apply the Hotfix if it is not a 1394 Firewire issue)

Otherwise its Probably a video driver causing it, seems to be common in W7, but other hardware can cause it also, bad memory modules are also highly suspect.

Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION

http://msdn.microsoft.com/en-us/library/ff558949(v=VS.85).aspx

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. Parameters

The following parameters are displayed on the blue screen. ParameterDescription 1The exception that caused the bug check 2The address of the exception record for the exception that caused the bug check 3The address of the context record for the exception that caused the bug check 40

Cause

This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .