Hi,
Bit 5 of a page table entry is an "accessed" bit. When the CPU accesses the page, it sets the bit.
Code: Select all
0x0007f400 <bogus+ 1024>: 0x00100023 0x00101003 0x00102003 0x00103003
The first page table entry here indicates that you've accessed something in the identity mapped area, in the page at 0x00100000.
Page directory entries have a similar "accessed" bit.
Code: Select all
0x0007e000 <bogus+ 0>: 0x0007f023
0x0007ec00 <bogus+ 0>: 0x00080023
Both of these were accessed. We already know something in the identity mapped area was accessed. What was accessed in kernel space? None of the page table entries shown have the "accessed" bit set, but I can only see 40 of them. This implies that whatever was accessed was not in the range from 0xC0000000 to 0xC0037FFF, but would've been in the range 0xC0038000 to 0xC03FFFFF. The address 0xC0101510 is in that range.
If we assume the CPU did access 0xC0101510 then you'd have to wonder what is at that virtual address. Does it contain a "jmp $" instruction, or does it contain an "add [eax], al" instruction (because the virtual page is full of zeroes)? If it did contain a "jmp $" then there's no likely way that it could've caused an exception (the only possible way would be an NMI).
All of this suggests that Combuster is right - the CPU successfully accesses the page but it's full of zeros, so the CPU gets an "add [eax], al" instruction, the value in EAX is still the same value you loaded into CR0 (e.g. 0xE0000011), so the CPU tries to add 0x11 to the value at (virtual address) 0xE0000011 and this trigger the page fault (due to "page not present").
If that is the case; the next question is why does the page (at physical address 0x00100000) contains zeros. Was it loaded properly and then trashed by something; or was it not loaded properly?
Cheers,
Brendan