First of all I have to say that your debugger looks very nice ( from the UI style up to the features ;) ).

Currently the feature I´m missing the most is the possibility to dump sections from some context menu option in the memory map.


Continue the nice work!

~Zer0Flag

excuse me,just a question,where i can find alt+k on this version? thank you M.exodia

@Kurapica:

1. Yep, that's on the todo list
2. This shouldn't happen, what is your screen resolution?
3. Thanks, that should be fixed now
4. Something like this? http://forum.exetools.com/showpost.php?p=92819&postcount=22 feel free to port some scemes and send them to the author of the plugin
5. Yep, also on the todo list
6. Added that right away, will be available in the next release
7. There will be an option to specify the default application font. Notice that I won't adjust dialogs that have problems displaying the selected font.
8. What does that mean?

@Zer0Flag: Thanks :) Currently you can follow a memory page in the dump using right click -> Follow in Dump, in the future there will be an extra tab with 4 hex dumps so you can display multiple data sets at once.

@pps44: You cannot find it, it's on the todo list: http://issues.x64dbg.com

Greetings,

Mr. eXoDia

this debugger is becoming better and better well done on your hard work

would be nice to add option to use hwbp to step or trace code, a-la Olly

Hi mr.exodia and Sigma too ;)

2 - I have 2 monitors, each one is at 1920 * 1080, my CPU is i7 and I have 16 GB of memory and a separate GPU.
4 - Excellent work, Sorry I didn't notice it.
8 - I meant that the IDA-like jump bar on the left side can be distracting a little but It's a great addition.

Thanks for your efforts helping the community go on.

V2.0ALPHA is out!

Changelog:
- added _dbgfunctions to plugin header
- fixed some context menu bugs in the RegistersView
- option to disassemble in uppercase
- color settings for symbol log
- use hexedit colors in ASCII and UNICODE fiels in HexEditDialog
- added various plugin functions
- automatically add plugin callbacks on certain exports (see help)
- updated help
- updated DeviceNameResolver
- added boundary checks on DbgMem* functions (resolved some crash)
- added patches, comments, labels, bookmarks, functions to the toolbar
- speed boost because the memory map is now cached
- allow sorting in every StdTable (References, Symbols etc)
- added simple update checker
- limit size of the log view
- click bullets to enable/disable/remove breakpoints
- fixed a display bug in the title when not inside a module
- fixed attaching (does not hang anymore)
- fixed issue with deleting disabled breakpoints
- fixed an issue with the last breakpoint never removed from the database
- fixed a crash in the string reference functions
- fixed a bug in valapifromstring (test.exe:imagebase now works)
- double click now works better
- double click on breakpoints will follow in CPU
- fixed a display bug in the InfoBox
- breakpoints/bookmarks in the reference view
- fixed focus problem in Goto dialog
- double click on the CIP register will follow it in the CPU
- added font customization options
- fixed a bug with displaying 'rep stosb'
- fixed a display bug when there are no bookmarks/comments etc
- fixed a bug in valtostring, editing CSP will now actually update the stack
- fixed a bug with negative values in 'complex' expressions
- WordEditDialog now allows signed and unsigned decimal editing too
- added callstack
- added 'Patches' to Disassembly context menu
- you can now 'Modify' a value in the stack from the context menu

Website:
http://x64dbg.com

Greetings,

Mr. eXoDia

I find a bug in font setting, when I setting the font, it says setting saved, but when I restart x32_dbg.exe, it restored default setting, my os is chinese x64 win 7 ultimate.

will you fix it?

@cxj98: The font setting is working fine on my side. Could you try my attached INI file?

Greetings

you file is fine but after change theme with plugin, bug again, I don't know is it conflict with plugin?

I really have no idea about the plugin, sorry.

Greetings

Hi mr.exodia! First thing COMPLIMENTS for your hard and amazing work on x64dbg!
Than I looked the features request list but didn't found the request of copy-paste of selected parts of disassembly. Will be really useful! I love to document my reverse jobs copying the interesting parts of disassembly and paste into my documentations ;) hope that will be possible in a future release of x64dbg.
BEST REGARDS

@cjack: Actually it was on the list, but I'm working on it. Implementing stuff like this is just very boring lol (https://bitbucket.org/mrexodia/x64_dbg/issue/63/copy-address-opcode-instruction-text)

Greetings,

Mr. eXoDia

mr.exodia

Hi

i post :
_http://bbs.pediy.com/showthread.php?t=188535
:)

I download and install MUI language packs Chinese (Traditional) & (Simplified)
but I can't reproduce the bug with FangSong font or else Chinese fonts...

