none
Getting several BSOD's on a new system, not sure why!

    Question

  • Hi,

    So, I posted a thread on Tom's Hardware yesterday explaining an issue regarding multiple BSOD's on my brand new system.  I wouldn't have wanted to explain all that here because explaining all that stuff in this thread would be too verbose and there's some potentially useful information on that thread so yeah.  I'm linking it here anyway in case someone wants to read it but it doesn't contain actual dump files, so I don't know how useful it will be:

    http://www.tomshardware.com/answers/id-1934341/solve-bsod-mystery-lots-random-bsod-multiple-bug-check-strings.html


    Anyway, I'm here because I'm hoping I would get a quicker answer, and I've seen people here that have experience with reading memory dump files using windbg.

    Having said that, I have a few things not mentioned in the link above:

    A.) I used a system restore point on my machine.  That way, any unnecessary drivers would be taken out of the picture.

    B.) I initially installed Windows 8 on my SSD.  The reason for this was because, as a CS student, I got access to Windows 8 when it came out.  I kept it with me until I knew I would be moving onto a x64 system configuration, which I have now.  That being said, I don't really know if this might have messed up any of my drivers, but I believe I double checked the drivers after updating to 8.1 specifically to make sure this kind of problem wouldn't occur, although anything is still possible.

    C.) I ran memtest+ for a little bit for a second time after I fixed my HSF problem.  No immediate errors after about 5 minutes, although yeah that is definitely not a full scale test.  I'll probably run it again tonight.  I want to really believe that this isn't a hardware issue.

    I also have additional crash info from WhoCrashed aside from the one on the TH forum:

    Crash dump directory: C:\WINDOWS\Minidump

    Crash dumps are enabled on your computer.

    On Wed 12/18/2013 9:19:43 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-15390-01.dmp
    This was probably caused by the following module: ntoskrnl.exe (nt+0x14DCA0)
    Bugcheck code: 0x139 (0x3, 0xFFFFD000201F2810, 0xFFFFD000201F2768, 0x0)
    Error: KERNEL_SECURITY_CHECK_FAILURE
    file path: C:\WINDOWS\system32\ntoskrnl.exe
    product: Microsoft® Windows® Operating System
    company: Microsoft Corporation
    description: NT Kernel & System
    Bug check description: The kernel has detected the corruption of a critical data structure.
    The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



    On Wed 12/18/2013 9:19:43 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\memory.dmp
    This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0)
    Bugcheck code: 0x139 (0x3, 0xFFFFD000201F2810, 0xFFFFD000201F2768, 0x0)
    Error: KERNEL_SECURITY_CHECK_FAILURE
    Bug check description: The kernel has detected the corruption of a critical data structure.
    The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



    On Wed 12/18/2013 3:54:05 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-4593-01.dmp
    This was probably caused by the following module: e22w8x64.sys (0xFFFFF8000316505F)
    Bugcheck code: 0xD1 (0xFFFFCF8005ECAE80, 0x2, 0x0, 0xFFFFF8000316505F)
    Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    file path: C:\WINDOWS\system32\drivers\e22w8x64.sys
    product: Killer e2200 PCI-E Gigabit Ethernet Controller
    company: Qualcomm Atheros, Inc.
    description: Killer e2200 PCI-E Gigabit Ethernet Controller
    Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
    This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
    A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: e22w8x64.sys (Killer e2200 PCI-E Gigabit Ethernet Controller, Qualcomm Atheros, Inc.).
    Google query: Qualcomm Atheros, Inc. DRIVER_IRQL_NOT_LESS_OR_EQUAL



    On Wed 12/18/2013 3:49:27 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-4984-01.dmp
    This was probably caused by the following module: e22w8x64.sys (0xFFFFF80002F8E05F)
    Bugcheck code: 0xD1 (0xFFFFCF8005D2EDD0, 0x2, 0x0, 0xFFFFF80002F8E05F)
    Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    file path: C:\WINDOWS\system32\drivers\e22w8x64.sys
    product: Killer e2200 PCI-E Gigabit Ethernet Controller
    company: Qualcomm Atheros, Inc.
    description: Killer e2200 PCI-E Gigabit Ethernet Controller
    Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
    This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
    A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: e22w8x64.sys (Killer e2200 PCI-E Gigabit Ethernet Controller, Qualcomm Atheros, Inc.).
    Google query: Qualcomm Atheros, Inc. DRIVER_IRQL_NOT_LESS_OR_EQUAL

    And here are the dump files associated with the above four as described in the WhoCrashed report above:

    Hi,

    So, I posted a thread on Tom's Hardware yesterday explaining an issue regarding multiple BSOD's on my brand new system.  I wouldn't have wanted to explain all that here because explaining all that stuff in this thread would be too verbose and there's some potentially useful information on that thread so yeah.  I'm linking it here anyway in case someone wants to read it but it doesn't contain actual dump files, so I don't know how useful it will be:

    http://www.tomshardware.com/answers/id-1934341/solve-bsod-mystery-lots-random-bsod-multiple-bug-check-strings.html

    Anyway, I'm here because I'm hoping I would get a quicker answer, and I've seen people here that have experience with reading memory dump files using windbg.

    Having said that, I have a few things not mentioned in the link above:

    A.) I used a system restore point on my machine.  That way, any unnecessary drivers would be taken out of the picture.

    B.) I initially installed Windows 8 on my SSD.  The reason for this was because, as a CS student, I got access to Windows 8 when it came out.  I kept it with me until I knew I would be moving onto a x64 system configuration, which I have now.  That being said, I don't really know if this might have messed up any of my drivers, but I believe I double checked the drivers after updating to 8.1 specifically to make sure this kind of problem wouldn't occur, although anything is still possible.

    C.) I ran memtest+ for a little bit for a second time after I fixed my HSF problem.  No immediate errors after about 5 minutes, although yeah that is definitely not a full scale test.  I'll probably run it again tonight.  I want to really believe that this isn't a hardware issue.

    I also have additional crash info from WhoCrashed aside from the one on the TH forum:

    Crash dump directory: C:\WINDOWS\Minidump

    Crash dumps are enabled on your computer.

    On Wed 12/18/2013 9:19:43 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-15390-01.dmp
    This was probably caused by the following module: ntoskrnl.exe (nt+0x14DCA0) 
    Bugcheck code: 0x139 (0x3, 0xFFFFD000201F2810, 0xFFFFD000201F2768, 0x0)
    Error: KERNEL_SECURITY_CHECK_FAILURE
    file path: C:\WINDOWS\system32\ntoskrnl.exe
    product: Microsoft® Windows® Operating System
    company: Microsoft Corporation
    description: NT Kernel & System
    Bug check description: The kernel has detected the corruption of a critical data structure.
    The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time. 



    On Wed 12/18/2013 9:19:43 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\memory.dmp
    This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0) 
    Bugcheck code: 0x139 (0x3, 0xFFFFD000201F2810, 0xFFFFD000201F2768, 0x0)
    Error: KERNEL_SECURITY_CHECK_FAILURE
    Bug check description: The kernel has detected the corruption of a critical data structure.
    The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time. 



    On Wed 12/18/2013 3:54:05 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-4593-01.dmp
    This was probably caused by the following module: e22w8x64.sys (0xFFFFF8000316505F)
    Bugcheck code: 0xD1 (0xFFFFCF8005ECAE80, 0x2, 0x0, 0xFFFFF8000316505F)
    Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    file path: C:\WINDOWS\system32\drivers\e22w8x64.sys
    product: Killer e2200 PCI-E Gigabit Ethernet Controller
    company: Qualcomm Atheros, Inc.
    description: Killer e2200 PCI-E Gigabit Ethernet Controller
    Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
    This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. 
    A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: e22w8x64.sys (Killer e2200 PCI-E Gigabit Ethernet Controller, Qualcomm Atheros, Inc.). 
    Google query: Qualcomm Atheros, Inc. DRIVER_IRQL_NOT_LESS_OR_EQUAL



    On Wed 12/18/2013 3:49:27 PM GMT your computer crashed
    crash dump file: C:\WINDOWS\Minidump\121813-4984-01.dmp
    This was probably caused by the following module: e22w8x64.sys (0xFFFFF80002F8E05F)
    Bugcheck code: 0xD1 (0xFFFFCF8005D2EDD0, 0x2, 0x0, 0xFFFFF80002F8E05F)
    Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
    file path: C:\WINDOWS\system32\drivers\e22w8x64.sys
    product: Killer e2200 PCI-E Gigabit Ethernet Controller
    company: Qualcomm Atheros, Inc.
    description: Killer e2200 PCI-E Gigabit Ethernet Controller
    Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
    This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. 
    A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: e22w8x64.sys (Killer e2200 PCI-E Gigabit Ethernet Controller, Qualcomm Atheros, Inc.). 
    Google query: Qualcomm Atheros, Inc. DRIVER_IRQL_NOT_LESS_OR_EQUAL

    And here are the dump files associated with the above four as described in the WhoCrashed report above:

    http://sdrv.ms/18zDmGc


    I have the other dumps, but for some reason I couldn't see them after my system restore in BlueScreenView (and I tried using windbg to open them, but I couldn't get it to work).  But yeah, if anyone could possibly look at these and figure out what could be the problem, or perhaps lead me in the right direction, then that would be really great!! :-)

    • Edited by dazinger92 Tuesday, December 24, 2013 12:53 AM
    Thursday, December 19, 2013 12:30 AM

