Windows (64) Kernel Driver and pagable Functions

Question

i wrote a C tool to mess around with the windows kernel a bit. Now as we can see there are several functions inside the "PAGE" section, meaning this functions of the kernel can be paged out. I know their address because I can read the PE header of the windows kernel in memory. (non-pageable as well as primary .text section).

So here is my question: What do i have to do in order to call a pagable function of the windows kernel (from my driver). More precisely what do i have to do to ensure the function is currently paged-in and resident as executable memory? I get BSOD occasionally when these functions are paged out. Is there a convinient way to accomplish that? (instead of "MmProbeAndLockPages" for kernel text section called "PAGE").

Hint: i am not using windows tools. i need to accomplish that in plain old C (MinGW toolchain)

regards, Michael

---

./bin/asmdiff.exe info -s /cygdrive/c/Windows/winsxs/amd64_microsoft-windows-os-kernel_31bf3856ad364e35_6.1.7601.17514_none_ca56670fcac29ca9/ntoskrnl.exe 

Trying to get Information for file: /cygdrive/c/Windows/winsxs/amd64_microsoft-windows-    os-kernel_31bf3856ad364e35_6.1.7601.17514_none_ca56670fcac29ca9/ntoskrnl.exe...

BinaryFormat: PE_64

######### Dumping PE64-File sections: #########

Section 0: <.text> base:0x0000000140001000 len:1712881
Section 1: <INITKDBG▒9> base:0x00000001401A4000 len:14768
Section 2: <POOLMI> base:0x00000001401A8000 len:7197
Section 3: <POOLCODE base:0x00000001401AA000 len:11803
Section 4: <RWEXEC> base:0x00000001401AD000 len:4096
Section 5: <.rdata> base:0x00000001401AE000 len:252272
Section 6: <.data> base:0x00000001401EC000 len:603464
Section 7: <.pdata> base:0x0000000140280000 len:196824
Section 8: <ALMOSTRO▒> base:0x00000001402B1000 len:7664
Section 9: <SPINLOCK@> base:0x00000001402B3000 len:6464
Section 10: <PAGELK> base:0x00000001402B5000 len:85739
Section 11: <PAGE> base:0x00000001402CA000 len:2317806
Section 12: <PAGEKD> base:0x0000000140500000 len:19442
Section 13: <PAGEVRFY▒> base:0x0000000140505000 len:136619
Section 14: <PAGEHDLS▒'> base:0x0000000140527000 len:10199
Section 15: <PAGEBGFXLf> base:0x000000014052A000 len:26188
Section 16: <PAGEVRFB> base:0x0000000140531000 len:13312
Section 17: <.edata> base:0x0000000140535000 len:67960
Section 18: <PAGEDATA> base:0x0000000140546000 len:56576
Section 19: <PAGEVRFC)> base:0x0000000140554000 len:10526
Section 20: <PAGEVRFDP> base:0x0000000140557000 len:4688
Section 21: <INIT> base:0x0000000140559000 len:357788
Section 22: <.rsrc> base:0x00000001405B1000 len:221024
Section 23: <.reloc> base:0x00000001405E7000 len:8304

Answer 1

Generally, you shouldn't have to do anything to get the code paged in - the memory manager will take care of that for you.

However, if code is marked as being pageable what that means is that the function can only be called when the system is at an IRQL less than DISPATCH_LEVEL. So any code that you want to be able to run at a higher IRQL shouldn't be marked pageable.

You can dynamically lock pageable code using MmLockPagableCodeSection() (see http://msdn.microsoft.com/en-us/library/windows/hardware/ff554307.aspx ), but I think that level of control is probably needed only rarely.

You can use Driver Verifier with "Force IRQL Checking" to help more deterministically detect when you have pageable code that's being called at a high IRQL.