Can you upload your used font file?
Also, your used font it is with Chinese character name ?

@Insid3Code: The problem is with fonts that have an non-ascii character in their name, all the default windows fonts are working fine here...

Greetings

@Insid3Code

I use fixsys font is working, I think the problem not of your plugin, maybe is x32_dbg.exe not support spcial none-english font.

Nice tool. Add a "make x64_dbg just in time debugger" feature pls in the next version.

Thanks for this update.

very good work, very useful tool!
i use it on 64-bit systems.
but i cann't use windows symbols with it.
i've downloaded symbols (windows 7 sp1 x64) from microsoft site,
but only 25% symbol was found, 60% mismatched, 15% not found at all.

i would be very glad if x64_dbg will be able to use IDA-map files, as syser.

@u_f_o: You should copy symsrv.dll into the x64_dbg directory and then set the environent variable like this:
Not recommended to use to globally, maybe a .bat file:
Greetings

loving the improvements and the progress and finally a x64 debugger.

thanks alot for all the time spend in this project.
looking forward to the next upgrade. ;)

It's a great poject. It's always good to see someone working actively on an x64 debugger who also responses/includes community feedback.

mr.exodia :

After days of testing the latest version 020, I found it less stable than 019 !!

First, the application threw several "Memory leaks" messages on Shutdown.

It was much slower than 019 and the worst problem was that once I bring the debugger's main window

