I installed a new motherboard and cpu however I do not believe that is what is causing it. I had an issue where I could not allow a program to be installed because windows firewall was automatically quarantining the file. I managed to fix that however since I did that my computer keeps getting bsods randomly usually after closing and reopening a program. Any help is appreciated thank you.
SOLVED Multiple bsod crashes not sure the cause included dump files
- Thread starter Slycoo
- Start date
Your minidumps appear to be driver related. The latest two are an IRQL_NOT_LESS_OR_EQUAL and a PAGE_FAULT_IN_NONPAGED_AREA and both of these indicate an attempt to access memory that is invalid - that's almost always the fault of a driver.
In your second minidump (060421-146265-01.dmp) there is an error for nvlddmkm.sys in the list of driver calls for the active thread. This is your Nvidia graphics driver...
I would suggest that you uninstall the Nvidia driver with DDU and then download and install the latest driver for your card and OS direct from the Nvidia website. Install this manually, not via GeForce Experience.
In your second minidump (060421-146265-01.dmp) there is an error for nvlddmkm.sys in the list of driver calls for the active thread. This is your Nvidia graphics driver...
I would suggest that you uninstall the Nvidia driver with DDU and then download and install the latest driver for your card and OS direct from the Nvidia website. Install this manually, not via GeForce Experience.
I did this and I am still getting blue screens I got a different message this time though in which it said "DPC_WATCHDOG_VIOLATION". thank you for the help so far though it is appreciated.
The 073121-6187-01.dmp minidump is a INTERRUPT_EXCEPTION_NOT_HANDLED which means that an exception during an interrupt service routine (ISR) was not handled. This is a vanishingly rare stop code and it immediately makes me suspect hardware.
The process in control was the System process running the Idle thread (which is run when there is no work to do). The stack trace shows the CPU entering the C1 (Halt) power state (which is the processor sleep state) followed by an interrupt. This interrupt however only contains the trap frame address indicating a memory reference of 0x00, which is of course invalid.
The 073121-6375-01.dmp minidump is a KMODE_EXCEPTION_NOT_HANDLED which means that an unhandled exception occurred whilst running in kernel mode.
The process in control is again the System process running the idle thread. The stack trace is slightly different here but again we see the CPU go idle and the power management transition to a lower power state begin, then we get the bug check.
The 073121-6468-01.dmp mindump is a PAGE_FAULT_IN_NONPAGED_AREA which means that a reference to a memory location in a non-pageable pool was invalid - either because the page was paged out (which can't happen) or because the memory is uninitialised or the reference pointer is invalid.
The stack trace is slightly different again but once more we see the CPU entering the idle transition, then a memset call to write a block of memory and then we get the bug check.
I did not see the DPC_WATCHDOG_VIOLATION stop code that you mention so there's probably also a kernel dump in the file C:\Windows\Memory.dmp. Please upload that to the cloud somewhere (it's almost certainly too big for here) and post a link to that here please.
You've made some pretty major hardware changes there - did you reinstall Windows again afterwards? I would have done so. Windows optimises itself for the hardware on which it's being installed, so if you changed the motherboard and CPU and run the old version of Windows it's not optimised for that new hardware. The first thing I would be doing is a fully clean reinstall of Windows from bootable media. (A Windows Reset in this case would be pointless).
From a hardware point of view the common denominators across all three minidumps are the CPU and RAM. All three BSODs happened as the CPU was transitioning into or out of the idle state, so power management might be an issue - check the CPU power management settings in the BIOS. Of course WIndows is likely using invalid power management information because if you didn't reinstall it still thinks it's running on the old CPU.
All three minidumps also reference invalid memory so it's well worth downloading Memtest and running a check on your RAM.
Since you've recently changed motherboard and CPU that has to be high up on the list of suspects. Is your RAM fully compatible with that new motherboard for example?
The process in control was the System process running the Idle thread (which is run when there is no work to do). The stack trace shows the CPU entering the C1 (Halt) power state (which is the processor sleep state) followed by an interrupt. This interrupt however only contains the trap frame address indicating a memory reference of 0x00, which is of course invalid.
The 073121-6375-01.dmp minidump is a KMODE_EXCEPTION_NOT_HANDLED which means that an unhandled exception occurred whilst running in kernel mode.
The process in control is again the System process running the idle thread. The stack trace is slightly different here but again we see the CPU go idle and the power management transition to a lower power state begin, then we get the bug check.
The 073121-6468-01.dmp mindump is a PAGE_FAULT_IN_NONPAGED_AREA which means that a reference to a memory location in a non-pageable pool was invalid - either because the page was paged out (which can't happen) or because the memory is uninitialised or the reference pointer is invalid.
The stack trace is slightly different again but once more we see the CPU entering the idle transition, then a memset call to write a block of memory and then we get the bug check.
I did not see the DPC_WATCHDOG_VIOLATION stop code that you mention so there's probably also a kernel dump in the file C:\Windows\Memory.dmp. Please upload that to the cloud somewhere (it's almost certainly too big for here) and post a link to that here please.
You've made some pretty major hardware changes there - did you reinstall Windows again afterwards? I would have done so. Windows optimises itself for the hardware on which it's being installed, so if you changed the motherboard and CPU and run the old version of Windows it's not optimised for that new hardware. The first thing I would be doing is a fully clean reinstall of Windows from bootable media. (A Windows Reset in this case would be pointless).
From a hardware point of view the common denominators across all three minidumps are the CPU and RAM. All three BSODs happened as the CPU was transitioning into or out of the idle state, so power management might be an issue - check the CPU power management settings in the BIOS. Of course WIndows is likely using invalid power management information because if you didn't reinstall it still thinks it's running on the old CPU.
All three minidumps also reference invalid memory so it's well worth downloading Memtest and running a check on your RAM.
Since you've recently changed motherboard and CPU that has to be high up on the list of suspects. Is your RAM fully compatible with that new motherboard for example?
Last edited:
Okay I'm glad you managed to narrow it down to a couple of denominators however, I am starting to think it may be the cpu since the memtest passed. I will attach the additional bsods I'm not sure if the watchdog violation is in one of these but there are three new ones. Here are what my bsod settings for my cpu are currently at as well as the result from the memtest. Results from requested tests to run. Also I ran my parts through pcpartpicker for a compatibility check and they all seem to be compatible with each other.
Last edited:
The 080121-5953-01.dmp is a classic IRQL_NOT_LESS_OR_EQUAL which means that an attempt was made to access memory that was paged out (or improperly allocated or the pointer was bad) whilst running at an elevated IRQL. This is almost always a third party driver or user code problem.
The trap frame shows that the problem was caused by a user mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace shows that the problem happened whilst the system was hibernating prior to a shutdown. We can see the ACPI call to transition the CPU power and the calls to the hibernation functions. The bug check seems to happen in a write operation during the creation of the hibernation file itself.
The active thread also shows a driver call error for the hiber_storahci.sys driver, this is the driver use by hibernation to write to the ACHI drive (SSD or HDD).
The 080121-5968-01.dmp is also a classic IRQL_NOT_LESS_OR_EQUAL stop code.
The trap frame here shows that the problem was caused by a kernel mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace also shows that this problem happened during hibernation at shutdown. Here the bug check occurred whilst compressing the buffer to be written to the hibernation file.
The active thread also shows a similar error for the hiber_storachi.sys driver....
The 080321-6562-01.dmp is almost identical to the others, it's a classic IRQL_NOT_LESS_OR_EQUAL stop code.
Again the trap frame shows that the problem was caused by a kernel mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace also shows that this problem happened during hibernation at shutdown. Again the bug check occurred whilst compressing the buffer to be written to the hibernation file.
The active thread also shows a similar error for the hiber_storachi.sys driver....
The common denominators here (apart from them all happening during hibernation) are RAM and the drive containing the hibernation file (hiberfil.sys). A chkdsk /f on the drive would be a good idea, but it seems to me that all three of these dumps are pointing at RAM again.
It could of course be the CPU as you think, it's always wise to suspect whatever you changed last, but RAM is a much more likely cause. Is your RAM overclocked at all? Is the CPU overclocked at all? If either or both are overclocked then I would reduce everything to stock frequencies to see whether it's stable then.
If you have more than one RAM card then run with just one card at a time for a while to see whether one of the cards is flaky. Memtest is a great tool but it can only prove that the RAM is bad, it can never prove that it's good.
The trap frame shows that the problem was caused by a user mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace shows that the problem happened whilst the system was hibernating prior to a shutdown. We can see the ACPI call to transition the CPU power and the calls to the hibernation functions. The bug check seems to happen in a write operation during the creation of the hibernation file itself.
The active thread also shows a driver call error for the hiber_storahci.sys driver, this is the driver use by hibernation to write to the ACHI drive (SSD or HDD).
Code:
fffff901`9b8b6cb8 fffff807`374e674bUnable to load image hiber_storahci.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for hiber_storahci.sys
hiber_storahci+0x674bThe 080121-5968-01.dmp is also a classic IRQL_NOT_LESS_OR_EQUAL stop code.
The trap frame here shows that the problem was caused by a kernel mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace also shows that this problem happened during hibernation at shutdown. Here the bug check occurred whilst compressing the buffer to be written to the hibernation file.
The active thread also shows a similar error for the hiber_storachi.sys driver....
Code:
fffffa83`d52f6ef8 fffff800`8fad6585Unable to load image hiber_storahci.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for hiber_storahci.sys
hiber_storahci+0x6585The 080321-6562-01.dmp is almost identical to the others, it's a classic IRQL_NOT_LESS_OR_EQUAL stop code.
Again the trap frame shows that the problem was caused by a kernel mode buffer (or by the pointer to that buffer) which was invalid (paged out or not allocated).
The stack trace also shows that this problem happened during hibernation at shutdown. Again the bug check occurred whilst compressing the buffer to be written to the hibernation file.
The active thread also shows a similar error for the hiber_storachi.sys driver....
Code:
ffffbd05`a24f6ef8 fffff804`80e36585Unable to load image hiber_storahci.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for hiber_storahci.sys
hiber_storahci+0x6585The common denominators here (apart from them all happening during hibernation) are RAM and the drive containing the hibernation file (hiberfil.sys). A chkdsk /f on the drive would be a good idea, but it seems to me that all three of these dumps are pointing at RAM again.
It could of course be the CPU as you think, it's always wise to suspect whatever you changed last, but RAM is a much more likely cause. Is your RAM overclocked at all? Is the CPU overclocked at all? If either or both are overclocked then I would reduce everything to stock frequencies to see whether it's stable then.
If you have more than one RAM card then run with just one card at a time for a while to see whether one of the cards is flaky. Memtest is a great tool but it can only prove that the RAM is bad, it can never prove that it's good.
I went ahead and purchased some new ram for my pc and I have yet to have a blue screen so I think that may have been the issue. Thank you a lot for your help through all this.
Fingers crossed for you then.
