x64dbg is (probably) the most user-friendly x64 debugger right now. It's pretty, it's open-source and it usually works. But I find it very hard to switch from WinDbg to x64dbg for several reasons. Some of them are purely emotional (don't worry, I'm not going to bore you to death explaining those) but most of them are technical and related to the way x64dbg is being developed.
So, here goes slightly exaggerated but still serious list of my grievances. 🙂
Insane system requirements
Both DNSpy and x64dbg suffer from this disease. They love to use the "latest and greatest" of technologies, meaning Visual Studio 2017, .NET 4.6 and what not. That's perfectly fine when you're writing normal software. But debugger is not a normal software.
If I have a customer with a software crashing on his production servers, I can't tell him "You need to install Windows 7 SP2 and 3 different VS redistributables and reboot your machine twice just for me to run my debugger". No, I really can't.
Debugger must run on any and all systems out-of-the box. Olly does that. WinDbg does that. And it wouldn't be hard to link x64bdg with static VS runtime libs and target WinXP while using all the modern goodies. But for some reason it's not done that way.
Updated 30-Sep-2016: Mr. eXoDia let me know that now x64dbg is distributed together with the necessary runtime DLLs. We can remove this grievance off of my list. Hooray! 🙂
Uncertain direction and feature bloat
Antoine de Saint Exupery said:
Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away
These are really wise words and Olly is designed that way. It does all the basic stuff and has stable SDK that enables plugin authors to implement all the extras.
On the contrary, Mr. eXoDia is adding features left and right and the direction of x64dbg development looks more like this:
For example, why does a debugger need 3 (yes, three!) different assembler engines?
Want another example? Let's just look at the latest weekly digest.. How about this:
... change to the info box. Basically the pointer values in the instruction were not resolved (so if the instruction contained qword ptr ds:[rsp+30] it would not show the value of rsp+30). Personally this is quite useless
Yes, Mr. eXoDia, you're right. It is useless for everyone but few people.
And how about:
The commands plugload and plugunload have been added. This is useful for plugin developers who want to test plugins without having to restart x64dbg all the time.
How many people in the entire world will actually benefit from that? 5? 10?
So, why add such bloat? Once you add something, that something must be maintained. And it's very hard to remove stuff later, as it might break something else. So, please don't..
Broken features
When I am on a job and need to debug something, last thing I want to spend my time on, is fighting with debugger bugs. And my customers certainly don't want to pay me for doing that.
Oleh Yuschuk got it exactly right with the OllyDbg. There were few releases - but they were properly tested and rock solid. From what I can see, x64dbg is going the other way:
Frequent commits like "Fixed search for constant references", "Fixed intermodular calls in module", "Fixed FS/GS memory branch destinations" is not something you want to see in any software, let alone a debugger.
Well, it wouldn't matter much, if there was some known-stable version I could put in my tool collection and use it anytime anywhere. But no, Mr. eXoDia thinks that "No more excuses to not update every day!" is a way to go. Instead of using tried-and-tested version, I should use a probably buggy and unstable one? Dafuq?
Conclusion
So, those are my 3 biggest complaints about x64dbg. I'd love to love x64dbg. I'd love to use x64dbg for everything. But right now I just can't.
How about you?
Protective daddy of x64dbg here, my responses to your points:
> Insane system requirements
This is x32dbg running in Virtual Box without any software installed, directly from a network share on Windows XP SP3. What more do you want? I cannot seriously consider support XP SP2 or Windows 2000/98 those don't even have a 64 bit version from what I know...
> Uncertain direction and feature bloat
I could react to everything individually, but let me just say that the pluginsdk is still compatible with the very first plugin I ever wrote and changes to core components are done with extreme care.
Small features like in the GUI do not impact old users but do benefit new users, you don't have to use the new assembler engines or the address in the info box but the room is there, why not use it to see if it works?
> Broken features
Technically x64dbg has never come out of alpha (and it will probably not come out of alpha for another 3 years). Some people confused 0.24ALPHA (released April 2014) with a 'stable' version to use which is why I changed to a continuous 'release' model.
mrexodia
Hi, protective daddy! 🙂 Sorry for keeping the moderation queue, any URL in comment triggers the anti-spam defense.
#1 - cool, msvcp120.dll and msvcr120.dll are now included in the distribution. That's a nice change, it wasn't like that in the mid-August! 🙂 /me approves.
#2 - oh yes, new features impact old users. One reason - the GUI gets cluttered as f*ck. Example screenshot shamelessly stolen from your blog:
Highlighted are the only features I have ever used. The rest is just crud - useful for maybe 1% of all users.
Another reason - adding new features occasionally breaks existing ones.
Third reason - sooner or later it will become a maintenance nightmare (not that I care about that, I don't have to do that. 😀 )
#3 - "continuous release model" is not a substitute for proper testing.
You have a good point about GUI menu clutter and you are completely right about the register view menu (and other menus), so I changed it:
A quick feedback loop allows me to directly focus on issues people might find instead of having to focus on release management and dealing with people using month/year old versions thinking they are somehow 'stable' while the debugger is still in alpha.
Proper testing is not something I focus on personally (mostly maintenance and the occasional feature) but there is a great community out there and issues get resolved very quickly. Alternatively you can write a plugin to fix the issue like with OllyDbg 😀
Nice, complaining about free software.
How can you say 1%? I use many of those features.
I don't know how much you have done UI coding but adding menu items doesn't take jack shit from PC.
You are making money using this software, maybe donate 10000$ to mrexodia so he can improve his software (which he does on his FREE TIME) and stop complaining so harshly.
I mean nice complains are ok but you are complaining like he owes you something.
The reason is why those "useless" features are these because MAYBE someone else has coded them for x64dbg.
Not people like you who only complaining how you cannot make money more effectively.
Hehe, the classic "It's a free software, so don't complain about it!" argument. How appropriate! 🙂
I stated my opinion why I think some of decisions regarding x64dbg are wrong. You are entitled to your opinion as well. And Mr. eXoDia is entitled to his. That's called democracy. 🙂
So, if I'll code a window showing huge pile of crap, you'll integrate that into x64dbg as well?
Any project needs a leader and a clear direction in which they are moving. In my opinion, x64dbg lacks that and therefore features are being added "just because someone coded it".
have you tried to used radare2 ? well that's a true nightmare. Windbg is good for debugging your own code otherwise is not usable e.g. WinDbg scroll up/down is not implemented properly will only go +1 byte or -1 byte confusing disasembly view
but MS guys dont care about it.
64-bit OllyDbg:
October 24, 2013 - first presentation of the 64-bit OllyDbg.
February 05,2014 - the progress is steady LOL
...
Current date: 2016-09-27
Radare2? No, thanks, I'm not a masochist.
True, scrolling in Windbg disassembly can be annoying. However, I can understand reasons behind it. But Windbg excels in other areas - it's rock solid and "it just works" (tm)
This is an interesting one - daily work life for me involves having the new buzz words of 'dev ops', 'MVP' and 'agile' shoe horned into every conversation (the new "cloud" or "digital"). People tend play buzz word bingo and assume that everything has to be done that way now. In reality, what should happen is that the use case is nailed down to a point that the right model can be selected from the available options - if you are using a sprint release methodology for your core ERP solution for example, you might want to make sure you are comfortable with the inherent risks.
That said, I see both arguments on this one. On the one hand, Olly was stable and great at what it did. On the other, there were bugs/missing features in there which plugins such as OllyAdvanced fixed on V1.10 (fpu, inability to break on tls). Olly really would have benefited from more quick releases, but relied on one (all be it, brilliant) man.
On the flip side, bloat and compatibility is an issue on something which, as you say, should be a quick <1MB or so download which you can rely on in as many scenarios as possible.
Getting the balance between release cycle and stability is tough.
Personally, I have taken the positives and started using x64dbg more and more (I use a slightly older version which I consider stable, and update as I test and see the need). I welcome the opportunity to move the debugger functionality forward at a fast pace.
Having said that, I don't have your client/stakeholder requirements and I still use Olly 2 too if I'm firing something up quickly on another machine to do some troubleshooting - habit I guess.
As for Radare2.... um, yeah. That's a good example of something that's probably pretty powerful, but has been developed in such a way that the barrier to entry is ridiculous. If I need to read a manual to just do the basic stuff I can do in 30 seconds elsewhere, it's a non-starter.
With the added complications of multiple operating systems versions, nice to see a debugger that you can just use on all of them.. Open Source is always a plus for me too..
x64dbg support is shit. I just have been there now and told me to go search in his source code. Now he tell me to compile. Remind me microsoft support. #windbg
That sounds familiar.. 😀 "It's open-source, dude, just fix it and send a pull request"
To be honest, I support it because it is actively developed and the development team is responsive. It also feels robust and stable to me.
Hey Kao, I challenge you to develop a superior "x64dbg"... and please let us know when you have it ready.
Best regards.
Marck, if x64dbg works for you, that's great and I'm happy for you. But I don't have to prove you anything. 🙂
You sound butthurt on everything about x64dbg and seem to have some some beef with the developer, even though you'll never amount to anything close to what mr exodia has. See, it's just useless personal remarks. Don't even know why he wastes time explaining himself to dumb asses like you.
Of course, you're entitled to your opinion. As I'm entitled to mine.
Any time you want to have a discussion and talk about the specific items I mentioned in my blogpost, you're welcome. Until then you just sound butthurt.
What do you use instead? :))
Usually Windbg. It does everything I need, even though the UI is a bit.. strange.. 🙂
x64DBG is a great piece of software. I haven't had much issues with it that I've had with Olly. Windbg is good but its ui is ancient and honestly in this day and age, some eyecandy like x64DBG is a must. It has an active development community, lots of plugins, good API and it works well at what it does.
Thanks for your opinion. Thanks to you, I decided to give x64dbg another chance. 🙂
Here's the new article about current state of x64dbg: https://lifeinhex.com/x64dbg-2-years-later/
I came to shit on you're post like everyone else. Maybe contribute since its...... O P E N S O U R C E
Randomly stumbled upon this. Whoever wrote this article, even at the time x64dbg was in alpha phase, has no real sense of how useful this debugger is. Why you need 3 ASM engines.. try to compile a MOV RAX,[ptr] instruction and you will see.. It matters in terms of size and ASLR.
I wrote the article and gave a very specific list of the reasons why I (personally) am not using x64dbg for my work. Your reply did not address any of them, it just stated your personal opinion without any concrete evidence.
In fact, it highlighted another x64dbg issue.
Yes, you really need 3 assembler engines in x64dbg to compile a simple MOV instruction properly.
..which means that at least 2 of these engines are complete and utter crap. Why not use just one assembler engine and spend some time fixing the glaring bugs in it? 🙄
how to block lifeinhex web from google search?
You should probably google that. 🙂
If You Don't Like It Just Don't Use That... It's That Simple...
..which is exactly what the post title says.
There is no better alternative,:(
Im new to software development and stumbled across this late in the game. 2023 to be exact. Its nice to see that although we have masters degrees some of us have yet to leave high school. Open source my friend. Maybe you just dont like your job? Can we say mid life crisis?
Thank you for the valuable insight! 🙂