Sign in with
Sign up | Sign in
Your question
Solved

BSOD bugcheck (crash dump analysis available)

Tags:
  • Windows
  • Windows 7
  • Blue Screen
  • Crash
Last response: in Windows 7
Share
October 12, 2014 12:01:25 PM

Hi

I just got a BSOD and I would like to know if anyone can help me about this.

I replaced a faulty GPU one week ago so it may be linked.

Update: I forgot to mention that this happened while is was browsing on firefox.

Please help!!

I analyzed it with WinDbg and got the following:


Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18409.amd64fre.win7sp1_gdr.140303-2144
Machine Name:
Kernel base = 0xfffff800`02e1e000 PsLoadedModuleList = 0xfffff800`03061890
Debug session time: Sun Oct 12 13:47:51.736 2014 (UTC - 4:00)
System Uptime: 0 days 3:30:38.011
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {10060000a, 2, 1, fffff80002ec4622}

Probably caused by : ntkrnlmp.exe ( nt!KxWaitForLockOwnerShip+12 )

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

6: 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: 000000010060000a, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec4622, address which referenced memory

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


WRITE_ADDRESS: 000000010060000a

CURRENT_IRQL: 2

FAULTING_IP:
nt!KxWaitForLockOwnerShip+12
fffff800`02ec4622 48890a mov qword ptr [rdx],rcx

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: services.exe

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

TRAP_FRAME: fffff88006fc7820 -- (.trap 0xfffff88006fc7820)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffff88006fc7a28
rdx=000000010060000a rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec4622 rsp=fffff88006fc79b0 rbp=fffff88006fc7b60
r8=fffffa800e441218 r9=0000000000000000 r10=ffffffffffffffbf
r11=fffffa800ecd2601 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nt!KxWaitForLockOwnerShip+0x12:
fffff800`02ec4622 48890a mov qword ptr [rdx],rcx ds:00000001`0060000a=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002e93169 to fffff80002e93bc0

STACK_TEXT:
fffff880`06fc76d8 fffff800`02e93169 : 00000000`0000000a 00000001`0060000a 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`06fc76e0 fffff800`02e91de0 : fffffa80`0e3f4b50 fffff880`06fc7a90 00000000`ffff0000 fffffa80`0e430a00 : nt!KiBugCheckDispatch+0x69
fffff880`06fc7820 fffff800`02ec4622 : 00000000`00000000 fffffa80`0e420ad0 00000000`0233fcb0 fffff880`06fc7aa0 : nt!KiPageFault+0x260
fffff880`06fc79b0 fffff800`02e7ef9c : fffffa80`0e430a00 fffff880`06fc7a68 fffff880`06fc7a88 00000000`00000001 : nt!KxWaitForLockOwnerShip+0x12
fffff880`06fc79e0 fffff800`02e92e53 : fffffa80`0f375060 00000000`770145c0 fffff880`00000102 00000000`00000000 : nt!NtWaitForWorkViaWorkerFactory+0x41b
fffff880`06fc7ae0 00000000`76f62bba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0233fac8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f62bba


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KxWaitForLockOwnerShip+12
fffff800`02ec4622 48890a mov qword ptr [rdx],rcx

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KxWaitForLockOwnerShip+12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 531590fb

IMAGE_VERSION: 6.1.7601.18409

FAILURE_BUCKET_ID: X64_0xA_nt!KxWaitForLockOwnerShip+12

BUCKET_ID: X64_0xA_nt!KxWaitForLockOwnerShip+12

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0xa_nt!kxwaitforlockownership+12

FAILURE_ID_HASH: {69f619cc-5abb-1c14-4270-8e17efbcd182}

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

More about : bsod bugcheck crash dump analysis

Best solution

a b $ Windows 7
October 12, 2014 4:04:48 PM

not very useful, it just says that some driver tried to write to a memory location it did not own.
the service.exe is a generic program that allows other programs to run in the background.

problem is you don't have the name of the other program, and you don't know why it was trying at write to a bad address.

out of all the causes, testing the physical RAM for memory /bios setting errors is the easiest.
you would download and run memtest86 on is own boot image (cd, or thumb driver)
if that test passes, then you would start looking at updating non microsoft drivers on your system.
(assumes you run windows update and get the microsoft drivers fixes)

after you update the drivers and reboot, if you still have the problem
you would put the memory dump file on a server so someone can take a quick look.
(there are so many bad drivers that corrupt memory, people can recognize them just by the driver name and date)

since you have the windows debugger installed
you can use the command

lmiftsm (this will dump the list of the drivers, check the dates and look for old versions that you could update)
this command
!for_each_module !chkimg @#ModuleName
(this will try to check to see if you core windows files are corrupted while in the memory of your machine)
it will produce a errors for files that are not owned by microsoft (with some exceptions)


There are other things you can do to Isolate the problem down if you can not find the cause.
you would use verifier.exe to set debugging flags that make window look for drivers that corrupt memory.
and you set your memory dump type to kernel or full to make the crash dump contain the debugging info and allow more debugging commands to be used.
Share
October 12, 2014 5:17:00 PM

johnbl said:
not very useful, it just says that some driver tried to write to a memory location it did not own.
the service.exe is a generic program that allows other programs to run in the background.

problem is you don't have the name of the other program, and you don't know why it was trying at write to a bad address.

out of all the causes, testing the physical RAM for memory /bios setting errors is the easiest.
you would download and run memtest86 on is own boot image (cd, or thumb driver)
if that test passes, then you would start looking at updating non microsoft drivers on your system.
(assumes you run windows update and get the microsoft drivers fixes)

after you update the drivers and reboot, if you still have the problem
you would put the memory dump file on a server so someone can take a quick look.
(there are so many bad drivers that corrupt memory, people can recognize them just by the driver name and date)

since you have the windows debugger installed
you can use the command

lmiftsm (this will dump the list of the drivers, check the dates and look for old versions that you could update)
this command
!for_each_module !chkimg @#ModuleName
(this will try to check to see if you core windows files are corrupted while in the memory of your machine)
it will produce a errors for files that are not owned by microsoft (with some exceptions)


There are other things you can do to Isolate the problem down if you can not find the cause.
you would use verifier.exe to set debugging flags that make window look for drivers that corrupt memory.
and you set your memory dump type to kernel or full to make the crash dump contain the debugging info and allow more debugging commands to be used.


Alright

I will try your trouble shooting method.

I did run Memtest before and It passed, I will try to run it to individual ram modules to be more thorough (i ran it on both before).

How do you run lmiftsm and chkimg on WinDbg, im a bit noob a it?

Could this kind of BSOD be an isolated incident, its the first it happened and I didn't happen again. However, it may be linked with my new GPU drivers so I will reinstall them.

Thank you for your answer, I will keep you informed.
m
0
l
Related resources
October 13, 2014 6:53:11 AM

Hi

Yesterday, I sent my mini-dump files to someone from the Microsoft forum and he seems to have isolated the cause of my problem to AMD AODDriver.

It makes total sense since I had trouble with it last week and changed some registry values from a tutorial I found on Tom's Hardware to resolve the issue I had.

To be on the safe side I will check my RAM then I will try to clean reinstall my AMD Drivers.

Thank you.
m
0
l
a b $ Windows 7
October 13, 2014 7:56:56 AM

the AMD AODDriver is a overclocking driver for the video card. normally you see a bugcheck in a graphics subsystem when that driver causes a problem.
run without the driver installed for a while and make sure your problem is gone.

to enter the windows debugger commands, when you bring up the debugger the very last line at the bottom of the screen lets you enter in a command. (right next to the bottom border)
m
0
l
!