I'm doing some remote kernel debugging with IDA + WinDBG plugin and I want to set a breakpoint in some function inside the DLL, which I found while disassembling it in IDA. I switched to the process, which loads the target DLL, but unfortunately I found out that the DLL in memory is partly missed including my function.
Examples for proof are below. Here IDA recognized the function sub_180001FC8, but in WinDBG this disassembly breaks off on address 0x7fff3d131fff.
Screenshot 1 - DLL loaded into memory in live kernel debugging
Screenshot 2 - same DLL opened in IDA "statically"
What's wrong and how to recover missed parts?
Finally I found the answer.
The region where disassembly breaks off with ?? is paged out memory region.
To "restore" the page I used the command:
.pagein /f /p <process_address> <page_start_address>
For my situation:
.pagein /f /p 0xffffbc4a4405efc0 0x7fff3d132000
This command loads memory pages from secondary storage and they become visible in disassembly.
References:
https://en.wikipedia.org/wiki/Memory_paging
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-pagein--page-in-memory-