Does the DisablePagingExecutive registry change have any actual effect?

There is an enormous amount of confusion on the internet regarding this function. The setting only affects the portion of the kernel known as the executive, and then only to the portions that are pageable. There are other parts of the kernel that are completely unaffected by this setting.

Kernel paging works the same way as any other paging. Code and data that is frequently accessed will be kept in RAM while the remainder will remain on disk - where it belongs. The system will not remove any portion of the kernel from RAM unless it has found a better use for it. Microsoft has devoted an enormous amount of research and testing to the paging systems.

In the context of the kernel, "Nonpaged" means code and data that can never be paged out under any circumstances. "Paged" means code and data that CAN be paged out if necessary. How much actually IS paged out is impossible to tell from Task Manager. A portion of the code that is paged out was never read from disk in the first place because it wasn't needed yet. Not all of the kernel is frequently accessed. You should not expect Paged and Nonpaged numbers to be affected by the setting in question.

Note: When code is paged out it is not normally copied to the pagefile. This is not necessary as it can simply be reloaded from the original files. This applies to most code, not just the kerenl.

With a reasonable amount of RAM the setting will do essentially nothing. It simply prevents the system from paging out data that it didn't want to page out anyway.


I'm not sure if you realise this, but page-faults are the mechanism which Windows uses to load executable code. So, for example, a DLL is mapped to virtual memory, and then page-faults are used to do the actual loading from disk as required. The pagefile is not involved in this.

So lots of what you think of as 'paged to disk' might be stuff that was on disk in the first place.


Just to add one additional use of this setting: it is needed by xperf stack walking.

http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx

Disable Paging Executive

In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages.

One additional piece of info about the setting. This quote can be found over the internet, I do not know its primary source.

DisablePagingExecutive applies only to ntoskrnl.exe. It does not apply to win32k.sys (much larger than ntoskrnl.exe!), the pageable portions of other drivers, the paged pool and of course the file system cache. All of which live in kernel address space and are paged to disk. On low memory systems this can force application code to be needlessly paged and reduce performance. If you have more than enough RAM for your workload, yes, this won't hurt, but then again, if you have more than enough RAM for your workload, the system isn't paging very much of that stuff anyway. This setting is useful when debugging drivers and generally recommended for use only on servers running a limited well-known set of applications

So one can conclude that besides the xperf-usage its benefit is obscure: Essentially it limits some "almost random" stuff from paging and on further thought - consequently causes something else to be paged out more often instead.


The DisablePagingExecutive tweak does not stop paging, it's purpose was to prevent the "Executive" (i.e. the Kernel itself) being paged and thus causing whole system slowdown, not just individual paged apps.

You can try and disable paging completely by removing all pagefiles in System Properties (or in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles). This works well for me, but things get rather unpleasant when you run out of physical memory, and you must have a page file to debug STOP errors.


System level components, such as the kernel, executive, and device drivers, can allocate memory from two pools. These are the paged pool, which can be paged out at the memory managers discretion, and the non-paged pool which must remain in RAM at all times. The developer decides according to his needs what pool will be used. It is recommended that the paged pool be used whenever possible as this allows the system memory manager maximum flexibility. Both pools are of limited size and in 32 bit systems in particular these limits can pose a problem. The paged pool is considerably larger. If the non-paged pool were used excessively the size limit could be reached and this will cause some serious system problems.

The items labeled in Task Manager as "Paged" and "Non paged" kernel memory are showing the allocations of these pools. It has absolutely nothing to do with the dynamic state of how much memory actually is paged out. The "DisablePagingExceutive" registry entry influences the dynamic paging state of a portion of the paged pool so it's effects will never be shown by ask Manager.