unloaded driver stack

jcgriff2 said:
Are you saying that minidumps do not contain the unloaded driver list, but a full kernel does (for the same user; same BSOD)?

I always have users set crash dumps to full kernel, which produces a full kernel dump + a mini dump.
Click to expand...

That's one thing I didn't ask him to do, create a full kernel dump. A small memory dump just keeps producing these mini kernel dumps which aren't even in the drop down list. Patrick seems to think it could be because of a paging file on a different drive but anyway I'll ask him to change his settings to full kernel and see how we go..
Much thanks to everyone for their replies.
 
Windows is very finicky with how things need to be when it comes to the OS, the pagefile, etc. Let's create this scenario as an example:

System:

SSD #1, 250 GB - Windows 8.1.

HDD #1 (you have a total of two drives in the system with the SSD + HDD, but I'm labeling it as #1 because you only have one HDD in the system specifically), 1 TB - Storage.

If the OS drive is getting BSOD's (SSD), the pagefile must! also be on the SSD itself. Many people store the pagefile off on the storage drive to save space to get the most performance, but when this is done, we get a lot of crash generation problems, or no crashes generated at all.

EDIT - Some also disable the pagefile entirely on SSD's (the horror), and this is also why we have crash generation problems.
 
Last edited:
Exactly, you're not saving that much space and for the amount of problems it causes it's always best to keep it on the C drive.
 
jcgriff2 said:
Are you saying that minidumps do not contain the unloaded driver list, but a full kernel does (for the same user; same BSOD)?

I always have users set crash dumps to full kernel, which produces a full kernel dump + a mini dump.
Click to expand...

Apologies I just remembered. The users settings were already set to Kernel dump and it still produced the mini kernel dump. I had asked him to change it to small memory dump and his reply was:
Please excuse me , it was indeed kernel dump who was checked
Click to expand...
,

Thanks for the above replies I'll investigate how his page files are set up but you've given me at least some ideas to go on.. Much thanks once again.

 
Tell the user to do everything I said here, even if they already think they have for at least clarity purposes:

1. 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'.

2. 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 Kernel Memory Dump is selected and ensure the path is %systemroot%\MEMORY.DMP.

3. 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.
Click to expand...

If it's all done already, ask them to take a screenshot of their Startup and Recovery window.
 
I asked him three times to change it Patrick and nothing makes a difference whether it be kernel memory dump or small memory dump it all produces these mini kernel dumps.. It must have something to do with his page files like you say.... Maybe..lol
 
It's not so much the Kernel Memory Dump is the important step, the others are. You can have KMD set as the desired crash type, but so long as all of the prerequisites are not in place (WER, pagefile, etc), it won't generate.

Also, it's very important to keep in mind that if it is a hardware problem, the crash dump process may not be completing gracefully, therefore all we get is a triage dump (as Jared said, a snapshot of the thread stack, loaded drivers, etc). The dump process has to completely fully and gracefully to capture the entire kernel memory space.

With that said, if the crashes weren't happening before installing the new GPU, I would revert back to the old GPU and see if the crashes stop. If they do, then there's the problem. No use in creating headaches with dump settings if you don't have to.
 
Agreed. This isn't the first R9 BSOD thread I've dealt with and I doubt very much it will be the last. It seems these cards either place too much strain on the system or they are poorly designed. One only has to search the net a little and it soon becomes apparent there are many users with issues with these cards. In fact he tested the cards memory and it had faults so a replacement was duly sought and the next card also has memory faults as well as the bsod's. I advised the user that its more than likely that both cards are faulty and to send the new one back too.
 
Mate,

Those R9's run hot.
I had a situation where no matter what I tried the user was still getting crashes. His R9 was on water, BTW.
Eventually he opened the case and left it open. Bingo! no more crashes.
Attached is photo of his case. He certainly had enough air flow, well I thought that he did.2.jpg

Just as a side note, did you have a look in c:\Windows\Live KernelReports\WATCHDOG
 
I was thinking of buying an R9 as well, I'll probably stick with Nvidia.
On a different note, I always love these conversations we can have on this forum, especially the tutorial/information section.
 
'Your right they do run warm but he has adequate cooling.

Really i just wanted to find out about these damn min kernel dumps and to be honest I still feel that the explanation of it being a snapshot or because it was an awful crash and therefore didn't get written isn't the the actual reason. The reason why I think this is because i've had a user sending me bugcheck 124s and they have been fine. Small memory dumps with all the info one would need. In this particular case the user needed his drivers updating and also his bios which he then upgraded. Once he did that all his machine would produce (the bsods continued) was these damn mini kernel dumps. Now I have to wonder what the hell was changed.... The user certainly didn't change any settings in the advanced user settings drop down list but nevertheless these type of dumps started to appear. To digress a tad, I can debug without the unloaded list and i guess it isn't a huge obstacle more of a pain in the *** really. I'd just love to know why it happens.

I'll check on his watchdog folder although I think the user has given up to be honest..lol
 
I always love these conversations we can have on this forum, especially the tutorial/information section.
Click to expand...

One of the only forums where you'll find it : )

Really i just wanted to find out about these damn min kernel dumps and to be honest
Click to expand...

