Never mind, please ignore my previous email. The QMP command 'xp' can dump the memory, I'll try to reproduce this issue and dump the memory. Thanks Annie

CC Nate

Hello Laszlo, I was thinking of CR2 because it has the address that causes this exception, and we suppose to find out the information of the page in which the address locates. no? Thanks Annie

Hello Laszlo, "click "Reboot" with Shift held down " works properly for me too, the Windows can boot into recovery mode in my environment. I just updated the bug with an another simpler way to

I think that's a typo: it should be CR3. But, I agree -- you can use QEMU monitor commands to read RAM words, and walk the page tables manually. (I figured I could help with this, but I couldn't

Annie, I’ve never used it, but I assume there is a way to dump page tables from the QEMU console. Maybe something like `info mem` ? Thanks, Andrew Fish

Annie, CR2 points the 1st level of the page tables. Those entries point to other page tables, so you kind of have to walk it by hand. https://wiki.osdev.org/Paging Thanks, Andrew Fish

Hi Jiewen, In DumpCpuContext function in ArchExceptionHandler.c, the exception details are gotten from either "SystemContextX64->ExceptionData" or "SystemContextX64.xxx". I am wondering how I can

Yes it is very strange.

Good question. The CR0.WP is set. But the page table protection may be turn OFF/ON again, if CPU driver need update it to protect an EFI image. Maybe it a bug somewhere. I just read the final debug

Stupid question? Is there a reason the page tables are not write protected and the write to the page table would fault? Thanks, Andrew Fish

Hi Arie I added some of my thought in the Bugzilla. - https://bugzilla.tianocore.org/show_bug.cgi?id=3269 If you can dump paging structure info for further analysis, we can help to check.

WARNING Wish List off topic….. It would nice to have a debug script that could post process serial log file and append the extra information. That tool would need to bee toolchain aware as for gcc

Hello Laszlo, In my previous email, the exception is reproduced with pretty old code base from where I started bisecting the comments. This time I reproduce this issue with the code of branch

Hello Andrew A bug is filed - https://bugzilla.tianocore.org/show_bug.cgi?id=3269 I changed the DEBUG flag to 0x8070FFFF in OvmfPkg/OvmfPkgX64.dsc, and hope it provides more helpful debug log. The

Hello everyone, My name is Ayush Dwivedi. I am currently studying Computer Science and Engineering and am in my 3rd year of B.Tech program. I am interested in operating systems, firmwares and game

In addition to what Andrew said, I suggest the following: (1) Please rebuild OVMF *locally*, using the same edk2 tree, and the same toolchain, and the same "build" flags. (2) Reproduce the issue,

Annie, Can you attach the entire serial log of the boot to give some context to the address ranges? Also please file a BZ. CR2 is the fault address and I think the ExceptionData is implying a

Hello, I ran into a windows booting failure issue(a page fault exception), and narrow down it to the following patch, MdeModulePkg/DxeIpl: support more NX related

Redirections are processed in the following order: - pipe first (redirects stdout) - then left to right, as seen on the command line So what we have for "xxx.sh" is: step#1: file descriptor 1 refers