RemedyBG 0.2.1.0

Change log for RemedyBG 0.2.1.0.

* Now allow referencing registers (RAX, RSP, EAX, AL, etc.) in the watch window
* Adds hexadecimal format specifier ('x' or 'X')
* Memory window now refreshes with changes to target's state
* Fixed typo in session state display for F11
* Control>Break will default to the main thread rather than the OS created thread
* Modules are now listed in the order they were loaded
* Expression parser implements better handling of pointer arithmetic
* Expression parser now allows casting an integer to an arbitrary type
* No longer switch focus to text window if disassembly in focus
* Fixed disassembly output when an invalid instruction is found in instruction stream
* Colors for status bar now reflect exception vs. running vs. suspended state.

I sincerely appreciate the continued support from the community. Thanks all.

--
George

Edited by x13pixels on Reason: Initial post
Added a bunch of suggestions/feature requests/... in github but wanted to still post here and give you a thumbs up and thanks for the awesome work!
direbroom
Added a bunch of suggestions/feature requests/... in github but wanted to still post here and give you a thumbs up and thanks for the awesome work!


Thanks, man!

--
George
Hi,

I have a question for you, but since I've never really looking into PDB I'm not sure it'll make sense what I'm asking but I'll try anyway:

So I had a case yesterday where I had a _debugbreak() in a function and remedy correctly stopped and resolved the function symbol, however it wouldn't load/recognize the source file for it. I opened it manually and remedy basically said "that file has nothing to do with the exe you're debugging" (everything worked perfectly for other functions in other files, so it's not like it didn't work at all)

Can you add some debug information/logs about how the source file resolution works in order for me to give you more details on what might be the issue? Thing is, it's a fairly large codebase here and I don't know if/how I'll be able to shrink it done enough to share but still expose the problem.
Maybe something where I can go to the context menu for a function in the callstack and say "resolve source file" (so it doesn't need to happen all the time)

I hope you understand what i mean.. (again not knowing how it works/how you do it) but something like:
symbol_x -> source_file.c / source_file not found/... something along those lines, whatever would help you to find/fix the issue (or let me know what might be wrong in my setup here)

cheers,
sev
Sev,

Because querying for a symbol and its line information is so common, these two sections of a PDB are merged together a single time upon loading the symbol file. A mistake on my part during this step is quite probable.

Probably the fastest way for me to see what's going on is to take a look at the associated PDB file along with the name of the function(s) you are having problems with (no source code or binaries necessary). If that isn't possible then I can make you a separate EXE that spits out detailed information that we can use to track it down.

--
George
Hi,

unfortunately I don't own all the code (aka symbols) in the project where I've encountered the issue so I can't really send you the PDB for it and I haven't seen it happen yet on my own projects (sorry about that I know that would have been the faster solution).

But I'll be happy to try a custom build and work with you to figure out what's going on.

Let me know how you will want to proceed.

Cheers,
sev
direbroom

Let me know how you will want to proceed.


If you'll send me an email so I have your address we can work out the details there. I appreciate your help.

--
George