Hi, this is driving me nuts, I'm fairly certain that it's a hardware issue which is why I'm posting here instead of the windows section. Anyway, so far I've replaced my HDD with a SSD and I've even tried unplugging all my HDDs but I still get bsods. Second thing I did was to throw my bullcrap OCZ ram and I replaced them with 8GBs of Mushkin, still no solution. Bsods are random and happen maybe once a day or more often, mostly it won't even create a crash dump. http://www65.zippyshare.com/v/71160194/file.html http://www65.zippyshare.com/v/32045784/file.html http://www65.zippyshare.com/v/20009657/file.html http://www65.zippyshare.com/v/17940961/file.html http://www65.zippyshare.com/v/61756611/file.html Or zip with all: http://www25.zippyshare.com/v/47121680/file.html Here are a few crash dumps, I hope some of you could help me figure out what is most likely causing the issue. Rig is in my profile.
This programs shows very little information compared to windbg. I can't make any reference to the results I get, that's what I need help with. Or of course, I can google and find 100 people with the same crash process name, but all have other problems ultimately. This is why I'm trying to find someone to take a look at my crash dumps to find anything that might hint something specific being broken.
020114-10359-01.dmp - 01.02.2014 18:56:15 - MEMORY_MANAGEMENT (0x1a) - Parameter1 = 0x00005003 - ntoskrnl.exe+14dca0 Bug Check 0x1A: MEMORY_MANAGEMENT - The MEMORY_MANAGEMENT bug check has a value of 0x0000001A. This indicates that a severe memory management error occurred. Parameter 1 = 0x5003 - The working set free list is corrupt. This is probably a hardware error. 020314-8250-01.dmp - 03.02.2014 3:53:04 - UNEXPECTED_KERNEL_MODE_TRAP (0x7f) - Parameter1 = 0x00000008 - ntoskrnl.exe+14dca0 Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP - The UNEXPECTED_KERNEL_MODE_TRAP bug check has a value of 0x0000007F. This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap. Parameter 1 = 0x00000008, or Double Fault - indicates that an exception occurs during a call to the handler for a prior exception. Typically, the two exceptions are handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault: - A kernel stack overflow. This overflow occurs when a guard page is hit, and the kernel tries to push a trap frame. Because there is no stack left, a stack overflow results, causing the double fault. If you think this overview has occurred, use !thread to determine the stack limits, and then use kb (Display Stack Backtrace) with a large parameter (for example, kb 100) to display the full stack. - A hardware problem. 041114-8890-01.dmp - 11.04.2014 16:24:46 - SYSTEM_SERVICE_EXCEPTION (0x3b) - Parameter1 = 0xc0000005 - ntoskrnl.exe+14dca0 Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION - The SYSTEM_SERVICE_EXCEPTION bug check has a value of 0x0000003B. This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code. Parameter 1 = 0xc0000005 - The exception that caused the bug check. 0xc0000005 - EXCEPTION_ACCESS_VIOLATION - The thread tried to read from or write to a virtual address for which it does not have the appropriate access. 051914-9562-01.dmp - 19.05.2014 20:20:49 - KMODE_EXCEPTION_NOT_HANDLED (0x1e) - Parameter1 = 0xc0000005 - ntoskrnl.exe+153fa0 Bug Check 0x1E: KMODE_EXCEPTION_NOT_HANDLED - The KMODE_EXCEPTION_NOT_HANDLED bug check has a value of 0x0000001E. This indicates that a kernel-mode program generated an exception which the error handler did not catch. Parameter 1 = 0xc0000005 - The exception that caused the bug check. 0xc0000005 - EXCEPTION_ACCESS_VIOLATION - The thread tried to read from or write to a virtual address for which it does not have the appropriate access. 071514-9578-01.dmp - 15.07.2014 15:46:29 - SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x1000007e) - Parameter1 = c0000005 - ntoskrnl.exe+a5c02 Bug Check 0x7E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED - The SYSTEM_THREAD_EXCEPTION_NOT_HANDLED bug check has a value of 0x0000007E. This bug check indicates that a system thread generated an exception that the error handler did not catch. Parameter 1 = 0xc0000005 - The exception that caused the bug check. 0xc0000005 - EXCEPTION_ACCESS_VIOLATION - The thread tried to read from or write to a virtual address for which it does not have the appropriate access. To me it all looks like memory related problems.
No it does not, it only highlights the problem, to understand what the actual problem is you need to be able to read the .DMP files. It is something ive been wanting to do myself for alongtime but never got around too it.
Well, info in dmp-file is for a developer of crushed module. By this info he can find a place in code and think about source of a crush. Others can use mostly a call stack, bugcheck number and its parameters.
