How to do just-in-time debugging with x64dbg

[youd...@gmail.com]

Hi guys, i tried to debug a crashed application on Windows 7 using x64dbg, but i have some problems with it.

I successfully set x64dbg as just-in-time debugger in options, and button "debug the application" started appearing in crash dialog. However i don't know how to find the source of the exception, that made the program crash. When the the app crashes and i click "debug the application", x64dbg opens somewhere in ntdll address space, and on stack, there isn't any return address going to the application code, so i have no idea how to go to that place, where the exception occured. How to do this?

[TPoDT|Mr. eXoDia]

x64dbg will break at the exception breakpoint. Pressing run (F9) should get you to the original exception if no anti-debug is in place.

On Sun, 5 Feb 2017 at 16:46 <youd...@gmail.com> wrote:

Hi guys, i tried to debug a crashed application on Windows 7 using x64dbg, but i have some problems with it.

I successfully set x64dbg as just-in-time debugger in options, and button "debug the application" started appearing in crash dialog. However i don't know how to find the source of the exception, that made the program crash. When the the app crashes and i click "debug the application", x64dbg opens somewhere in ntdll address space, and on stack, there isn't any return address going to the application code, so i have no idea how to go to that place, where the exception occured. How to do this?

--
Don't forget to report issues on http://issues.x64dbg.com!
---
You received this message because you are subscribed to the Google Groups "x64dbg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to x64dbg+un...@googlegroups.com.
To post to this group, send email to x64...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[youd...@gmail.com]

Dne neděle 5. února 2017 16:48:25 UTC+1 mr.exodia napsal(a):

x64dbg will break at the exception breakpoint. Pressing run (F9) should get you to the original exception if no anti-debug is in place.

Actually that didn't quite work. After pressing F9, program terminates and everything disappears.

[TPoDT|Mr. eXoDia]

That most likely means the program is using some anti debug. Also try updating x64dbbg.

--

[youd...@gmail.com]

Dne neděle 5. února 2017 17:07:48 UTC+1 mr.exodia napsal(a):

That most likely means the program is using some anti debug. Also try updating x64dbbg.

I don't think so. When i start that application under debugger from the beginning and cause the crash, it breaks at the instruction causing the problem. But when i do it via just-in-time debugging, it opens in some code in ntdll, which looks like some post-exception code (exception handlers, ExitProcess, ...). That means it opened too late! And there is no way to go back to where the exception occured.

[TPoDT|Mr. eXoDia]

The way JIT works is that the application shows the exception dialog. This creates an event that is passed to x64dbg. The application then launches the JIT debugger with CreateProcess and calls WaitForSingleObject on the event.

When x64dbg starts it attaches to the process and calls SetEvent. The ntdll code you are seeing is in a function similar to DebugBreak that does the initial breakpoint to signal the debugger that it can take control.

Running again with make the application return from WaitForSingleObject and that should signal the exception handler to re-throw the exception so it can be inspected.

Plugins such as ScyllaHide interfere with this and might be the source of your problems. The ntdll code is expected and definitely not a bug.

--

[youd...@gmail.com]

Dne pondělí 6. února 2017 11:12:13 UTC+1 mr.exodia napsal(a):

The way JIT works is that the application shows the exception dialog. This creates an event that is passed to x64dbg. The application then launches the JIT debugger with CreateProcess and calls WaitForSingleObject on the event.

When x64dbg starts it attaches to the process and calls SetEvent. The ntdll code you are seeing is in a function similar to DebugBreak that does the initial breakpoint to signal the debugger that it can take control.

Running again with make the application return from WaitForSingleObject and that should signal the exception handler to re-throw the exception so it can be inspected.

Plugins such as ScyllaHide interfere with this and might be the source of your problems. The ntdll code is expected and definitely not a bug.

Unfortunately i'm not able to make the exception be re-thrown. When the debugger opens, it is on ret instruction in DbgBreakPoint, going 1 step forward (F8) results in returning to somewhere, where only RtlExitUserThread is after that. Calling it terminates the program and debugging.



I didn't install any plugins, i use a clean version from here: https://sourceforge.net/projects/x64dbg/files/snapshots/
How do i make it work?