| View previous topic :: View next topic |
| Author |
Message |
lcineyes
Newbie cheater
![]() Reputation: 0
Joined: 19 May 2025
Posts: 17
|
 Posted: Tue Oct 14, 2025 3:18 am Post subject: I encountered a strange blue screen issue while using DBVM |
 |
|
I booted the system using DBVM from a USB drive but did not utilize any of its features. After launching the target game, I played normally for a period of time until its protection system triggered a CLOCK_WATCHDOG_TIMEOUT blue screen. In the call stack, I found that the thread causing the exception was querying information about a certain process and then timed out while waiting. When I switched to the CPU core that timed out in the full core dump, I discovered that the call stack of that thread was completely missing, and the CET bit in the CR4 register was lost. The known information is as follows:
1.DBVM was booted from a USB drive, but none of its functions were used.
2.The target program has VT-d protection enabled.
3.The operating system is Windows 10 with the latest updates.
4.The CPU is an Intel Core i7 14th Gen (CET is enabled by default in the OS).
5.When using Windows' native VT, the program runs without any issues.
What additional information should I investigate to analyze this issue? The full dump is 31 GB, and I can provide necessary details as required.
|
|
| Back to top |
|
 |
Dark Byte
Site Admin
 Reputation: 470
Joined: 09 May 2003
Posts: 25807
Location: The netherlands
|
| Posted: Tue Oct 14, 2025 3:48 am Post subject: |
|
|
clock_watchdog_timeout just means DBVM didn't know how to handle something which results in a frozen CPU that doesn't respond to anything anymore. (Which includes full system crash causing an instant reboot)
If you have a POST display on the mainboard or pci-e add-on card the value on the display could give a clue on why dbvm failed
The memory dump isn't that useful as I don't have the debug symbols of that version (and would only work if dbvm physical memory cloak was off)
Try dbvm 19: https://cheatengine.org/download/dbvm19.zip
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
lcineyes
Newbie cheater
![]() Reputation: 0
Joined: 19 May 2025
Posts: 17
|
| Posted: Thu Oct 16, 2025 9:36 pm Post subject: |
|
|
| Dark Byte wrote: | clock_watchdog_timeout just means DBVM didn't know how to handle something which results in a frozen CPU that doesn't respond to anything anymore. (Which includes full system crash causing an instant reboot)
If you have a POST display on the mainboard or pci-e add-on card the value on the display could give a clue on why dbvm failed
The memory dump isn't that useful as I don't have the debug symbols of that version (and would only work if dbvm physical memory cloak was off)
Try dbvm 19: https://cheatengine.org/download/dbvm19.zip |
Thank you, I will proceed with testing and provide feedback here promptly. Additionally, may I ask which version of DBVM is currently open-sourced? Also, is Bochs used for debugging VT? I would like to further my studies on VT technology.
The test has been conducted, and the same error still persists, as before. I would like to obtain more information, but I don't understand how to add the PCI-E POST display. I hope there can be some instructions provided.
Also, may I ask where in DBVM the code for freezing the CPU is located? I haven't seen it.
|
|
| Back to top |
|
|
C1aref5
Cheater
![]() Reputation: 0
Joined: 20 Feb 2025
Posts: 32
|
| Posted: Thu Oct 23, 2025 3:35 pm Post subject: |
|
|
Since it happens even without using DBVM’s features, you might want to:
Check if the crash reproduces immediately after DBVM loads (without launching the target app).
Confirm if the watchdog always points to the same core/thread.
Capture the MSR_IA32_VMX_BASIC and MSR_IA32_FEATURE_CONTROL values before and after loading DBVM to see if anything changes.
Try running with hyperthreading disabled — sometimes watchdogs happen when one logical core hangs waiting for the sibling VMX transition to complete.
If the problem still occurs on DBVM 19, it might be specific to 14th gen microcode (since CET integration changed quite a bit since 12th gen).
|
|
| Back to top |
|
|
lcineyes
Newbie cheater
![]() Reputation: 0
Joined: 19 May 2025
Posts: 17
|
| Posted: Thu Oct 23, 2025 11:47 pm Post subject: |
|
|
| C1aref5 wrote: | Since it happens even without using DBVM’s features, you might want to:
Check if the crash reproduces immediately after DBVM loads (without launching the target app).
Confirm if the watchdog always points to the same core/thread.
Capture the MSR_IA32_VMX_BASIC and MSR_IA32_FEATURE_CONTROL values before and after loading DBVM to see if anything changes.
Try running with hyperthreading disabled — sometimes watchdogs happen when one logical core hangs waiting for the sibling VMX transition to complete.
If the problem still occurs on DBVM 19, it might be specific to 14th gen microcode (since CET integration changed quite a bit since 12th gen). |
1.After loading DBVM, everything functions normally. This has been extensively tested. The issue only occurs when the target driver is active.
2.A currently observed characteristic is that the target driver has built-in obfuscation. To freely manipulate the stack, it uses specific instructions designed to operate on the CET shadow stack.
3.After the blue screen occurs, I observed from the dump file that the CET bit in the CR4 register is disabled on the frozen CPU. Additionally, all register values are zero.
4.If Windows' native VT is used, the target driver operates correctly without causing a blue screen.
5.Therefore, I conclude that this is still likely a compatibility issue with DBVM.
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