Answers

  • Hi,

    The dump file shows that this issue is related with steam.exe, do you have some software related with steam, a
    game? I suggest you uninstall it if possible for a test.<o:p></o:p>

    Regards,<o:p></o:p>

    Yolanda<o:p></o:p>



    Yolanda
    TechNet Community Support

    Tuesday, December 24, 2013 11:21 AM
  • There are hardware stress tests that can be run

    Try this free video stress test:  http://www.ozone3d.net/benchmarks/fur/
    FurMark Setup:

    - If you have more than one GPU, select Multi-GPU during setup
    - In the Run mode box, select "Stability Test" and "Log GPU Temperature"
    Click "Go" to start the test
    - Run the test until the GPU temperature maxes out - or until you start having problems (whichever comes first)
    - Click "Quit" to exit

    *

    Try this free stress test:  http://www.mersenne.org/freesoft/

    Prime95 Setup;
    - extract the contents of the zip file to a location of your choice
    - double click on the executable file
    - select "Just stress testing"
    - select the "Blend" test.  If you've already run MemTest overnight you may want to run the "Small FFTs" test instead.
    - "Number of torture test threads to run" should equal the number of CPU's times 2 (if you're using hyperthreading).
    The easiest way to figure this out is to go to Task Manager...Performance tab - and see the number of boxes under CPU Usage History
    Then run the test for 6 to 24 hours - or until you get errors [b](whichever comes first)
    The Test selection box and the stress.txt file describes what components that the program stresses.

    *

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


    Wanikiya and Dyami--Team Zigzag


    Tuesday, December 24, 2013 6:17 PM

