BSOD
-
Wednesday, February 13, 2013 3:49 AM
Had a BSOD but did not catch the error message. I had not installed any new hardware or software recently. It occurred while I was coding a VBA routine -- but I was not running any of the code.
After the BSOD, I did a disk check on my boot disk. It did not return any errors. I also have a RAID10 data drive which is in a verify/repair process -- this is not unusual after an abnormal shutdown, in my experience. I have had an occasional bad HDD, but not for some time. I plan to run chkdsk on the RAID array after it finishes with the verify/repair (assuming that goes well.
Some of my machine characteristics:
I7 processor
12 GB RAM
W7 - 64 bit Prof
WHQL certified nVidia driver
Boot disc is a 128GB SSD; RAID10 array for D: Drive consisting of four 300GB drives.Any suggestions appreciated. Thanks
My machine:
Minidump File was generated. Here is an excerpt (the complete file is at the link:
BugCheck A, {80, 2, 1, fffff800032952ff} Probably caused by : ntkrnlmp.exe ( nt!KeAcquireInStackQueuedSpinLock+5f ) Followup: MachineOwner --------- 0: 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: 0000000000000080, 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: fffff800032952ff, address which referenced memory
Ron
- Moved by Carey FrischMVP, Moderator Wednesday, February 13, 2013 8:33 AM Relocated to proper forum
All Replies
-
Friday, February 15, 2013 12:20 AMCan you post the rest of the !analyze -v?
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ” How to ask a question that is fixable.
-
Friday, February 15, 2013 2:42 AM
I guess in answer to both Zig Zag and Imperfect is that I thought the link to the MiniDump file I posted in my original question would have enabled you to download and analyze it. That is why I only posted a portion. Since that link may not have worked, here is the full file as presented to me by Windbg. If the link does not work for you, I'm not sure what to do -- It works for me and I thought I had followed the process to enable sharing (via Skydrive). It is still there in my original question, and still seems to work.
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [D:\Users\Ron\Desktop\021213-15740-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: SRV*D:\Symbols*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 Built by: 7601.17944.amd64fre.win7sp1_gdr.120830-0333 Machine Name: Kernel base = 0xfffff800`0320d000 PsLoadedModuleList = 0xfffff800`03451670 Debug session time: Tue Feb 12 19:57:15.853 2013 (UTC - 5:00) System Uptime: 0 days 16:46:10.743 Loading Kernel Symbols ............................................................... ................................................................ ............................................................. Loading User Symbols Loading unloaded module list ............................ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {80, 2, 1, fffff800032952ff} Probably caused by : ntkrnlmp.exe ( nt!KeAcquireInStackQueuedSpinLock+5f ) Followup: MachineOwner --------- 0: 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: 0000000000000080, 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: fffff800032952ff, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800034bb100 0000000000000080 CURRENT_IRQL: 2 FAULTING_IP: nt!KeAcquireInStackQueuedSpinLock+5f fffff800`032952ff 488717 xchg rdx,qword ptr [rdi] CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: SearchFilterHo TRAP_FRAME: fffff880118de700 -- (.trap 0xfffff880118de700) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000 rdx=fffff880118de910 rsi=0000000000000000 rdi=0000000000000000 rip=fffff800032952ff rsp=fffff880118de890 rbp=fffff880118deca0 r8=fffff880118de910 r9=fffffa801336ab30 r10=0000000000000000 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc nt!KeAcquireInStackQueuedSpinLock+0x5f: fffff800`032952ff 488717 xchg rdx,qword ptr [rdi] ds:9800:00000000`00000000=???????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8000328b569 to fffff8000328bfc0 STACK_TEXT: fffff880`118de5b8 fffff800`0328b569 : 00000000`0000000a 00000000`00000080 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`118de5c0 fffff800`0328a1e0 : fffffa80`1394c280 fffff800`032a085c fffffa80`1146bc10 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff880`118de700 fffff800`032952ff : 00000000`00000001 00000000`00000001 00000000`00000088 fffff880`118deca0 : nt!KiPageFault+0x260 fffff880`118de890 fffff800`0334034e : fffff880`118deca0 00000000`00000000 00000000`00000000 fffff800`0327a89c : nt!KeAcquireInStackQueuedSpinLock+0x5f fffff880`118de8e0 fffff800`032f79ea : 00000000`00000028 00000000`00000006 00000000`00bf4000 fffffa80`1336ab30 : nt!MiReleaseConfirmedPageFileSpace+0x5e fffff880`118de960 fffff800`0327881f : fffffa80`00000000 00000000`00c7ffff 00000000`00000000 fffff800`035a2ee6 : nt! ?? ::FNODOBFM::`string'+0x34ee6 fffff880`118deb20 fffff800`0328b253 : ffffffff`ffffffff 00000000`001bee40 00000000`001bee30 00000000`00008000 : nt!NtFreeVirtualMemory+0x61f fffff880`118dec20 00000000`76f314fa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`001becc8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f314fa STACK_COMMAND: kb FOLLOWUP_IP: nt!KeAcquireInStackQueuedSpinLock+5f fffff800`032952ff 488717 xchg rdx,qword ptr [rdi] SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!KeAcquireInStackQueuedSpinLock+5f FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 503f82be FAILURE_BUCKET_ID: X64_0xA_nt!KeAcquireInStackQueuedSpinLock+5f BUCKET_ID: X64_0xA_nt!KeAcquireInStackQueuedSpinLock+5f Followup: MachineOwner ---------
Ron
- Edited by Ron Rosenfeld Friday, February 15, 2013 2:43 AM
-
Saturday, February 16, 2013 3:29 AMModerator
Ron
I have a gut feeling, given the type of crash, I would remove PGP and Avast. AT LEAST TO TEST. If you by chance have an SSD I would update the firmware.
MS-MVP 2010, 2011, 2012 Team ZigZag
- Edited by ZigZag3143xMVP, Moderator Saturday, February 16, 2013 5:21 AM
-
Saturday, February 16, 2013 5:19 AM
Hello Ron,
Avast can be a contributing cause of BSOD'S .Please remove and replace with Microsoft Security Essentials AT LEAST TO TEST
http://files.avast.com/files/eng/aswclear5.exe
Dyami & Wanikiya -Team-ZigZag.
-
Saturday, February 16, 2013 12:16 PM
Thank you for your suggestions. Given that this is the first BSOD on this system with no clear cause (one other was clearly related to a particular driver), and that Avast and PGP have been running on it since its birth, how would I know if the test is successful?
I do have an SSD, and there is newer firmware available. So I will plan to update it in the near future (the first update is not a simple task as it requires moving the SSD to a different port, and reconfiguring my BIOS, so I need to have some "quiet time").
Ron
-
Saturday, February 16, 2013 12:18 PMHow do I tell if the test is successful, given that this is the first BSOD of this type since birth about two years ago?
Ron
-
Sunday, February 17, 2013 2:48 AMModerator
Ron
Since the Avast and PGP are easier than the firmware I would remove them first. If you dont have future problems you can wait on the firmware. It is your call, if the BSOD dont happen frequently and dont disrupt you too much I would just live with them.
MS-MVP 2010, 2011, 2012 Team ZigZag
- Marked As Answer by Ron Rosenfeld Sunday, February 17, 2013 12:02 PM
-
Sunday, February 17, 2013 12:02 PMI'll see if the BSOD's occur any more frequently. I will upgrade the SSD firmware eventually, anyway, when a I get a round2it. But I am loathe to remove useful programs without direct evidence for their involvement for an event that has occurred only once in two years.
Ron
.png)
