adding a kernel hook causes a system crash on AMD

[chiefmasterR]

hey, I'm trying to run your project on my computer with a Ryzen 7 2700 processor. When I run it in a virtual machine, everything initializes, but as soon as I add a kernel hook using the akh command, the virtual machine freezes and does not respond. I tried running it on my computer without a virtual machine, and after a couple of seconds, either I get CLOCK_WATCHDOG_TIMEOUT BSOD, or the computer freezes as well. I am trying to set a hook on ntoskrnl.exe!ZwOpenFile. Both the virtual machine and the bare metal are running freshly installed Windows 11 24H2, build number 26100.1742

Other commands, such as reading the guest's physical memory, work without any problems

Thank you

[noahware]

It isn't to do with adding a kernel hook, its about the amount of vmexits that the hyperv-attachment handles. With a kernel hook, more vmexits are going to occur, hence the crash. This only occurs on the latest versions of 24H2 from what others and I have tested. Try go to a previous Windows version (e.g. older 24H2 or 23H2) and see if it still happens for you.

This issue has been fixed by an anonymous developer, but he has requested to keep the solution private, so it can't be published to the repository.

See if downgrading Windows version works for you.

[crvvdev]

It isn't to do with adding a kernel hook, its about the amount of vmexits that the hyperv-attachment handles. With a kernel hook, more vmexits are going to occur, hence the crash. This only occurs on the latest versions of 24H2 from what others and I have tested. Try go to a previous Windows version (e.g. older 24H2 or 23H2) and see if it still happens for you.

This issue has been fixed by an anonymous developer, but he has requested to keep the solution private, so it can't be published to the repository.

See if downgrading Windows version works for you.

Someone already mentioned similar problems here.
Can we assume both issues are related?

[noahware]

Someone already mentioned similar problems here. Can we assume both issues are related?

Yes they could be related, mainly due to "fails during heavy VMEXIT loads".

[whosstyler]

"requested to keep the solution private" thats just crazy for something like this lmfao, no surprise this is 2025 after all

Let’s remember what’s actually happening here: you’re trying to copy-paste a public hypervisor that is already extremely well-developed and, honestly, probably shouldn’t even be public in the first place. There are parts of this project that do need to be fixed, adjusted, or reworked for it to run without issues - that’s normal for a PoC hypervisor.

You’re upset because he won’t publish a fix that:

1.Was written by someone else,
2.Was shared privately with the maintainer, and
3.Was never intended to be open-sourced.

I wouldn’t release it either. Hypervisors like this are meant for learning, experimenting, and understanding the concepts — not for people to blindly paste code, run into a problem, and then get mad when the maintainer won’t hand out the solution.

Take it as an opportunity to actually dive in and fix it yourself. That’s the entire point of these projects.

[noahware]

"requested to keep the solution private" thats just crazy for something like this lmfao, no surprise this is 2025 after all

Let’s remember what’s actually happening here: you’re trying to copy-paste a public hypervisor that is already extremely well-developed and, honestly, probably shouldn’t even be public in the first place. There are parts of this project that do need to be fixed, adjusted, or reworked for it to run without issues - that’s normal for a PoC hypervisor.

You’re upset because he won’t publish a fix that:

1.Was written by someone else,
2.Was shared privately with the maintainer, and
3.Was never intended to be open-sourced.

I wouldn’t release it either. Hypervisors like this are meant for learning, experimenting, and understanding the concepts — not for people to blindly paste code, run into a problem, and then get mad when the maintainer won’t hand out the solution.

Take it as an opportunity to actually dive in and fix it yourself. That’s the entire point of these projects.

Very well said, and thank you for the appreciation of the project.

[ivanpos2015]

exit_end: vmcb->rip = vmcb->nrip; if (WindowsBuild >= 22000) { TimeCompensation(vmcb, unknown, unknown2, context); } return reinterpret_cast<svm::pgs_base_struct>(__readgsqword(0));

The solution to the problem is very simple: you must call the original vmexit because timers are not processed.

[qydc1984]

exit_end: vmcb->rip = vmcb->nrip; if (WindowsBuild >= 22000) { TimeCompensation(vmcb, unknown, unknown2, context); } return reinterpret_cast<svm::pgs_base_struct>(__readgsqword(0));

解决此问题非常简单：必须调用原始的 vmexit，因为定时器不会被处理。

如何调用原始的 vmexit

[evorafbi]

after handling your intercept, call hyper v's original vmexit handler instead of premature return, the key trick for slat violations on AMD is that you need to hide your hook state from the original handler

vmcb_t* vmcb = get_vmcb();

// save current state
cr3 saved_cr3 = vmcb->control.nested_cr3;
uint64_t saved_exit_info = vmcb->control.first_exit_info;

// hide from original handler: clear execute bit, switch to hyper-v's cr3
vmcb->control.first_exit_info = saved_exit_info & ~(1ULL << 4);
set_nested_cr3(hyperv_cr3);
flush_tlb();

// call the original which processes schedulers timers etc
uint64_t ret = original_vmexit_handler(a1, a2, a3, a4);

// restore our hook state
vmcb->control.first_exit_info = saved_exit_info;
set_nested_cr3(saved_cr3);

return ret;

for ept its the same concept, u save the current eptp, then switch to hyper-v's eptp, call original then restore

hope this helps