Using x64dbg as a development tool

[ZILtoid1991]

I'm a D developer, and while my choice of debuggers under Linux are pretty wide, under Windows not so much. I used to use Visual Studio as a debugger, but recently I was forced to look for alternatives.

Visual Studio has an official D plugin called VisualD, however it doesn't support dub, the official build tool for D, and it would make the management of dependencies a real chore. So instead I have to use VSCode, then build my project in command line using dub, then load the exe file into an empty C++ project.

This worked fine without any issues, up until recently. Since VS2022, the option to toggle the break on all D exceptions have vanished, so I have to deal with that. If that wasn't enough, the whole thing broke since an update a few days ago. It causes VS to grow until it consumes all my system resources and crashes Windows, unless I stop debugging or close VS in task manager.

So I've started to look into alternatives. WinDbg is not much better, almost giving me no clues on anything. x64dbg is the best so far, but most guides on it only discuss its reverse engineering capabilities. So far it loads my PDB files and I get a detailed callstack, but no local variables or anything like that. Obviously it won't have everything I might need (if I really need them, I'll develop some plugins for that), but at least I can debug programs on Windows, which is also my most popular target.

[mrfearless]

In theory if the pdb and the source files are in the same folder when debugging you should be able to use the source level debugging feature. Once the program breaks on the entrypoint, step once, and on that instruction right click. An Open Source File option should be available on the menu which will take you to the Source view tab, where you can continue to step, add breakpoints etc. Also worth looking at the xAnalyzer plugin to add extra information to your debugging (https://github.com/ThunderCls/xAnalyzer)

Here is a screenshot to show you the menu when right clicking:

Here is the source view (I write in assembler, so the source view is loaded as that):

[mrfearless]

Also worth checking this issue which adds some additional information about source code debugging: #2264

[mrexodia]

Just would like to comment that this is definitely something I feel could be important to increase the user base. Local types and locating source core are missing, but there is nothing really fundamentally blocking this. Just a matter of extracting the data, attaching it to the symbol and then displaying it in the UI.

Closely related is proper type support. Right now there is a proof of concept working, but this doesn’t connect with the PDB and doesn’t properly parse header files. I’ve been working on improvements there too, but it’ll definitely take a while until these things converge and become visible. Mostly because of time restrictions on my side.