Terminating critical process (csrss.exe)

[expend20]

Describe the bug
Hello there!

I'm trying to setup debugging of my physical machine with i9 13th gen, I'm able to load vmm with .connect local as well as use listen & connect from a neighbor machine via tcp.

As soon as I try to load an example script, kernel debugger pops up with something like this:

Microsoft (R) Windows Debugger Version 10.0.22621.2428 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target 192.168.8.193 on port 50000 on local IP 192.168.8.233.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 19041 x64 target at (Mon Jun 17 10:25:31.069 2024 (UTC - 4:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*z:\symbols*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*z:\symbols*https://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 10 Kernel Version 19041 MP (32 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff800`54400000 PsLoadedModuleList = 0xfffff800`5502a360
Debug session time: Mon Jun 17 10:25:31.337 2024 (UTC - 4:00)
System Uptime: 0 days 0:05:44.883
Terminating critical process 0xFFFFCF83AFA640C0 (csrss.exe)
Break, or Ignore (bi)? b
b
Break instruction exception - code 80000003 (first chance)
nt!PspCatchCriticalBreak+0xa2:
fffff800`54d0d5a6 cc              int     3
24: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffcc8d`502decc0 fffff800`54c1845b     nt!PspCatchCriticalBreak+0xa2
01 ffffcc8d`502ded60 fffff800`54abf320     nt!PspTerminateAllThreads+0x15853f
02 ffffcc8d`502dedd0 fffff800`54abf11c     nt!PspTerminateProcess+0xe0
03 ffffcc8d`502dee10 fffff800`54811b05     nt!NtTerminateProcess+0x9c
04 ffffcc8d`502dee80 fffff800`54802940     nt!KiSystemServiceCopyEnd+0x25
05 ffffcc8d`502df018 fffff800`5489d271     nt!KiServiceLinkage
06 ffffcc8d`502df020 fffff800`548124ec     nt!KiDispatchException+0x13fbb1
07 ffffcc8d`502df860 fffff800`5480dd52     nt!KiExceptionDispatch+0x12c
08 ffffcc8d`502dfa40 00007ff9`f068e6d4     nt!KiPageFault+0x452
09 000000ff`88c7f178 00007ff9`edc960c9     0x00007ff9`f068e6d4
0a 000000ff`88c7f180 00000000`00000000     0x00007ff9`edc960c9

If I ignore this error, it leads straight to a BugCheck

The behavior is consistent no matter if I connect hyperdbg locally or use listen & connect commands.

Desktop (please complete the following information):

• OS: Windows 10 22H2
• Processor 13th Gen Intel(R) Core(TM) i9-13900KF 3.00 GHz, 128 GB ram
• Environment: Physical Machine
• hyperdbg v0.9.0

[SinaKarvandi]

Hi,
Thanks for creating this issue.

Is the problem only with the '!syscall' command or other command make this behavior as well?

Could you test the '!syscall' command like this:
!syscall script { printf("syscall number: %x\n", @rax); }
I wanna make sure that this is a problem with this specific command or the hypervisor itself.

[expend20]

Thanks for a quick reply @SinaKarvandi!

I've tried !syscall script { printf("syscall number: %x\n", @rax); } and it works for a few seconds, but after that Terminating critical process ... (csrss.exe) still arrives into a kernel debugger.

This is weird because now I've setup vmware debugging via serial port on a completely different physical machine, and I also tried hyperdbg v0.5.0 as well, however this error persists.

What else could I check?

[SinaKarvandi]

I tested it and I could confirm the error, I think this behavior is because of the new protection they've added to the Windows for PatchGuard to prevent the syscall hooks.

We probably need to change the way we hook system-calls.

For now, you can use an alternative method to hook system calls as described here:
https://docs.hyperdbg.org/commands/extension-commands/syscall#alternative-method-for-syscall-interception

[expend20]

thanks! at least I'm not insane then :)