to front, the debugger freezes and stops responding :(

I tried to debug the same target with version 019 and this problem didn't occur.

the freezing problem also occurs once any breakpoint is created or even reached.

I know that such general description is not very useful, If you need more information then

I will be happy to provide if I can.

V2.1ALPHA is out

Changelog:
http://x64dbg.com/changelog.html

(this post filter is really shit, it doesn't allow me to post the changelog)

Website:
http://x64dbg.com

Greetings,

Mr. eXoDia

Windows XP SP2 x64 bug. When loading 32bit exe eip points to AddressOfEntryPoint+1.

@SLV: XP is supported from SP3 and the debugger doesnt change the entry point, probably your exe does some tricks.

Exe is msie 6 x64.

Hi exodia,

How could I load application to x64dbg with argument ??? I Could not find any place to put argument in x64dbg ?

@Computer_Angel: Currently we are working on a feature to directly set the commandline from within the application, but now you have to use the InitDebug command.

We hope to be releasing an improved version of x64_dbg soon, no promises though.

Greetings,

Mr. eXoDia

I've just used this tool (V2.1ALPHA) recently and wow! I am speechless on what to say about the improvement since the last time I used this debugger! Thanks a lot mr.exodia for the ongoing development of x64dbg, it is a really nice work and greatly appreciated!

Here are a few comments:

I can't seem to find a plugin development tool or instructions? Does it exist?

Do the hardware breakpoints work? When I try to set one, I always seem to get "address not aligned" in the log.

When I try to set a hardware breakpoint on access for a byte, I see the message "error setting hardware breakpoint". The log shows "invalid size, using 1"… Yet, right clicking on the byte and Breakpoint, the "Remove Hardware" appears in the contextual options. And we can delete the HWBP…

In the small action window in between the disassembly and the dump windows: when not in full screen, the horizontal scroll bar interferes with the visibility

A little cosmetic change on the icon when pinned in the taskbar. On Windows 7 with Aero, the icon is barely visible (at least on my systems…). Maybe add a little red contour? Not a big deal, only a suggestion…

I'm having a problem with the _NT_SYMBOL_PATH on both 32 & 64 bit. I use a central folder for storing all the symbols that are updated from the MSDN online repository. C:\debug\symbols When using a batch file for setting the srv path or setting it globally in the environment variables, x32_dbg doesn't find the symbols. It's ignoring the path set with _NT_SYMBOL_PATH and only searches for a folder named Symbols in the path of the debugger. C:\debug\x64_dbg\x32\Symbols The folder didn't exist but I've created the folder and tried setting the path there. This made no difference, it won't pulls any symbols from MSDN.

I updated to the current debug tools available from MS, replaced the required files and that made no difference. The only way I can get the symbols to load outside of the debugger path is by creating a hard symbolic folder link named "Symbols" and point it to the central symbols folder.
mklink /J C:\Debug\x64_dbg\x32\Symbols C:\Debug\Symbols
This seems to be working to load from local but it doesn't pull from MSDN. I use the same cmd for setting the env bat file that works for OllyDbg ver 1. Am I missing something?

Here is log entry from a symbol that is not current. This is starting with a batch file and a hard symlink set for the symbol folder. (If no hard symlink, all symbols fail.)
SYMSRV: C:\Debug\x64_dbg\x32\symbols\wininet.pdb\44EB68294B5042CB87A79B41E46A85692\wininet.pdb not found
DBGHELP: C:\Windows\SysWOW64\wininet.pdb - file not found
DBGHELP: wininet.pdb - file not found
DBGHELP: wininet - export symbols

Loaded the same app in Ollydbg 1 via srv batch file which updated the symbol from MSDN, now x64_dbg finds the symbol.
DBGHELP: wininet - public symbols
C:\Debug\x64_dbg\x32\symbols\wininet.pdb\44EB68294B5042CB87A79B41E46A85692\wininet.pdb

Idea?
Request - Possible to add setting the local symbol path with an option for using MSDN similar to how Ollydbg 2 does? So no batch file or global var is needed.
Thx - jack

@anon_c: There is a plugin API, but it's not very documented. We are working on that.

As for your hardware breakpoint problem, this is a hardware limitation (alignment with HWBP size), please see if you can reproduce the issue on another pc.

The icon is not ours, it's licensed from icons8 (with backlinks).

@RedBlkJck: For a central storage, consider setting up your own symbol store. Please add an issue saying the symbol path must be customized though INI/Settings.

Notice that you need to manually download the symbols in the symbols tab, x64dbg will not (like visual studio) automatically download symbols from the internet, as it terribly slows down the debugging.

Greetings

Ah ok. I saw from another post in ref to the _NT_SYMBOL_PATH where it looked like the MSDN symbol store would be used.

I looked at using the symstore method but it seemed to be a little more maintenance than I cared to do. I am using symsrv with a local cache stored in a centralized folder. SRV*LocalStore*RemoteStore If the local store has an older cache or the symbol is not present then MSDN is pulled. The initial build up of the cached files slows it down quite a bit but after that it doesn't seem to take very long to load up. Easy enough to use the LocalStore only if needed.

Anyway, yes to be able to control the SymSetSearchPath by the ini file would be much more convenient. ;) Quite a bit of progress since the project started, congrats. Cheers

Do you plan to include some memory search feature like in ollydbg? This is the only missing feature for me so far. Great work.

V2.2ALPHA is out!

Because I started a Bachelor Computer Science I didn't implement all requested features for this version, they are still on the ToDo list though and when I have more time I will try to implement them.

Changelog:
- better JIT Debugger information in the GUI
- JIT commands in the help
- Fixed various TitanEngine bugs
- resolved a crash when calling plugin callbacks
- remove plugins from the internal list on unloading (resolved another crash)
- fixed a bug in SearchListView with searching (strings would disappear)
- do not draw CIP when running
- fixed a bug with copying single byte commands
- fixed the launcher (crashes with compatibility mode)
- move detach command to file menu (+ new icon)
- HW BP on [RSP] is now back (thanks to DragonLoft!)
- show if a jump is going to execute or not in the InfoBox
- fix: Changing a label from an empty value to an empty value shows an error
- breakpoint/bookmark in the symbol view
- advanced change page rights dialog
- clear threads on detach (bugfix)
- fixed a crash in AbstractTableView
- new about dialog
- search for -> command in gui
- fixed deadlock on detaching while a script was running
- fixed a bug in the DbgDisasmFastAt function
- changed some register positions
- go to thread entry option in Thread view
- save user sorting preference for the session
- fixed various possible buffer overflows and other possible bugs
- change commandline of debuggee on the fly
- select next breakpoint on enable/disable
- unicode support (UTF-8)
- register view now has scroll area
- set focus to disassembly on target load
- better scrollbars in InfoBox
- uppercase option now will not uppercase API names
- fixed a bug with duplicate recent files
- changed confusing 'memory leaks found' message
- auto move cursor on toggling BP in reference view
- performance improvement with reading settings

Website:
http://x64dbg.com

Greetings,

Mr. eXoDia

What can i say other than very nice work, finally someone to pick up the thread on x64.
What I do wonder is though if you can implement a feature so that we can be able to search full memory, all of it at once, like you can in olly for unicode and ascii.

I don't think the feature is there unless im totally braindead and missed it.
If you could add this it would make my life much easier :)

What do you think?

Thanks in advance! :)

@0x22: You can search in a single memory section by pressing Ctrl+B in the dump window.

For searching the complete memory: If you can, please code an efficient algorithm to search the complete memory. I tried various things, but they were too slow to be useful.

Greetings

Maybe you need a video tutorial https://www.youtube.com/watch?v=lwFIC7It3Fc

Sorry couldn't resist :p

hi eXoDia,

why i can't download the latest version from here

check it plz.