Always bugcheck with PAGE_FAULT_IN_NONPAGED_AREA on Lenovo y700 (7601, x64)

[mountainspeak]

Hi, tandasat

HyperPlatform always causes PAGE_FAULT_IN_NONPAGED_AREA bugcheck on my laptop Lenovo Y700. This issue only occurs in 7601 x64, while HyperPlatform runs normally in 14393 x64 on the same laptop. I put HyperPlatform in VMWare Workstation running a 7601 x64 and no bugcheck occurs.
I have no idea what causes the problem. :(

My laptop configuration:
i7-6700HQ, 16G DDR4, pagefile enabled, without any anti-virus software.

Build with Visual Studio 2015 Update3 & WDK 14393

[tandasat]

Hi, thanks for reporting the issue.

Can you provide MEMORY.DMP created after recovering from bug check, along with HyperPlatform.sys, HyperPlatform.pdb and HyperPlatform.log?

[mountainspeak]

I have sent the files to your gmail. ;)

[tandasat]

Thank you for sending files! Does it reproduce with a debug build? It is harder to analyze release build. If it does, can you please send me the same set of files? I should have mentioned it, sorry.

[mountainspeak]

The project was compiled with Debug build, but with full optimization on. Does it matter?

[tandasat]

I see. Yeah, it optimization is enabled, it will be pretty much same as Release build, and Windbg cannot map some info in the DMP with source code.

[mountainspeak]

The same set of files have sent to your gmail.
Debug build & all optimization off ;)

[tandasat]

Thanks, I received the files and confirmed contained valid, full debug information. I will find some time soon.

[tandasat]

Hi, can you try out b0cfef6 in a branch issue34? I have not been able to reproduce the issue yet, but believe that I understand the cause.

Thanks!

[mountainspeak]

Nice! Branch b0cfef6 is tested and no bugcheck occurs. I'm wondering why this issue only occurs in my laptop running 7601 x64

[tandasat]

Beautiful. Thanks for testing it. I will merge it later.

The fix code path is executed when VMM needs to create a new EPT entry. It occurs when a physical address which is not backed by RAM, ie PA for MMIO by devices, is accessed, as we are unable to know such addresses prior to an access and build EPT entries for them beforehand.

The reasons why it happened only on the specific environment was that the machine had a device accessing such a MMIO PA and that the address hit the fixed condition (the condition is completely depending on a layout of RAM and MMIO addresses). So, the issue could happen on other systems, but unlikely on VMware as VM's memory layout (including MMIO addresses) was pretty much the same always.

[mountainspeak]

Thanks!!
Learned a lot. :P

[tandasat]

You are welcome. Re-opening it just until it is merged into master.

Thank you for reporting issue and helping me!

[tandasat]

Fixed with 8ded197