All replies

  • 2: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    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 kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: ffffcf8005ecae80, memory referenced
    Arg2: 0000000000000002, IRQL
    Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
    Arg4: fffff8000316505f, address which referenced memory
    
    Debugging Details:
    ------------------
    
    
    OVERLAPPED_MODULE: Address regions for 'peauth' and 'igdkmd64.sys' overlap
    
    READ_ADDRESS: fffff80302eb4340: Unable to get special pool info
    fffff80302eb4340: Unable to get special pool info
    GetUlongFromAddress: unable to read from fffff80302f4f208
     ffffcf8005ecae80 
    
    CURRENT_IRQL:  2
    
    FAULTING_IP: 
    e22w8x64+705f
    fffff800`0316505f 4d8b36          mov     r14,qword ptr [r14]
    
    DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP
    
    BUGCHECK_STR:  AV
    
    PROCESS_NAME:  svchost.exe
    
    TRAP_FRAME:  ffffd00022919d70 -- (.trap 0xffffd00022919d70)
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000282
    rdx=ffffe00003ca0770 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff8000316505f rsp=ffffd00022919f00 rbp=ffffcf8000796fb0
     r8=0000000000000000  r9=fffff80000d28c54 r10=fffff8030328f5c0
    r11=ffffe00000d6ae20 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei pl zr na po nc
    e22w8x64+0x705f:
    fffff800`0316505f 4d8b36          mov     r14,qword ptr [r14] ds:00000000`00000000=????????????????
    Resetting default scope
    
    LAST_CONTROL_TRANSFER:  from fffff80302d5b7e9 to fffff80302d4fca0
    
    STACK_TEXT:  
    ffffd000`22919c28 fffff803`02d5b7e9 : 00000000`0000000a ffffcf80`05ecae80 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
    ffffd000`22919c30 fffff803`02d5a03a : 00000000`00000000 00000000`00000000 00000000`00000300 ffffd000`22919d70 : nt!KiBugCheckDispatch+0x69
    ffffd000`22919d70 fffff800`0316505f : ffffe000`02f6ea38 00000000`00000000 ffffe000`03531110 ffffcf80`00796fb0 : nt!KiPageFault+0x23a
    ffffd000`22919f00 ffffe000`02f6ea38 : 00000000`00000000 ffffe000`03531110 ffffcf80`00796fb0 ffffe000`036a4440 : e22w8x64+0x705f
    ffffd000`22919f08 00000000`00000000 : ffffe000`03531110 ffffcf80`00796fb0 ffffe000`036a4440 fffff800`000001c0 : 0xffffe000`02f6ea38
    
    
    STACK_COMMAND:  kb
    
    FOLLOWUP_IP: 
    e22w8x64+705f
    fffff800`0316505f 4d8b36          mov     r14,qword ptr [r14]
    
    SYMBOL_STACK_INDEX:  3
    
    SYMBOL_NAME:  e22w8x64+705f
    
    FOLLOWUP_NAME:  MachineOwner
    
    MODULE_NAME: e22w8x64
    
    IMAGE_NAME:  e22w8x64.sys
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  514a28f1
    
    FAILURE_BUCKET_ID:  AV_VRF_e22w8x64+705f
    
    BUCKET_ID:  AV_VRF_e22w8x64+705f
    
    Followup: MachineOwner

    It’s a BSOD with a "DRIVER_IRQL_NOT_LESS_OR_EQUAL (e22w8x64.sys)" error, this is mostly caused by a compatibility issue with the Qualcomm Atheros Killer Service just as you said in your post, did you enable the Qualcomm Atheros Killer Service in your system, as a workaround, please follow instructions from the below link to disable the service.

    TechFAQ

    http://service.msicomputer.com/msi_user/TechFAQdetail.aspx?formid=3054

    NOTE This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites.

    Regards,

    Yolanda



    Yolanda
    TechNet Community Support

    Thursday, December 19, 2013 10:16 AM
  • Hi,

    Thanks for the response!

    So, I did what was shown in the TechFAQ link, but unfortunately I got another BSOD.

    The error code was the same as the last one listed in my OP (KERNEL_SECURITY_CHECK_FAILURE)

    http://msdn.microsoft.com/en-us/library/windows/hardware/jj569891(v=vs.85).aspx

    It's the same ambiguous blue screen crash (probably due to e22w8x64.sys) since when I was actually able to get verifier to work, it was because I made it not look at e22w8x64.sys.  Otherwise, as soon as Verifier loaded (or the Windows 8 startup screen pops up) the computer BSOD's with DRIVER_IRQL_NOT_LESS_OR_EQUAL.

    So yeah.  Do you have any other suggestions as to how I could solve this problem?  Do you think that I could still get my internet working without e22w8x64.sys, and using some other driver instead?  I know that my driver is up to date as I checked this morning, so that is definitely not the problem.  I do not want a buggy driver running on my new system.  What could I possibly do to resolve this issue permanently?

    Friday, December 20, 2013 3:27 PM
  • Okay, so I have an important update for this thread.

    Firstly, I figured out why I got the KERNEL_SECURITY_CHECK_FAILURE BSOD as mentioned in my above post.  It was because I uninstalled the ethernet adapter from the device manager, and not from the uninstall program.  So, there were actually still drivers sitting around.

    But, unfortunately, I ended up running into some more problems.  After posting on Friday I decided to uninstall the ethernet driver completely from my system and go without internet for a few days to see how stable my machine would be.

    I got several different debug codes and I'm going to provide them here.  Beware, there are a lot of them!  I don't know what good it will do, with the different bug check strings and what not:

    http://sdrv.ms/1d2rMmi

    I turned off Driver Verifier during this time so I don't know what is the culprit; I ran memtest+ last night for 10 hours (went through 5 + 1/3 passes) with zero errors.  I purchased this NIC on Newegg:

    http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033

    to replace the killer e2200 onboard chipset.  I figured it would give me a stable computer, and so I tested without having the ethernet driver installed, and with Driver Verifier off to see if I fixed the issue.  But, apparently not.

    Any ideas?  What do you find from these dump files?  Please let me know!!

    EDIT: Ran WhoCrashed.  Here's what I got (in a nutshell):

    19 crash dumps have been found and analyzed. Only 10 are included in this report. 2 third party drivers have been identified to be causing system crashes on your computer. It is strongly suggested that you check for updates for these drivers on their company websites. Click on the links below to search with Google for updates for these drivers:

    e22w8x64.sys (Killer e2200 PCI-E Gigabit Ethernet Controller, Qualcomm Atheros, Inc.)
    atikmdag.sys (ATI Radeon Kernel Mode Driver, Advanced Micro Devices, Inc.)

    This is the huge giveaway:

    On Mon 12/23/2013 3:49:06 AM GMT your computer crashed
    crash dump file: C:\WINDOWS\memory.dmp
    This was probably caused by the following module: atikmdag.sys (atikmdag+0x26C3B)
    Bugcheck code: 0x119 (0x7000000, 0xFFFFE00001E0F000, 0xFFFFE0000192D760, 0xFFFFE000019084B0)
    Error: VIDEO_SCHEDULER_INTERNAL_ERROR
    file path: C:\WINDOWS\system32\drivers\atikmdag.sys
    product: ATI Radeon Family
    company: Advanced Micro Devices, Inc.
    description: ATI Radeon Kernel Mode Driver
    Bug check description: This indicates that the video scheduler has detected a fatal violation.
    A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: atikmdag.sys (ATI Radeon Kernel Mode Driver, Advanced Micro Devices, Inc.).
    Google query: Advanced Micro Devices, Inc. VIDEO_SCHEDULER_INTERNAL_ERROR

    On my end, I'll use driver verifier to confirm that this is indeed the other broken driver.  If I can confirm it, then I really wonder how I'm going to fix this one.  Though, if someone with windbg.exe knowledge could look through these dump files just to confirm this, then that would be great!  I really want to make sure I completely eradicate this problem once and for all. :-)

    • Edited by dazinger92 Monday, December 23, 2013 4:57 AM added the skydrive link
    Monday, December 23, 2013 4:40 AM
  • Dazinger

    6 different error codes and it appears non of these were driver verified.  Either it was not enabled or the driver causing this is not in the list.  You can check to make sure it is enabled by typing verifier /query and you should get a list of drivers.  If you don't it isn't enabled.

    To narrow this to a single driver we will need you to run verifier.

    These crashes were related to memory management (probably caused by a driver).  I would run verifier first.


    If you are overclocking (pushing the components beyond their design) you should revert to default at least until the crashing is solved. If you dont know what it is you probably are not overclocking.

    1-Memtest. (You can read more about running memtest here)
    2-Driver verifier (for complete directions see our wiki here)
    Co-Authored by  JMH3143


    Wanikiya and Dyami--Team Zigzag

    Monday, December 23, 2013 5:05 AM
  • Alright,

    I'll probably be doing that between now and halfway through the week.  I'll let you know what I come up with.  With my results from memtest+ I am sure there's nothing wrong there [although, of course, I can always run it again just to make sure], so I'll uninstall the ethernet driver(s) and put Verifier on and see if I can confirm what WhoCrashed said about atikmdag.sys being the secondary culprit.

    Also, it seems that you cannot really determine much without Driver Verifier, even with the dump files?

    Monday, December 23, 2013 5:13 AM
  • Dazinger

    For starters WhoCrashed is wrong as often as it is right. It simply cant examine the data and most often blames and OS file.  I would not use it BlueScreenView, or similar apps.

    As I said I would run verifier FIRST because I believe that one driver is underlying this whole issue and the only easy way one can be sure is to run verifier.

    There is lots that can be told using WinDbg if it is physically attached to the machine

    When (or if) you run this is up to you of course its your machine that is crashing.


    Wanikiya and Dyami--Team Zigzag

    Monday, December 23, 2013 7:01 AM
  • Okay.

    Well, I ran Verifier once and got a BSOD.

    Not sure what this points to (if anything).  I did actually look at WhoCrashed with it and it didn't say much.  I do use BlueScreenView for stuff ever since I had issues with my NVidia 9500 GT about four years ago, but it's a bit outdated now and any newer bug check strings aren't even displayed on it.  I just use it for simply copying and pasting the bug check code.

    Memory.dmp will take a bit to upload.  I will update the thread when it is ready.  Hopefully this will yield some useful information.  Also remember that I was doing this while my ethernet device was not installed on my machine in order to eliminate the e22w8x64 problem which was already detected earlier (still waiting on the NIC).  For this error I have no idea what caused it (I don't even really think it was atikmdag.sys...)

    • Edited by dazinger92 Tuesday, December 24, 2013 12:53 AM
    Monday, December 23, 2013 4:59 PM
  • If you are getting a full memory DMP your cpanel settings can be adjusted using the below to create small (or kernel) dumps

    Let us know when the DMP is up

    To ensure minidumps are enabled:

    * Go to Start, in the Search Box type: sysdm.cpl, press Enter.
    * Under the Advanced tab, click on the Startup and Recovery Settings... button.
    * Ensure that Automatically restart is unchecked.
    * Under the Write Debugging Information header select Small memory dump (256 kB) in the dropdown box (the 256kb varies).
    * Ensure that the Small Dump Directory is listed as %systemroot%\Minidump.
    * OK your way out.
    * Reboot if changes have been made.

    Wanikiya and Dyami--Team Zigzag

    Monday, December 23, 2013 5:08 PM
  • Alright,

    Well it took an hour and 10 minutes to upload the full memory dump file (594MB), because when it was nearly done at around 12:20, my computer BSOD'ed (IRQL_NOT_LESS_OR_EQUAL) probably because of the unstable ethernet driver.  Does adding the large memory dump file in addition to the small dump file help much in terms of debugging (in practical terms)?

    In any case, here they both are:

    http://sdrv.ms/1c2SfLP

    • Edited by dazinger92 Tuesday, December 24, 2013 12:59 AM
    Monday, December 23, 2013 6:06 PM
  • Danzinger

    Having a full dump doesnt offer much more than the kernel and sometimes it gives even less.  The best way to use debugger is to physically connect it to the machine and watch (or force) it while it crashes.  In that case we can usually come up with an answer quickly.

    This way we are hobbled (hence verifier). 

    In your case both were 0x3D error codes.  In the minidump verifier was enabled but the driver that crashed the system was not "caught" (not in the set being examined).  You can change the set to "all" drivers to get a better chance of the driver being included but it will slow the computer down.

    I re-read Toms thread and you are doing things that will obfuscate the results of any tests.  You need to revert everything back to default and leave it there until you find what is causing this.  Adjusting the RAM voltage only adds another variable into the mix.


    Wanikiya and Dyami--Team Zigzag

    Monday, December 23, 2013 8:44 PM
  • OK.

    And, yeah.  What I did on Tom's Hardware was just little things that could have possibly "fixed" the issue (as a hunch.)  Setting the voltage to 1.55v didn't fix the problem, so I reverted back to 1.50v afterward.

    But of course that was one week ago.  Since I really do not / will not need the Killer e2200 drivers after this week I'm going to keep testing with that uninstalled (and maybe one day there will be a version that will fix all their issues! :-]) and keep everything else unchanged.  I'll see what I come up with.

    Monday, December 23, 2013 9:06 PM
  • I have a quick update:

    A.) I put on Verifier with it selecting all drivers.  However, I got a  BSOD right away (IRQL_NOT_LESS_OR_EQUAL) and there was no dump file.  I fixed it by removing Kernel synchronization delay fuzzing, but I really don't understand why.  The description that Windows gives it is "This option randomizes thread schedules to help detect concurrency bugs in drivers." Maybe that test type just takes too much system resources?

    B.) I tried doing a kd> !analyze -v in my windbg.exe program, but I got this:

    0: kd> !analyze -v

    [...] Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** *************************************************************************

    Is there any way to fix this?

    EDIT: after reading the instructions on http://support.microsoft.com/kb/311503/en-us, the problem was fixed.

    • Edited by dazinger92 Tuesday, December 24, 2013 12:52 AM
    Monday, December 23, 2013 10:31 PM
  • Okay.  Got a dump file that might be of use here.

    Will upload and edit post when it's ready.

    EDIT: http://sdrv.ms/1csYSNN

    I don't know if it will give the right information, but after I upload it I will run a bugcheck (!analyze -v) to see what it says.

    • Edited by dazinger92 Tuesday, December 24, 2013 12:52 AM
    Tuesday, December 24, 2013 12:45 AM
  • Hi,

    The dump file shows that this issue is related with steam.exe, do you have some software related with steam, a
    game? I suggest you uninstall it if possible for a test.<o:p></o:p>

    Regards,<o:p></o:p>

    Yolanda<o:p></o:p>



    Yolanda
    TechNet Community Support

    Tuesday, December 24, 2013 11:21 AM
  • Yes.

    I run Steam and play games on it.  I play nearly all of my games using Steam.  I also saw the same results yesterday when running a bugcheck on the dump file, but it doesn't make sense.  Could a program like Steam cause a double fault?

    As far as I can tell, this doesn't uncover the underlying issue.  It could, however, suggest that there is a hardware problem, right?  We had all of the installed drivers being checked with Driver Verifier.  If it didn't point to a specific driver, but instead something like steam.exe, then doesn't that mean that there is a much bigger issue here?

    I don't really know what to think right now.  I have had *10* different bug check strings/codes, and 24 BSOD's total since I purchased this motherboard, this CPU, this RAM, and SSD.  I know some earlier BSOD's may have led me to believe it was just a problem with the killer e2200 driver, but apparently not.  I'm just so stumped!



    • Edited by dazinger92 Tuesday, December 24, 2013 6:18 PM
    Tuesday, December 24, 2013 6:14 PM
  • There are hardware stress tests that can be run

    Try this free video stress test:  http://www.ozone3d.net/benchmarks/fur/
    FurMark Setup:

    - If you have more than one GPU, select Multi-GPU during setup
    - In the Run mode box, select "Stability Test" and "Log GPU Temperature"
    Click "Go" to start the test
    - Run the test until the GPU temperature maxes out - or until you start having problems (whichever comes first)
    - Click "Quit" to exit

    *

    Try this free stress test:  http://www.mersenne.org/freesoft/

    Prime95 Setup;
    - extract the contents of the zip file to a location of your choice
    - double click on the executable file
    - select "Just stress testing"
    - select the "Blend" test.  If you've already run MemTest overnight you may want to run the "Small FFTs" test instead.
    - "Number of torture test threads to run" should equal the number of CPU's times 2 (if you're using hyperthreading).
    The easiest way to figure this out is to go to Task Manager...Performance tab - and see the number of boxes under CPU Usage History
    Then run the test for 6 to 24 hours - or until you get errors [b](whichever comes first)
    The Test selection box and the stress.txt file describes what components that the program stresses.

    *

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


    Wanikiya and Dyami--Team Zigzag


    Tuesday, December 24, 2013 6:17 PM