This means that your commands will go through the routines from user-mode to kernel-mode and then vmx-root mode; thus, the debuggee is continued for some time, and then the debuggee is halted again.
It is clear that you'll lose the current context (registers and memory), and also your current process, which is under debugging, might find some time to continue its normal execution.
One important note about HyperDbg is that whenever you want to create an event (run an "event" command), HyperDbg continues the debuggee; however, all the other events (active events) are ignored till the current event successfully applied; thus, HyperDbg might ignore some of the events during this process.
Let's assume we triggered a breakpoint in our target process, and from now on, we want to monitor any syscall (syscall = 0x55) execution by that process. Clearly, if we use the !syscall command, as it's an event, the debuggee will be continued, and we might lose some of the system-calls as we didn't apply the event (syscall-hook) immediately.
What's the solution to solve these problems?
Whenever the system is halted, you can run scripts in debuggee, and HyperDbg executes the script while it guarantees that the debuggee (both user-mode processes and kernel-mode) kept halted.
The solution to this problem is to create the event before trying to debug the debuggee target process. For example, we execute the following command to get the syscalls
0x55 from the process with
HyperDbg> !syscall 55 pid 490
After that, we can see the event number using the 'events' command.
Note that the event number is
0 in this case.
HyperDbg> events0 (enabled) !syscall 55 pid 490
Now, we disable the event using the following command.
HyperDbg> events d 0
If we rerun the 'events' command, we can see that the event
0 is in a disabled state.
HyperDbg> events0 (disabled) !syscall 55 pid 490
0 is the event number which we get from the 'events' command.
HyperDbg> events e 0
HyperDbg> ? enable_event(0);
After that, we receive the events relating to the event with event number
0; thus, we won't lose any events as the guest remained paused while the above expression command is executed.
At last, if we want to disable the event, we can use the following commands.
HyperDbg> events d 0
HyperDbg> ? disable_event(0);
Using this way, we can solve the problem of losing some events in HyperDbg.