Address not in trace

Describe the bug Attempting to go to a virtual address to see the values in memory results in “Address not in trace” error.

To Reproduce Steps to reproduce the behavior:

1. Compile the two code snippets in the attachments sections.
2. Run analysis in the code browser for the launcher and the dll.
3. Open the launcher and the dll in the debuger tool.
4. In the launcher tab go to main and then in the decompiler window right-click anywhere just for laughs (and because I’m lazy).
5. Launch the debugger, in-vm and add the dll as the first argument.
6. Set a breakpoint after the call to LoadLibraryA.
7. Run until the breakpoint is hit.
8. Switch to the dll tab.
9. Open the modules view, right click on your dll and select “Map module to {dll_name}”.
10. Set a breakpoint at the entry point to debuggerProblems.
11. Go back to the launcher and continue running until the new breakpoint is hit.
12. Set until the string pointer is loaded into a register.
13. Find the register in the memory view.
14. Double-click the register, right click, go to the stack-view, registers in the object tree for the stopped thread, look through the Windows toolbar and just scratch you head in utter confusion.
15. Give up and try to use goto.
16. Enter the address pr be lazy and use *:4 EAX (assumming it is in EAX).
17. Be greeted with “Address not in trace” error text.
18. Mash enter repeatedly hoping it will magically work the next time.

19.

Attachments

main.cpp

#include <windows.h>
#include <iostream>
#include <system_error>

[[noreturn]] void garbageWinApiError() {
    std::error_code ec (errno,std::system_category());
    std::cerr << ec.message() << std::endl;
    throw std::system_error(ec);
}

struct Dll {
    HMODULE mod;

    Dll(HMODULE m) : mod(m) {};
    Dll& operator=(HMODULE m) { mod = m; return *this; }
    ~Dll() { FreeLibrary(mod); }
    operator HMODULE() { return mod; }
    operator bool() { return mod != nullptr; }
};

int main(int argc, const char **argv) {
    if (argc <= 1) {
        return -1;
    }
    Dll lib = LoadLibrary(argv[1]);
    if (!lib)
        garbageWinApiError();
    FARPROC fun = GetProcAddress(lib, "debuggerProblems");
    if (fun == nullptr)
        garbageWinApiError();
    fun();
    std::cout << "Press any key to continue..." << std::endl;
    std::cin.get();
}

dllmain.cpp

#include <Windows.h>
#include <iostream>

extern "C" BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        std::cout << "Deleting System32 please wait...\n"
            << "Deleted successfully...\n"
            << "Sending all your data through Ghidra's backdoor or something..." // for debugging purposes of course ◔_◔
            << std::endl;
    }
    return true;
}

__declspec(dllexport) extern "C" void debuggerProblems() {
    std::cout << "You're too late we're already done!" << std::endl;
}

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.22000.527]
• Java Version: 11
• Ghidra Version: 10.2_DEV ee268dea09d8f2632d73b0d00cdda3a377a744e1
• Ghidra Origin: [e.g. official ghidra-sre.org distro, third party distro, locally built]

Additional context #3151

[d-millar]

Well, this is just my opinion - take it with a grain of salt - but my impression is that most users can stand a considerably larger hit to the running process than they can when interacting with it. For example, full-on tracing via single-step incurs about a 100x penalty, but for debugging a serious problem on a single process many users are willing to take that hit. Tracing via step-by-branch or using dedicated hardware is considerably less, in the 10x-100x range, and most users don’t mind this at all unless they’re batch processing hundreds (or thousands) of executables. However, a 2x-10x slowdown in single-stepping is unacceptable to almost everyone. Users want to be able to bang in single-step as hard and fast as they can and have the GUI respond. Single-step normally involves a minimum of commands, typically ask for the step (often by setting a register), resuming, and returning the new register values. That’s typically of the order of a hundred bytes for a large register set. Asking for all the modules and/or all the memory regions and potentially pages that might have changed and are visible is more like a thousand+ bytes. For users with very fast machines maybe not a problem, but for most at least an annoyance. I think updating on non-single-step events is a good compromise, and generally that means process/thread create/destroy, module load/unload, and breakpoints hit.

[astrelsky]

So initially I was under the impression that I had to refresh the memory node all the time including after a single byte had been written to memory. Now that I know it is only when sections of memory are added/removed I no longer see it as such a big deal. 😅

I think you misunderstood my above comment. I initially thought the behavior was like that. After getting everything mostly working I realized I had misunderstood the reason for having to refresh the memory node. It seems to be functioning as would be expected at the moment.