Error while using CODEMON resulting in Windows Kernel Crash

[ubersandro]

Windows 10 crashes while monitored with the Codemon plugin. I am using Ubuntu Focal Fossa 20.4.6 LTS. I recently moved to xen 4.17 and Drakvuf 1.1. I compiled Drakvuf enabling debugging features. This is the output leading to the crash. errlog2.txt https://www.tinyurl.com/drakvuferrlogwin

[ubersandro]

I traced back the problem to the routines executed at libdrakvuf initialization which are in the json-profile.c file. What is the function of such routines? I am exploring Drakvuf code for, like the first time; I guess they perform some sort of symbol lookup reading the json file generated using the following code snippet at a certain point of the setup phase: python3 ~/drakvuf/volatility3/volatility/framework/symbols/windows/pdbconv.py --guid GUID -p NAME.pdb -o win.json Is my guess somehow correct? The point is I tried to regenerate the file multiple times to be sure it is correct but Drakvuf still fails to monitor Windows. Do you have any ideas why it fails? By the way, thanks a lot for you help!

[BonusPlay]

Logs don't really help a lot in this case, could you provide a coredump?

[ubersandro]

Good morning and thanks for your answer. I will put here the output of xl dmesg which seems to contain the cause of the crash. It reports a failure linked to p2m. I will try to collect a coredump and some more further information and update this issue.

[tklengyel]

rc -12: XEN_ERRNO(ENOMEM, 12) / Out of memory /

You ran out of memory for the VM, probably need to increase your shadow_memory setting in the VM config.

[ubersandro]

I tried to raise the shadow_memory value to 128 and it actually solved the crashes problem as the Windows instance no longer raises exceptions; I am no longer noticing blue screens/kernel panics as before. Unfortunately, now I have a new problem. The OS keeps on blocking during the monitoring. xl list shows no state for the windows domain, i.e. it just prints ----- five dashes with no info on whether it is blocked, running etc (even if I think this may be due to the fact that I am preserving the domain after a crash, does this make sense?). I am currently running Windows with the following config: arch='x86_64' name="win10" maxmem=5000 memory=5000 shadow_memory=128 vcpus=2 maxvcpus=2 viridian=1 builder="hvm" vif=['type=ioemu,model=e1000,bridge=br0'] disk=['phy:/dev/vg/winvol,hda,w','file:/home/pwn/Downloads/Windows.iso,hdc:cdrom,r'] on_poweroff='destroy' on_reboot='destroy' on_crash='preserve' vnc=1 vnclisten="0.0.0.0" vga="stdvga" usb=1 usbdevice=['tablet'] audio=1 soundhw='hda' altp2m=2 type='hvm' I cannot really explain to myself why it happens, but the strange part is that it only happens after a certain time of using the guest with Drakvuf running. I don't know whether or not it may help but, while monitoring Windows 10 with the codemon plugin, I can see libvmi handler seems stuck in a loop. All of sudden it stops at this particular point, on xen_get_memory_pfn success on pfn=0x148884 .
Does it look suspect? I compiled libvmi for debug to observe this. What I observe is that Windows is just irresponsive. BTW, thanks a lot for your valuable help; as you can see, I am a newbie!

[ubersandro]

Besides what I wrote before, how can I handle coredumps? I think I got one using xl but how can I look into it?