locked
Perpetual BSOD on Windows 7 Enterprise machine RRS feed

  • Question

  • Hello guys, I have a Dell Optiplex 780 with Windows 7 Enterprise which makes me hard days trying to get it healthy. There is a BSOD once in a while, well basically weekly if not daily and I could't get rid of it.

    The Log is:

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


    Loading Dump File [\\EB-OR1019945\c$\Windows\Minidump\011515-11310-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: srv*;c:\symbols
    Executable search path is: srv*
    Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 7601.18409.amd64fre.win7sp1_gdr.140303-2144
    Machine Name:
    Kernel base = 0xfffff800`03010000 PsLoadedModuleList = 0xfffff800`03253890
    Debug session time: Thu Jan 15 09:47:28.179 2015 (UTC + 2:00)
    System Uptime: 0 days 10:53:13.263
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ...............................................
    Loading User Symbols
    Loading unloaded module list
    ......
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 1, {77a1132a, 0, ffff, fffff88009921c60}

    Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExit+245 )

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

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

    APC_INDEX_MISMATCH (1)
    This is a kernel internal error. The most common reason to see this
    bugcheck is when a filesystem or a driver has a mismatched number of
    calls to disable and re-enable APCs. The key data item is the
    Thread->CombinedApcDisable field. This consists of two separate 16-bit
    fields, the SpecialApcDisable and the KernelApcDisable. A negative value
    of either indicates that a driver has disabled special or normal APCs
    (respectively) without re-enabling them; a positive value indicates that
    a driver has enabled special or normal APCs (respectively) too many times.
    Arguments:
    Arg1: 0000000077a1132a, Address of system call function or worker routine
    Arg2: 0000000000000000, Thread->ApcStateIndex
    Arg3: 000000000000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
    Arg4: fffff88009921c60, Call type (0 - system call, 1 - worker routine)

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


    FAULTING_IP:
    +0
    00000000`77a1132a ??              ???

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

    BUGCHECK_STR:  0x1

    PROCESS_NAME:  svchost.exe

    CURRENT_IRQL:  0

    LAST_CONTROL_TRANSFER:  from fffff80003085169 to fffff80003085bc0

    STACK_TEXT:  
    fffff880`09921a28 fffff800`03085169 : 00000000`00000001 00000000`77a1132a 00000000`00000000 00000000`0000ffff : nt!KeBugCheckEx
    fffff880`09921a30 fffff800`030850a0 : 00000000`00000000 0000007f`ffffffff 00000000`00000000 00000980`00000000 : nt!KiBugCheckDispatch+0x69
    fffff880`09921b70 00000000`77a1132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x245
    00000000`00fbe318 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77a1132a


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    nt!KiSystemServiceExit+245
    fffff800`030850a0 4883ec50        sub     rsp,50h

    SYMBOL_STACK_INDEX:  2

    SYMBOL_NAME:  nt!KiSystemServiceExit+245

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  531590fb

    FAILURE_BUCKET_ID:  X64_0x1_SysCallNum_4_nt!KiSystemServiceExit+245

    BUCKET_ID:  X64_0x1_SysCallNum_4_nt!KiSystemServiceExit+245

    Followup: MachineOwner

    I made a BIOS update, Video Card, Chipset, all windows updates ar done, antivirus also. I ran a check disk and a SFC Scan, non solved the problem yet..

    Any help is much appreciated!

    Thursday, January 15, 2015 10:32 AM

Answers

  • CV

    Only one of the DMP files contained information.  It was memory related and pointed to McAfee (yours is 3+ years old)> I would remove it and use MSE in its place and if you continue to crash I would run driver verifier

    McAffe often contributes to BSOD'S

    I would remove and replace it with Microsoft Security Essentials

    http://download.mcafee.com/products/licensed/cust_support_patches/MCPR.exe

    http://www.microsoft.com/security_essentials/

    These crashes were related to memory corruption (probably caused by a driver). 

    Please run these two tests to verify your memory and find which driver is causing the problem.  Please run verifier  first

    If you are over-clocking anything reset to default before running these tests.
    In other words STOP!!! 
     

    If you do not know what this means you probably are not


    1-Driver verifier (for complete directions see our wiki here)

    2-Memtest. (You can read more about running memtest here)



    Wanikiya and Dyami--Team Zigzag



    • Edited by ZigZag3143x Thursday, January 15, 2015 1:10 PM
    • Marked as answer by ZigZag3143x Monday, January 19, 2015 11:42 AM
    Thursday, January 15, 2015 1:09 PM

All replies

  •  We do need the actual log files (called a DMP files) as they contain the only record of the sequence of events leading up to the crash, what drivers were loaded, and what was responsible.  


    Please follow our instructions for finding and uploading the files we need to help you fix your computer. They can be found here
    If you have any questions about the procedure please ask


    Wanikiya and Dyami--Team Zigzag

    Thursday, January 15, 2015 12:10 PM
  • Hello,

    There are the Minidumps and also the Memory.DMP file. http://1drv.ms/17KLcNR  If you need any other info let me know.

    Thank you!


    • Edited by Cozmin V Thursday, January 15, 2015 12:58 PM
    Thursday, January 15, 2015 12:57 PM
  • CV

    Only one of the DMP files contained information.  It was memory related and pointed to McAfee (yours is 3+ years old)> I would remove it and use MSE in its place and if you continue to crash I would run driver verifier

    McAffe often contributes to BSOD'S

    I would remove and replace it with Microsoft Security Essentials

    http://download.mcafee.com/products/licensed/cust_support_patches/MCPR.exe

    http://www.microsoft.com/security_essentials/

    These crashes were related to memory corruption (probably caused by a driver). 

    Please run these two tests to verify your memory and find which driver is causing the problem.  Please run verifier  first

    If you are over-clocking anything reset to default before running these tests.
    In other words STOP!!! 
     

    If you do not know what this means you probably are not


    1-Driver verifier (for complete directions see our wiki here)

    2-Memtest. (You can read more about running memtest here)



    Wanikiya and Dyami--Team Zigzag



    • Edited by ZigZag3143x Thursday, January 15, 2015 1:10 PM
    • Marked as answer by ZigZag3143x Monday, January 19, 2015 11:42 AM
    Thursday, January 15, 2015 1:09 PM
  • Thank you, it was a mix of different RAM modules and one was malfunctioning.
    Tuesday, January 20, 2015 9:03 AM