BSOD debugging basics guide - Page 2

qwertylesh · 4th September 2009, 11:26 PM

You dont have C:\Windows\Minidump?

Did you double check the system failure settings under startup and recovery under advanced under system properties?

core69 · 4th September 2009, 11:41 PM

Quote:

Originally Posted by qwertylesh

You dont have C:\Windows\Minidump?

Did you double check the system failure settings under startup and recovery under advanced under system properties?

Yehp thats right.. in the start up and recovery advanced settings this is what i have

Write Debugging information
Small memory Dump (64KB)

Small dump directory:
%SystemRoot%\Minidump

but can't find it in the windows system root..

qwertylesh · 4th September 2009, 11:47 PM

OK, that is strange.
If you goto Run and type %systemroot% it brings up c:\windows huh?

Have you gone to your folder options and chosen to show hidden files (just incase it somehow has a hidden attribute) Neve seen the need to, although I have on some systems seen the system32 directory hidden (probably caused from malware)

Also try going to your command prompt, going to C:\Windows and trying Dir Minidump or Dir /A:H

---
Edit: You should disable automatic restart on system failure, if you find the Stop code is 0x0000024 or 0x000007B or 7E it could be a problem related to your disk in some way.

Also you should reveiw your bootup parameters (boot.ini for XP) and bcdedit for Vista (alternatively for vista, you can get a free VistaBootPro version from |MajorGeeks| VBP is very user friendly compared to bcdedit) see if the debug flag is listed, if so, remove it please.

core69 · 5th September 2009, 12:10 AM

Quote:

Originally Posted by qwertylesh

Edit: You should disable automatic restart on system failure, if you find the Stop code is 0x0000024 or 0x000007B or 7E it could be a problem related to your disk in some way.
.

Hi,

I now disabled automatic restart on system failure. This time round when the bsod came up i saw at the bottom of the screen it was now writing the dump file.

what do you know, i have a minidump dir now

i'm new to this debugging and dont understand what it really is telling me.
i read on the guide "Other areas of the Analysis to take note of is the image_name and module_name entry under the debugging details, these fields will indicate a specific file if your BSOD is driver related."

MODULE_NAME: nt
IMAGE_NAME: memory_corruption

Is there somewhere i can post what the bugcheck analysis came up with and someone help me with the problem?

Cheers!!

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

qwertylesh · 5th September 2009, 12:22 AM

If you like you can, but maybe put it in a code box (the hash symbol next to quote).
I think though that from what youve pasted so far that it looks like your system is unstable.

just as I posted earlier in another thread:

Quote:

You should also ensure your ram is running at its stock voltage, at its stock frequency and to at least 3 passes with memtest make sure it has no addressing errors, then see if a stress test like OCCT or Prime95 exposes any instability or bsods.

does it give you any specific file names or the stop code?

core69 · 5th September 2009, 6:28 AM

Quote:

Originally Posted by qwertylesh

If you like you can, but maybe put it in a code box (the hash symbol next to quote).
I think though that from what youve pasted so far that it looks like your system is unstable.

Oh man, so its unstable but i'm not oc or anything.. pretty much everything is on normal or auto..

This is the first debug check

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini090409-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

WARNING: Whitespace at start of path element
Symbol search path is: SRV*C:\custompath*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\Windows\System32; http://www.alexander.com/SymServe
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Fri Sep  4 23:42:11.406 2009 (GMT+10)
System Uptime: 0 days 0:44:28.139
Loading Kernel Symbols
...............................................................
.......................................................
Loading User Symbols
Loading unloaded module list
.................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000000A, {c8b5fa5c, 2, 1, 805168c5}

