New
#11
Hi,
Another crash today, this time it was a BSOD and then wouldn't reboot for some time. Dump is attached.
Hi,
Another crash today, this time it was a BSOD and then wouldn't reboot for some time. Dump is attached.
There is no dump file attached to this report. Check to see if any recent ones exist in C:\Windows\Minidump.
Btw, the syslog is only showing entries up to February. You may want to delete the output from your previous generated reports, as well as go into Event Viewer (type in Start menu) and right click the System log and say "clear entries". Do same for Application log as well. Of course, then we'll have to have it repopulated again when a new issue comes up.
Hi, and thanks again for taking the time to look at this issue. I've done as you said and cleared the logs, so I guess we're just waiting for another issue to arise now. When I try and run the SF Diagnostic tool it comes up with the warning message "Sorry, No Dump Found". The directory you told me to look for in windows also doesn't exist. Is there something I need to do to activate this dump facility?
Cheers in advance,
Matt.
Type advanced system settings in Start menu, then Settings under Startup & Recovery, then check to see if Write an event to the system log is checked and that Automatically restart is unchecked. Also make sure that the dump file type is Kernel memory dump, and that the directory should be %SystemRoot%\MEMORY.DMP. This isn't referring to the minidumps in the Minidump folder. Rather, this is the larger kernel dump that we may need sometime that the minidumps are actually produced from (if my memory is correct).
Now, understand that if the kernel memory dump isn't being made for whatever reason, than most likely the minidump will not be created as well. You will want to check details at this article. In addition to what's been mentioned in the article, to make absolutely sure that the crashdump is produced, you'll want to make sure there's at least a good amount of hard drive space available on the partition where the pagefile sits, as well as where the crashdump will be made. Basically more than twice the size of the pagefile. If the space is lacking, the system will refuse to generate the crashdump. Also, understand that the kernel dump (MEMORY.DMP in Windows directory) is overwritten each time a new crashdump is successfully made, so the kernel dump is always from the latest crash (that could produce a crashdump).
If working these things out still does not produce a crashdump, then most likely there is some drive I/O failure that's occurring during the attempt to produce the crashdump during the crash, which may or may not be hardware-related. That, or the system has reached a state where it actually isn't BSODing, like freezing.
Hi again,
I've now managed to get my computer to generate dump files after a BSOD, but it seemed that it was just a system freeze that is occurring and not BSOD, so no dump file was being generated. I've just set up the force crash keyboard command in my registry and used that, which did then create a dump file. I've attached it to this message, but the dump is from over and hour after the actual freeze itself occurred, I don't know if this is a problem. The actual time of the freeze was around 10:23.
Cheers in advance,
Matt.
Wait... when you did the force BSOD using the keyboard command, did you do it when the system was frozen? As in while the system was frozen and unresponsive, it did allow you to do the force BSOD? Or did you just happen to force a BSOD at some random time and give us the crashdump from that? If the latter, that's not going to help us. We'll need a crashdump generated at the time when the symptoms occurred.
I did the keyboard induced crash an hour after the system freeze, it took me that long to get the dump file hotfix and the reg edit to allow the keyboard crash working. I'm not sure that I'll be able to force the BSOD during the actual system freeze as it's well, frozen. Keyboard does respond for 5 secs + when it starts though so I will attempt this the next time the freeze starts to happen.
So the freeze isn't a hard, instant lockup, but the system rapidly becomes increasingly unresponsive until it's completely frozen?
yes, exactly that
Sounds like it may be an interrupt or DPC storm, which is smothering the system with device activity. That would narrow things down to either your hardware or your device drivers being the cause.
Once you happen to get a BSOD successfully during the initial freeze, I recommend you provide us the kernel dump (MEMORY.DMP in Windows directory), not a minidump. You'll obviously need to zip it up and upload to a 3rd party site since it'll be too big. After this, you may also want to try out Driver Verifier.