Yep, like we said, either a snapshot since we didn't gracefully crash, or there's some sort of pagefile problem. If the user has given up, not much you can do.
 
If it is set to Kernel memory dumps, check to see if there is a memory.dmp and use that instead.
It can be a bit difficult due to the size but they normally get the job done, the cause as Patrick pointed out seems pretty clear, it's just interesting getting to the bottom of this though.
 
Last edited:
The only reason I'm unsure it isn't a graceful crash issue is because of a previous user I had this problem with. As explained above his dump files were fine until he updated his drivers and bios. Suddenly the dump files changed from small memory dumps to mini kernel dumps and if it was down to a ungraceful crash wouldn't that be sporadic? Like some dump files would be worse than others.. I mean this was like a switch had been thrown. (I tried asking the user what if anything he changed but he hadn't changed anything settings wise)

The other way I've tried to approach this is to see how one would go about producing mini kernel dumps by design. Which settings would you need to change in order to just produce this type of dump file?

I'm not totally discounting either of your theories as they all sound plausible and I thank you guys for putting up with my incessant ravings.
 
As far as I know the main way for manually creating mini kernel dumps is attaching a local debugger which can issue commands by using noninvasive methods of recording information (AFAIK) which doesn't lead to a system crash.
I'm unsure why it does it automatically though.
It can be created by running the kdbgctrl.exe found in the debugging tools for windows, it's used as a remote debugger control.
I'll need to look further into this.
 
Ok, my suggestions, so you can ignore them if you like.:grin1:

Get the user to remove any AMD software (like CCC) and only have the drivers installed.
Try version 13.1, it seems to be the most stable for the R9's. Available from HERE.

About the odd crash dumps I would probably get them to run the following command as Administrator:
Code: 
wmic recoveros set DebugInfoType = 2

Then double check the registry, by asking for a screen shot of:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]

I see that you asked in post #25 for the user to set the crash type, in your thread, but I prefer to see screen shots when weird stuff happens.

Anyway just my 2 cents.
 
There are several undocumented functions in creating memory dumps.
One is the "mini-dump" generated file - where the STOP error is 0x1000007E for example - the 1 indicating that it is a mini-dump (this was figured out through anecdotal information - so it may not be entirely accurate). I have no clue as to how this relates to saving the dump.
The other is when wininit.exe launches WerFault.exe -k -c (-c is to create a minidump). This implies that there's a larger dump that needs a size reduction - otherwise the system can simply go to the C:\Windows\Minidump directory and pickup the latest one.

It's been my impression over the years that the system generates the complete memory dump (actually dumps the full contents of memory to the pagefile (or other designated location), and then the system decides to create a mini-dump from it. Most references to mini-dumps indicate that they are extracted from larger dumps. I have seen no references that indicate that they may have been created alone.
I haven't seen this (nor have I looked for it) since the XP days, so that behavior may have changed.
It would be interesting to investigate this behavior (and the 0x1xxxxxxx STOP errors) to see if it does have an impact on how the dumps are created

Again, AFAIK, in the event of an ungraceful crash, the system checksum's the components involved in capturing the crash.
If the checksum doesn't match the one made at boot, then the system discards the dump (presuming it's corrupted).
This second checksum occurs after the reboot, so the actual "dump" has been completed - but it hasn't been converted/compiled/whatever the process is to make it into a file with the .dmp extension.

Then, recently, there have been changes in the way that the type of memory dumps have been selected.
Now there's an "auto" setting in the registry that lets the system decide what kind of dump to collect (Windows 8 and Windows Server 2012: Automatic Memory Dump - Ask the Core Team - Site Home - TechNet Blogs)
This implies (IMO) that the system is able to select (at that early stage) what type dump is needed.
It still sorta implies (IMO) that the system takes a complete dump of memory and then converts it into what's needed
Again, I'll need to investigate the creation of the C:\Windows\MEMORY.dmp file and it's relation to any mini-dumps that are created.

Also, changes to the CrashControl key in the registry won't necessarily be reflected in the sysdm.cpl applet that you adjust the settings in
(ref: Understanding Crash Dump Files - Ask the Performance Team - Site Home - TechNet Blogs )

Finally, it seems to me that the system would have to generate the complete dump of memory during a crash as there just isn't time to select different types of data during the crash and then collect the dump of the memory.
Once the system reboots, then it has time to "massage" the data - and create the requested dump files.
This mechanism is still a bit unclear. I've compiled traces of system boots w/Sysinternal's Procmon utility (that's how I'm trying to figure out how the MachineCrash key gets deleted) - but haven't done it with a system that's BSOD'ing.
If I get one at work soon, I'll try to log the boot of a system after it BSOD's (this'll be difficult, as I'll have to have a system that reliably/predictably BSOD's).
I still have to wonder about the relationship between the MEMORY.dmp file and the files stored in the Minidump folder.
 
2 quick notes (experiments in an 8.1 VM):

- changes in the registry may not be reflected in the GUI for crash dump settings.
- In Win8.1, the system does not create a full/kernel dump when set for minidumps - rather it created a C:\DUMP0a8f.tmp file, from which (I'm guessing here) WefFault.exe extracts a minidump.
No idea of the properties of the C:\DUMP0a8f.tmp file, as it appears to disappear before I can get to File Explorer
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top