none
Frequent BSOD

    Question

  • I am having big problems with BSODs. I have uninstalled and re installed video driver, updated bios etc. Ive ran memtest over night and havent found any problems with my ram. I have ran chkdsk as well. im on my 3rd install of windows and im still having problems. I cant figure out if it is hardware or software problems. I only have problems when the computer is idle, i havent had any problems while playing video games. Occasionally it will happen when XBMC is on, But most of the time it is just when its sitting there. 

    Here is my log file form event viewer. https://drive.google.com/folderview?id=0B5rkDibp_weJWDJIbkd4aHRlUUk&usp=sharing

    I have just built this pc i can provide full specs if need be, any help would be much appreciated. 

    Monday, April 14, 2014 6:22 AM

Answers

  • Thanks very much!

    The attached DMP file is of the MEMORY_MANAGEMENT (1a) bug check.

    This indicates that a severe memory management error occurred.

    BugCheck 1A, {41793, fffff6800008eff8, 200, 1ff}

    - The 1st parameter of the bug check is 41793 which indicates an unknown memory management error occurred.

    3: kd> k
    Child-SP          RetAddr           Call Site
    ffffd000`25ac6648 fffff800`27383bf2 nt!KeBugCheckEx
    ffffd000`25ac6650 fffff800`2725ce82 nt! ?? ::FNODOBFM::`string'+0xea52
    ffffd000`25ac68b0 fffff800`2725b1d6 nt!MiDeleteVad+0xc02
    ffffd000`25ac69a0 fffff800`273704b3 nt!NtFreeVirtualMemory+0x846
    ffffd000`25ac6b00 00007fff`a829675a nt!KiSystemServiceCopyEnd+0x13
    00000000`0024e068 00000000`00000000 0x00007fff`a829675a

    ^^ nt!NtFreeVirtualMemory routine call, with nt! implying that we're free virtual memory from a non-trusted kernel-mode/user-mode source. If it was a trusted kernel-mode source that didn't require validation afterwards, it would be zw as opposed to nt.

    nt! ?? ::FNODOBFM::`string' - TO MY KNOWLEDGE, the debugger (WingDbg) is slightly confused about symbol names in NTDLL due to the binary being reorganized into function chunks. The functions are no longer contiguous in memory. Hot code paths are clustered together with hot code paths of other functions. “Cold” code paths are moved elsewhere. That way you save on paging I/O by maximizing the amount of relative data on each code page.

    Essentially, to my understanding, when a sequence of code is compiled, it will occupy a single contiguous chunk of memory. With this said however, the optimizer can spread the executable code all over the place, replacing the inline code with a jump to some other memory location.

    When this happens, to my knowledge, FunctionName+Offset no longer equals FunctionAddress+Offset, therefore the output of information in the debugger isn't correct. In these specific cases, the code is moved to a location (which is random, to my knowledge) and the closest symbolic name is a string in the image. When this happens, the debugger (WinDbg) uses the string as a best guess for the return address on the stack.

    -----------------

    Other than what's in the stack regarding virtual memory routine calls, etc, we have little information in this dump.

    PROCESS_NAME:  XBMC.exe

    ^^ FWIW, I have seen XBMC cause many crashes. Be sure you're at the latest version of XMBC, and if you already are, please remove it for troubleshooting purposes as it may be causing the the issues we're seeing here.

    Other than that, your system (modules wise) is clean as a whistle. Nothing standing out/red flags.

    Regards,

    Patrick
    • Marked as answer by aflatt22 Monday, April 14, 2014 3:37 PM
    Monday, April 14, 2014 2:21 PM

All replies

  • Hi,

    In order to assist you, we will need the .DMP files to analyze what exactly occurred at the time of the crash, etc.

    If you don't know where .DMP files are located, here's how to get to them:

    1. Navigate to the %systemroot%\Minidump folder.

    2. Copy any and all DMP files in the Minidump folder to your Desktop and then zip up these files.

    3. Upload the zip containing the .DMP files to Onedrive or a hosting site of your choice and paste in your reply. Prefered sites: Onedrive, Mediafire, Dropbox, etc. Nothing with wait-timers.

    4 (optional): The type of .DMP files located in the Minidump folder are known as Small Memory Dumps. In %systemroot% there will be what is known as a Kernel-Dump (if your system is set to generate). It is labeled MEMORY.DMP. The difference between Small Memory Dumps and Kernel-Dumps in the simplest definition is a Kernel-Dump contains much more information at the time of the crash, therefore allowing further debugging of your issue. If your upload speed permits it, and you aren't going against any strict bandwidth and/or usage caps, etc, the Kernel-Dump is the best choice. Do note that Kernel-Dumps are much larger in size due to containing much more info, which is why I mentioned upload speed, etc.

    If you are going to use Onedrive but don't know how to upload to it, please visit the following:

    Upload photos and files to Onedrive.

    Please note that any "cleaner" programs such as TuneUp Utilities, CCleaner, etc, by default will delete .DMP files upon use.

    If your computer is not generating .DMP files, please do the following:

    1. Start > type %systemroot% which should show the Windows folder, click on it. Once inside that folder, ensure there is a Minidump folder created. If not, CTRL-SHIFT-N to make a New Folder and name it Minidump.

    2. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Performance > Settings > Advanced > Ensure there's a check-mark for 'Automatically manage paging file size for all drives'.

    3. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to 'Write an event to the system log'.

    Ensure Small Memory Dump is selected and ensure the path is %systemroot%\Minidump.

    4. Double check that the WERS is ENABLED:

    Start > Search > type services.msc > Under the name tab, find Windows Error Reporting Service > If the status of the service is not Started then right click it and select Start. Also ensure that under Startup Type it is set to Automatic rather than Manual. You can do this by right clicking it, selecting properties, and under General selecting startup type to 'Automatic', and then click Apply.

    If you cannot get into normal mode to do any of this, please do this via Safe Mode.

    Regards,

    Patrick
    Monday, April 14, 2014 6:30 AM
  • Thanks for the reply!

    Here is a link for the compressed mini dump folder 

    https://drive.google.com/file/d/0B5rkDibp_weJRmV4ZmFJbDl0RHc/edit?usp=sharing

    Monday, April 14, 2014 6:46 AM
  • Here is the MEMORY file as well. 

    https://drive.google.com/file/d/0B5rkDibp_weJWEJPWG54TGFIR1U/edit?usp=sharing

    Monday, April 14, 2014 6:52 AM
  • Thanks very much!

    The attached DMP file is of the MEMORY_MANAGEMENT (1a) bug check.

    This indicates that a severe memory management error occurred.

    BugCheck 1A, {41793, fffff6800008eff8, 200, 1ff}

    - The 1st parameter of the bug check is 41793 which indicates an unknown memory management error occurred.

    3: kd> k
    Child-SP          RetAddr           Call Site
    ffffd000`25ac6648 fffff800`27383bf2 nt!KeBugCheckEx
    ffffd000`25ac6650 fffff800`2725ce82 nt! ?? ::FNODOBFM::`string'+0xea52
    ffffd000`25ac68b0 fffff800`2725b1d6 nt!MiDeleteVad+0xc02
    ffffd000`25ac69a0 fffff800`273704b3 nt!NtFreeVirtualMemory+0x846
    ffffd000`25ac6b00 00007fff`a829675a nt!KiSystemServiceCopyEnd+0x13
    00000000`0024e068 00000000`00000000 0x00007fff`a829675a

    ^^ nt!NtFreeVirtualMemory routine call, with nt! implying that we're free virtual memory from a non-trusted kernel-mode/user-mode source. If it was a trusted kernel-mode source that didn't require validation afterwards, it would be zw as opposed to nt.

    nt! ?? ::FNODOBFM::`string' - TO MY KNOWLEDGE, the debugger (WingDbg) is slightly confused about symbol names in NTDLL due to the binary being reorganized into function chunks. The functions are no longer contiguous in memory. Hot code paths are clustered together with hot code paths of other functions. “Cold” code paths are moved elsewhere. That way you save on paging I/O by maximizing the amount of relative data on each code page.

    Essentially, to my understanding, when a sequence of code is compiled, it will occupy a single contiguous chunk of memory. With this said however, the optimizer can spread the executable code all over the place, replacing the inline code with a jump to some other memory location.

    When this happens, to my knowledge, FunctionName+Offset no longer equals FunctionAddress+Offset, therefore the output of information in the debugger isn't correct. In these specific cases, the code is moved to a location (which is random, to my knowledge) and the closest symbolic name is a string in the image. When this happens, the debugger (WinDbg) uses the string as a best guess for the return address on the stack.

    -----------------

    Other than what's in the stack regarding virtual memory routine calls, etc, we have little information in this dump.

    PROCESS_NAME:  XBMC.exe

    ^^ FWIW, I have seen XBMC cause many crashes. Be sure you're at the latest version of XMBC, and if you already are, please remove it for troubleshooting purposes as it may be causing the the issues we're seeing here.

    Other than that, your system (modules wise) is clean as a whistle. Nothing standing out/red flags.

    Regards,

    Patrick
    • Marked as answer by aflatt22 Monday, April 14, 2014 3:37 PM
    Monday, April 14, 2014 2:21 PM
  • Patrick, 

    Thank you for the response. 

    I reinstalled xbmc 12 and at the last point of the install the screen started to flash, it got through the install and then when i ran the program, a blue screen happened within 5 minutes. I uninstalled and re intstalled xbmc 13.0 beta3 and it seems to be running just fine. 

    Thank you for helping me point out xbmc as a problem, to bad because xbmc is the best home theater media software that i have found. 

    Thank you again!

    Alex

    Monday, April 14, 2014 3:36 PM
  • Very glad to hear the beta was given positive results, Alex. Thanks for the update, and my pleasure!

    Regards,

    Patrick
    Monday, April 14, 2014 4:03 PM
  • Hi Patrick, 

    i seem to still be having BSOD problems, I left my computer on while i was at work and i came home to it back at the log in screen. I checked blue screen view and there was another error. It had another BSOD wtihin 10 minutes of the second restart. Do you have any other suggestions?

    Thanks, 

    Alex

    Tuesday, April 15, 2014 5:30 AM
  • Uninstall the software entirely and use the system for a few days without it. If no crashes, you're unfortunately just going to have to find an alternative software.

    Regards,

    Patrick

    Tuesday, April 15, 2014 5:49 AM