I'm trying to debug a game and it's closing under few circumstances:

  • When debugging (solved by hooking IsDebuggerPresent to return false when called by the game)
  • When setting a memory/hardware breakpoint to see what reads/writes

Testing with x64dbg and cheat engine, I'm getting the same results with both tools

I can debug some functions and put breakpoints in opcodes to see the program workflow (for example IsDebuggerPresent, I can set a breakpoint there and step in) but I'm not sure if I can do it everywhere

The final goal is learning to identify functions by checking what reads/writes on values

Here are all breakpoints I've checked without results, the game closes directly:

enter image description here

Should I trace who is closing the game to disable it? Or should I debug it differently? If I have to trace, how can I do that if it doesn't hit the breakpoints when closing?

  • The code in your screenshot calls RtlQueryPerformanceCounter then some check, and then ExitProcess, which is a common anti-debugging technique. You are dealing with some anti-debugging features. If these anti-debugging attributes are of no interest to you, you can use a x64dbg plugins that try to bypass them. Have you tried hardware breakpoints?
    – Yotamz
    Commented Feb 21 at 9:59
  • The code in my screenshot is the symbols tab of x64dbg... As I explain in my question when I set a breakpoint it closes directly... I've checked with ScyllaHide if that's the plugin you're refering to but it doesn't make any difference and my idea is to learn
    – kuhi
    Commented Feb 21 at 15:06

2 Answers 2


Possibilities worth checking:

Try combinations of these and see if the behaviour changes:

  1. Disable all exception filtering by the debugger (pass all exceptions to the program). If the program uses custom exceptions to detect a debugger it will let them through. A common technique is throwing a SingleStep exception or a breakpoint exception and catching it. If the handler doesn't get called then there probably is a debugger attached.
  2. Enable all exceptions (the opposite of 1). If the program throws exceptions expecting some kind of handler code running - you will see them earlier and decide how to handle them.
  3. NOP or otherwise skip calls to SetUnhandledExceptionFilter. This function allows another technique for detecting an attached debugger.
  4. NOP calls to NtSetInformationThread. This API has a specific ThreadHideFromDebugger flag that, well, hides the running thread from an attached debugger.
  5. Put the breakpoint(s) in the function you want to break at but not on its first instruction (maybe on the ending RET).
  6. Break on process exit. You should be able to see the last state of some memory parts and registers. (not sure if x64dbg has this feature)
  • hi, sorry for late reply, not sure how to do 1 and 2 with x64dbg... hook set for 3 and 4 correctly... ok for 5... which debugger has that feature you mention in 6? It still closes when setting a breakpoint
    – kuhi
    Commented Mar 23 at 1:39

After testing several methods, the easiest ended up being TitanHide.

With TitanHide, setting only ThreadHideFromDebugger:

enter image description here

And enabling my hook for isDebuggerPresent to return false always, I can breakpoint and debug the game normally.

For PatchGuard I've used EfiGuard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.