I think I've tried everything but no dump file is created

Hi George300,

Why do you configure a custom page file with the same initial and max size?

What are the virtual memory setings for the other drives that are not shown in the screen shots?

It's a prerequisite for the complete kernel memory dump that the pagefile is at least the size of the RAM, plus a bit more for additional information. A complete kernel memory dump contains a lot of information of which 75% or more may be user-mode data, data which cannot be used for analysis.

I would recommend to let Windows handle the page file, because a memory kernel dump is usually more than you need which does not contain user-mode data and could be a few gigabytes in size depending on how much memory is kernel mode. Letting Windows handle the page file takes away other factors that may need to be considered for a dump file to be created as well. Some of these factors may also not be represented as a setting in any GUI, but rather as a 'setting' within the registry. An example of such is that it is not uncommon for folks to want to move the memory dump file to a different partition/drive because of the space it takes, but that may bring the situation where no dump is generated. Windows supposedly does support this, but it does not always go smooth. When such a situation arises, you should add a registry value with the path to the registry. This registry value will be used in the crash dump generation process and tells the process where the dump should be stored. This is not something you can configure within the control panel or in the Settings app.

What are the error codes you see when a crash happens?

Mainly the following.
30 = Bug Check 0x1E: KMODE_EXCEPTION_NOT_HANDLED
59 = Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION
126 = Bug Check 0x7E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
313 = Bug Check 0x139: KERNEL_SECURITY_CHECK_FAILURE
314 = Bug Check 0x13A: KERNEL_MODE_HEAP_CORRUPTION

But I have also seen these:
1 = Bug Check 0x1: APC_INDEX_MISMATCH
74 = Bug Check 0x4A: IRQL_GT_ZERO_AT_SYSTEM_SERVICE
78 = Bug Check 0x4E: PFN_LIST_CORRUPT

- - - Updated - - -

I am waiting for the next BSOD and I will be able to use the dump file for the first time (I hope).

George300 said:

I thought the posting instructions help solve BSOD issues. My post was not about solving a BSOD issue, but about dump files generation. But I will follow your advice.

The V2 tool allows us to look into issues when no dump is generated as it provides more details on the settings about dump generation, so it helps us with the dump generation issue and solving the BSOD crashes at the same time.


Only now I had a chance to look at the entire thread to see what had been done already. From the different crashes and the dump generation failure I fear this may be a RAM problem. While RAM tests are by no means always conclusive, they're less of a pain than physically testing them, which is why I would suggest to run memtest86.
How to boot MemTest86: PassMark MemTest86 - Memory Diagnostic Tool - Technical Information
Please note: you will have to run the test twice. The free version has a limit of 4 passes, but generally 8 passes is what we want to get a better indication on the status of the RAM.

Hardware can go bad quickly. I have found that it's usually not the RAM that goes bad quickly, but rather hard drives in which case there usually are signs all over the place. But the RAM can go bad quickly as well for a lot of reasons.

I hope you have noticed that the dump file was generated successfully after I disabled (and then uninstalled) avira.

Did this happen after your previous post?