Probably caused by : memory_corruption ( nt!MiReferenceSubsection+23 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c8b5fa5c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805168c5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  c8b5fa5c 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8050ea92 to 805168c5

STACK_TEXT:  
b38127b8 8050ea92 8a539f30 b381288c 00000000 nt!MiReferenceSubsection+0x23
b38127e0 804e4301 8a539f30 00000000 00000000 nt!MmFlushSection+0x82
b3812868 b7e24b75 8a5c8b84 00000000 00000000 nt!CcFlushCache+0x1d3
b3812894 b7e3e924 8a15cef0 e1903648 00000000 Ntfs!NtfsFlushUserStream+0x6c
b3812918 b7e5a7ac 8a15cef0 8a5e4460 00000001 Ntfs!NtfsFlushVolume+0x22a
b3812990 b7e24ae3 8a15cef0 8a140788 88c2ce88 Ntfs!NtfsCommonFlushBuffers+0xd1
b38129f4 804eeeb1 8a5e4380 8a140788 8a140918 Ntfs!NtfsFsdFlushBuffers+0x92
b3812a04 b7eefb2f 8a5e4c18 8a140788 00000000 nt!IopfCallDriver+0x31
b3812a18 b7eefffb b3812a30 8a1468d0 8a68df38 fltMgr!FltpPassThrough+0xf9
b3812a48 804eeeb1 8a5e6840 8a140788 806e4410 fltMgr!FltpDispatch+0xf3
b3812a58 8057e688 88c2ce88 8a140788 8a14c110 nt!IopfCallDriver+0x31
b3812a6c 80575ccb 8a5e6840 8a140788 88c2ce88 nt!IopSynchronousServiceTail+0x60
b3812ae4 8054060c 800009fc b3812b84 b3812dac nt!NtFlushBuffersFile+0x1b9
b3812ae4 804ff6b5 800009fc b3812b84 b3812dac nt!KiFastCallEntry+0xfc
b3812b64 805c69df 800009fc b3812b84 8a1466c0 nt!ZwFlushBuffersFile+0x11
b3812dac 805ce794 b81b7ad0 00000000 00000000 nt!PopFlushVolumeWorker+0xf9
b3812ddc 805450ce 805c68e6 b81b7ad0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiReferenceSubsection+23

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  41107b0d

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c8b5fa5c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805168c5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  c8b5fa5c 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8050ea92 to 805168c5

STACK_TEXT:  
b38127b8 8050ea92 8a539f30 b381288c 00000000 nt!MiReferenceSubsection+0x23
b38127e0 804e4301 8a539f30 00000000 00000000 nt!MmFlushSection+0x82
b3812868 b7e24b75 8a5c8b84 00000000 00000000 nt!CcFlushCache+0x1d3
b3812894 b7e3e924 8a15cef0 e1903648 00000000 Ntfs!NtfsFlushUserStream+0x6c
b3812918 b7e5a7ac 8a15cef0 8a5e4460 00000001 Ntfs!NtfsFlushVolume+0x22a
b3812990 b7e24ae3 8a15cef0 8a140788 88c2ce88 Ntfs!NtfsCommonFlushBuffers+0xd1
b38129f4 804eeeb1 8a5e4380 8a140788 8a140918 Ntfs!NtfsFsdFlushBuffers+0x92
b3812a04 b7eefb2f 8a5e4c18 8a140788 00000000 nt!IopfCallDriver+0x31
b3812a18 b7eefffb b3812a30 8a1468d0 8a68df38 fltMgr!FltpPassThrough+0xf9
b3812a48 804eeeb1 8a5e6840 8a140788 806e4410 fltMgr!FltpDispatch+0xf3
b3812a58 8057e688 88c2ce88 8a140788 8a14c110 nt!IopfCallDriver+0x31
b3812a6c 80575ccb 8a5e6840 8a140788 88c2ce88 nt!IopSynchronousServiceTail+0x60
b3812ae4 8054060c 800009fc b3812b84 b3812dac nt!NtFlushBuffersFile+0x1b9
b3812ae4 804ff6b5 800009fc b3812b84 b3812dac nt!KiFastCallEntry+0xfc
b3812b64 805c69df 800009fc b3812b84 8a1466c0 nt!ZwFlushBuffersFile+0x11
b3812dac 805ce794 b81b7ad0 00000000 00000000 nt!PopFlushVolumeWorker+0xf9
b3812ddc 805450ce 805c68e6 b81b7ad0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiReferenceSubsection+23

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  41107b0d

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c8b5fa5c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805168c5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  c8b5fa5c 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8050ea92 to 805168c5

STACK_TEXT:  
b38127b8 8050ea92 8a539f30 b381288c 00000000 nt!MiReferenceSubsection+0x23
b38127e0 804e4301 8a539f30 00000000 00000000 nt!MmFlushSection+0x82
b3812868 b7e24b75 8a5c8b84 00000000 00000000 nt!CcFlushCache+0x1d3
b3812894 b7e3e924 8a15cef0 e1903648 00000000 Ntfs!NtfsFlushUserStream+0x6c
b3812918 b7e5a7ac 8a15cef0 8a5e4460 00000001 Ntfs!NtfsFlushVolume+0x22a
b3812990 b7e24ae3 8a15cef0 8a140788 88c2ce88 Ntfs!NtfsCommonFlushBuffers+0xd1
b38129f4 804eeeb1 8a5e4380 8a140788 8a140918 Ntfs!NtfsFsdFlushBuffers+0x92
b3812a04 b7eefb2f 8a5e4c18 8a140788 00000000 nt!IopfCallDriver+0x31
b3812a18 b7eefffb b3812a30 8a1468d0 8a68df38 fltMgr!FltpPassThrough+0xf9
b3812a48 804eeeb1 8a5e6840 8a140788 806e4410 fltMgr!FltpDispatch+0xf3
b3812a58 8057e688 88c2ce88 8a140788 8a14c110 nt!IopfCallDriver+0x31
b3812a6c 80575ccb 8a5e6840 8a140788 88c2ce88 nt!IopSynchronousServiceTail+0x60
b3812ae4 8054060c 800009fc b3812b84 b3812dac nt!NtFlushBuffersFile+0x1b9
b3812ae4 804ff6b5 800009fc b3812b84 b3812dac nt!KiFastCallEntry+0xfc
b3812b64 805c69df 800009fc b3812b84 8a1466c0 nt!ZwFlushBuffersFile+0x11
b3812dac 805ce794 b81b7ad0 00000000 00000000 nt!PopFlushVolumeWorker+0xf9
b3812ddc 805450ce 805c68e6 b81b7ad0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiReferenceSubsection+23

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  41107b0d

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

Followup: MachineOwner
---------

1: kd> !Analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c8b5fa5c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805168c5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  c8b5fa5c 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8050ea92 to 805168c5

STACK_TEXT:  
b38127b8 8050ea92 8a539f30 b381288c 00000000 nt!MiReferenceSubsection+0x23
b38127e0 804e4301 8a539f30 00000000 00000000 nt!MmFlushSection+0x82
b3812868 b7e24b75 8a5c8b84 00000000 00000000 nt!CcFlushCache+0x1d3
b3812894 b7e3e924 8a15cef0 e1903648 00000000 Ntfs!NtfsFlushUserStream+0x6c
b3812918 b7e5a7ac 8a15cef0 8a5e4460 00000001 Ntfs!NtfsFlushVolume+0x22a
b3812990 b7e24ae3 8a15cef0 8a140788 88c2ce88 Ntfs!NtfsCommonFlushBuffers+0xd1
b38129f4 804eeeb1 8a5e4380 8a140788 8a140918 Ntfs!NtfsFsdFlushBuffers+0x92
b3812a04 b7eefb2f 8a5e4c18 8a140788 00000000 nt!IopfCallDriver+0x31
b3812a18 b7eefffb b3812a30 8a1468d0 8a68df38 fltMgr!FltpPassThrough+0xf9
b3812a48 804eeeb1 8a5e6840 8a140788 806e4410 fltMgr!FltpDispatch+0xf3
b3812a58 8057e688 88c2ce88 8a140788 8a14c110 nt!IopfCallDriver+0x31
b3812a6c 80575ccb 8a5e6840 8a140788 88c2ce88 nt!IopSynchronousServiceTail+0x60
b3812ae4 8054060c 800009fc b3812b84 b3812dac nt!NtFlushBuffersFile+0x1b9
b3812ae4 804ff6b5 800009fc b3812b84 b3812dac nt!KiFastCallEntry+0xfc
b3812b64 805c69df 800009fc b3812b84 8a1466c0 nt!ZwFlushBuffersFile+0x11
b3812dac 805ce794 b81b7ad0 00000000 00000000 nt!PopFlushVolumeWorker+0xf9
b3812ddc 805450ce 805c68e6 b81b7ad0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiReferenceSubsection+23

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  41107b0d

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c8b5fa5c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805168c5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  c8b5fa5c 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 8050ea92 to 805168c5

STACK_TEXT:  
b38127b8 8050ea92 8a539f30 b381288c 00000000 nt!MiReferenceSubsection+0x23
b38127e0 804e4301 8a539f30 00000000 00000000 nt!MmFlushSection+0x82
b3812868 b7e24b75 8a5c8b84 00000000 00000000 nt!CcFlushCache+0x1d3
b3812894 b7e3e924 8a15cef0 e1903648 00000000 Ntfs!NtfsFlushUserStream+0x6c
b3812918 b7e5a7ac 8a15cef0 8a5e4460 00000001 Ntfs!NtfsFlushVolume+0x22a
b3812990 b7e24ae3 8a15cef0 8a140788 88c2ce88 Ntfs!NtfsCommonFlushBuffers+0xd1
b38129f4 804eeeb1 8a5e4380 8a140788 8a140918 Ntfs!NtfsFsdFlushBuffers+0x92
b3812a04 b7eefb2f 8a5e4c18 8a140788 00000000 nt!IopfCallDriver+0x31
b3812a18 b7eefffb b3812a30 8a1468d0 8a68df38 fltMgr!FltpPassThrough+0xf9
b3812a48 804eeeb1 8a5e6840 8a140788 806e4410 fltMgr!FltpDispatch+0xf3
b3812a58 8057e688 88c2ce88 8a140788 8a14c110 nt!IopfCallDriver+0x31
b3812a6c 80575ccb 8a5e6840 8a140788 88c2ce88 nt!IopSynchronousServiceTail+0x60
b3812ae4 8054060c 800009fc b3812b84 b3812dac nt!NtFlushBuffersFile+0x1b9
b3812ae4 804ff6b5 800009fc b3812b84 b3812dac nt!KiFastCallEntry+0xfc
b3812b64 805c69df 800009fc b3812b84 8a1466c0 nt!ZwFlushBuffersFile+0x11
b3812dac 805ce794 b81b7ad0 00000000 00000000 nt!PopFlushVolumeWorker+0xf9
b3812ddc 805450ce 805c68e6 b81b7ad0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiReferenceSubsection+23
805168c5 895104          mov     dword ptr [ecx+4],edx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiReferenceSubsection+23

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  41107b0d

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

BUCKET_ID:  0xA_nt!MiReferenceSubsection+23

Followup: MachineOwner
---------

EDIT:
System specs
E8500 @stock
Corsair 8500 Dominator DDR2 4gb
Gigabyte GA-EP45-DS3L
9500GT 512
Seasonic 650w psu
VRapotr 150gb new drive with new install yesterday

any help much appreciated

Cheers

TheBear21 · 23rd September 2009, 1:51 AM

From the W7 thread. This is my debug analysis. Looks to be ntkrnlmp.exe?

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {ffffffffc0000005, fffff80002ec86f5, 0, ffffffffffffffff}

Probably caused by : ntkrnlmp.exe ( nt!ExQuerySystemLockInformation+175 )

Followup: MachineOwner
---------

3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80002ec86f5, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception

Debugging Details:
------------------


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

FAULTING_IP: 
nt!ExQuerySystemLockInformation+175
fffff800`02ec86f5 488b80b8030000  mov     rax,qword ptr [rax+3B8h]

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  ffffffffffffffff

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002ebd0e0
 ffffffffffffffff 

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x1E

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002cc6a17 to fffff80002c86f00

STACK_TEXT:  
fffff880`03efd258 fffff800`02cc6a17 : 00000000`0000001e ffffffff`c0000005 fffff800`02ec86f5 00000000`00000000 : nt!KeBugCheckEx
fffff880`03efd260 fffff800`02c86542 : fffff880`03efda38 00000000`00000158 fffff880`03efdae0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x460da
fffff880`03efd900 fffff800`02c84e4a : 00000000`00000000 00000000`00000000 00000014`00000000 00000000`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`03efdae0 fffff800`02ec86f5 : 00000000`00000008 fffff880`03efe180 00000000`00000000 fffff800`02ef94c9 : nt!KiGeneralProtectionFault+0x10a
fffff880`03efdc70 fffff800`030e6445 : fffff880`07ea0000 fffff800`00020000 00000000`00000000 fffff880`03efdd60 : nt!ExQuerySystemLockInformation+0x175
fffff880`03efdce0 fffff800`02fe958f : 00000000`00000000 00000000`00000000 fffff880`07ea0000 fffffa80`06f98590 : nt!ExpGetLockInformation+0x55
fffff880`03efdd20 fffff800`02f82e49 : fffff8a0`01c5a000 fffffa80`6365734b fffff880`010b52a8 fffff8a0`00000000 : nt! ?? ::NNGAKEGL::`string'+0x5821f
fffff880`03efe0c0 fffff800`02c86153 : 00000000`00013268 fffff880`02fe0000 00000000`00000001 00000000`00000000 : nt!NtQuerySystemInformation+0x4d
fffff880`03efe100 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!ExQuerySystemLockInformation+175
fffff800`02ec86f5 488b80b8030000  mov     rax,qword ptr [rax+3B8h]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nt!ExQuerySystemLockInformation+175

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc600

FAILURE_BUCKET_ID:  X64_0x1E_nt!ExQuerySystemLockInformation+175

BUCKET_ID:  X64_0x1E_nt!ExQuerySystemLockInformation+175

Followup: MachineOwner
---------

qwertylesh · 23rd September 2009, 10:08 AM

Your crash is quite interesting and unfortunately a little vague.
seems to be a problem faulting with with a MS Client Server Runtime Server subsystem process and that kernal process, whats interesting is that its crashing with a bugcheck flag and not a stop code, normally if you get a bug check crash and you dont have the debug flag enabled this is an indication that you have unstable hardware, but since your crashes are occuring between two operating system processes, i'm incline to suspect its a problem with the operating system state more so then hardware.

I think the best way for you to determine weather its a hardware bsod or not (and you probably don't want to hear/read this) is to use a temporary disk and setup a fresh W7, stress it to see if it bsods (or use any other method you know of that'll allow you to replicate this bsod) If it stops occurring and you cant get the fresh one to bsod then its definitly a problem with your installation state, and you could try sfc or even a system restore to correct the os process related crashes.

If you find that its still bsod'ing with a fresh temp hdd & os install, then its very likely you have a damaged motherboard chipset, especially if you've tested other components and theyve come back as healthy (ie ram, cpu, gfx card)

It sucks that its not pointing at a specific driver file which would be a sinch to correct. Yeah, just like you've probably already gathered, its either a problem with the critical section of the os or its a faulting piece of hardware which the dumps cannot identify.

Which leads me to another thing, Ive found with crash debugging you can identify a number of different hardware bsod's, particularly bad hdd's, unstable and faulty ram and unstable and faulty processors, however there are other hardware bsods where when you debug them it wont tell you diddly and just point at the kernel as being a possible cause like bad mobo or a buggy psu.

TheBear21 · 23rd September 2009, 10:30 AM

Quote:

Originally Posted by qwertylesh

Your crash is quite interesting and unfortunately a little vague.
seems to be a problem faulting with with a MS Client Server Runtime Server subsystem process and that kernal process, whats interesting is that its crashing with a bugcheck flag and not a stop code, normally if you get a bug check crash and you dont have the debug flag enabled this is an indication that you have unstable hardware, but since your crashes are occuring between two operating system processes, i'm incline to suspect its a problem with the operating system state more so then hardware.

I think the best way for you to determine weather its a hardware bsod or not (and you probably don't want to hear/read this) is to use a temporary disk and setup a fresh W7, stress it to see if it bsods (or use any other method you know of that'll allow you to replicate this bsod) If it stops occurring and you cant get the fresh one to bsod then its definitly a problem with your installation state, and you could try sfc or even a system restore to correct the os process related crashes.

If you find that its still bsod'ing with a fresh temp hdd & os install, then its very likely you have a damaged motherboard chipset, especially if you've tested other components and theyve come back as healthy (ie ram, cpu, gfx card)

It sucks that its not pointing at a specific driver file which would be a sinch to correct. Yeah, just like you've probably already gathered, its either a problem with the critical section of the os or its a faulting piece of hardware which the dumps cannot identify.

Which leads me to another thing, Ive found with crash debugging you can identify a number of different hardware bsod's, particularly bad hdd's, unstable and faulty ram and unstable and faulty processors, however there are other hardware bsods where when you debug them it wont tell you diddly and just point at the kernel as being a possible cause like bad mobo or a buggy psu.

Thanks for that. This has been on going. Has happened through Vista, W7 RC and W7 RTM. So I can't see how it would be a dodgy O/S install.

A lot of the BSOD's have pointed towards memory errors. I originally had Geil ultras (4x1gb) that I replaced with the Corsairs. I find memory errors unlikely now that I changed them out and the Corsairs are known to be rock solid. I have run extensive Memtests (each stick, in each slot 12 hour tests) that all come back fine (unless done immediately after the bsod).

I have had in the back of my mind that there might be something wrong with my m/b chipset. Just needed a way to confirm it. Might contact retailer and try to organise RMA.

Thanks

qwertylesh · 23rd September 2009, 10:38 AM

Oh if thats the case then its probably the memory controller.
if its an intel that would be located on your northbridge chipset.
:\

But yeah one thing I can say for sure is the OS is not supposed to bugcheck if you do not have the /Debug parameter in your boot loader. since you wouldn't it shows theres a serious problem, you could say I was hoping it was the OS state, but its not if youve had the bsods on multiple installs.

Ive dealt with faulty mobo chipsets before that bugcheck and they are a PITA to work on, especially when your not certain of the fault you tend to end up trying replacement Vid, mem, cpu, psu and hdd and Os before you consider trying another mobo.

TheBear21 · 23rd September 2009, 10:42 AM

Quote:

Originally Posted by qwertylesh

Oh if thats the case then its probably the memory controller.
if its an intel that would be located on your northbridge chipset.
:\

But yeah one thing I can say for sure is the OS is not supposed to bugcheck if you do not have the /Debug parameter in your boot loader. since you wouldn't it shows theres a serious problem, you could say I was hoping it was the OS state, but its not if youve had the bsods on multiple installs.

Ive dealt with faulty mobo chipsets before that bugcheck and they are a PITA to work on, especially when your not certain of the fault you tend to end up trying replacement Vid, mem, cpu, psu and hdd and Os before you consider trying another mobo.

How can I convince retailer that there is a problem, or will they have some secret means of finding these things out. I haven't been able to repeat the errors. I can go a month fine, and then every 15 minutes I will get errors.

qwertylesh · 23rd September 2009, 10:54 AM

If you've used a thorough bios configuration for the ram, multiple ram brands (which you have), and your cpu + psu work stable, without trouble on other systems. You'll just need to be firm, explain that it gets bugchecks and that none of your other parts are unstable. Give them plenty of time to try to expose the crash and relentlessly insist that the motherboard causes the bugchecks with different operating systems.

Since you haven't got a definite way if replicating the bugcheck it'll probably take them a while to get it to play up for them to see its got the fault, but eventually they should be able to get it to crash and if they're thorough and using new parts for testing they should rma the motherboard for you.

have you tried linpacking (intel burn test/linx) the cpu at stock for 30 passes to see if the residual norm values stay the same, you should if not to be certain its not instability with your processor you've been oc'ing.

basically though all i can suggest is you to be firm and insistent that the motherboard has the fault as long as you know your other current core parts (ram/cpu) are perfectly healthy, and as long as you give the store enough time to test (ie at least a week or so) and as long as they have a competent technician, you'll get the motherboard rma'd.
Be sure your cpu is healthy first tho, you could probably just linpack on the current board since it wont stress the north & southbridge.

IMO also, with the chipset fault and in regard to the shops testing the mobo, a 24 hour prime blend should expose the mobo problem. theres no way after a week of uptime and a few 24 hour prime blends that the problem isn't going to occur.

TheBear21 · 23rd September 2009, 11:20 AM

Thanks for all this help. Just ran a quick 5 pass burn test just to see. Everything there came back ok.

Will see how I go.

elstado · 23rd September 2009, 7:43 PM

Hey, great guide.

I've been having issues in the past few weeks with random BSODs occurring every few days. I want to try and debug myself, but I have one terribly noob question:

Do I need to download the Windows Symbol Packages?

I see the package for Vista x86 SP2 retail is:
Windows Vista SP2 and Windows Server 2008 SP2 x86 retail symbols, all languages (File size: 281 MB - Most customers want this package.)

It's quite a large file to download (for me anyway) and I just want to make sure I need this to debug my BSOD dumps.

Thanks.

qwertylesh · 23rd September 2009, 8:07 PM

Thats one of the beauties of the method listed in the OP, it will retrieve only the symbol files you need to debug the crash dump, you don't need to get the whole 281 meg package.

If you use the guide you'll very likely download less then 10 meg of symbol files

Edit: Don't download the 281 meg package, just put 'C:\Windows\System32; http://www.alexander.com/SymServe' in the image search path (this url works out what file versions you have for what symbol files you need) and this in the symbol search path 'SRV*C:\SymbolFiles*http://msdl.microsoft.com/download/symbols' (this url is where it will automatically download the apropriate symbol files from when you open a crash dump)

23rd September 2009, 11:20 AM	#28
TheBear21 Member Join Date: Aug 2007 Location: Central QLD Posts: 1,777	Thanks for all this help. Just ran a quick 5 pass burn test just to see. Everything there came back ok. Will see how I go. __________________ flickr \| Soundcloud

23rd September 2009, 7:43 PM	#29
elstado Member Join Date: Feb 2009 Location: Perth (SOR), W.A. Posts: 1,373	Hey, great guide. I've been having issues in the past few weeks with random BSODs occurring every few days. I want to try and debug myself, but I have one terribly noob question: Do I need to download the Windows Symbol Packages? I see the package for Vista x86 SP2 retail is: Windows Vista SP2 and Windows Server 2008 SP2 x86 retail symbols, all languages (File size: 281 MB - Most customers want this package.) It's quite a large file to download (for me anyway) and I just want to make sure I need this to debug my BSOD dumps. Thanks. __________________ Intel E8400 OC@3.6GHz, EP35-DS3R, 4GB DDR2 800MHz, Gigabyte 1GB GTX560 OC@830MHz, Intel X25-M G2 80GB SSD, 2x 500GB WD BLUE AAKS, Antec Sonata III, Zalman 9700, 22" Samsung + 24" BenQ, & Win7 x64 SP1 CHECK OUT MY PRACTICAL CYCLING AND CYCLE TOURING BLOG: VELOPHILEAUSTRALIA!