Cannot get debugger working on Windows - won't map to target or step through the listings

[smerriman]

I am working through the termmines tutorial in Ghidra's documentation and cannot get the debugger to work no matter what I try.

After creating a project and importing termmines.exe, I open the debugger, analyze the file (this shows me the static listing and decompiled code fine), and then connect to dbgeng locally IM-VM. I first get an error about the mapping not existing:

Have hunted through some past threads on this and saw recommendations about finding the process in the modules window, but there's only one thing in there and if I try mapping it, it doesn't help:

If I instead hit f5 / press the resume button in the Objects window, more things appear in the interpreter:

And then f5 again, a lot more:

Only now does termmines.exe open in a separate command prompt. While I can play the game, the resume / step into etc buttons are now all greyed out in the Objects window, and the dynamic window is showing some contents of ntdll.dll, so I can't use the debugger at all to see what's going on in the program itself.

Still nothing that looks like termmines.exe in the modules window either:

I feel like I must be missing something fundamental, and have been going through all past support threads, but haven't been able to find anything that has helped.

[smerriman]

OK, I think I might have finally been able to figure out my problem.

You do indeed need to map that image000... to the exe. And you'll also need to manually place a breakpoint at the start of the program's execution. And lastly, after you start the execution, you have to go back to that breakpoint and double click it to turn it on, since every single time you run it, it starts off in a disabled state.

A bit of a mess but hopefully this helps someone else..

[smerriman]

OK, a follow up question - while it's now stepping through fine, I'm unable to see the values of the majority of variables, as they're throwing IllegalArgumentExceptions:

Any suggestions?

[astrelsky]

@d-millar you might want to take a look at this.

[d-millar]

I think this might be one for @nsadeveloper789 - he designed this feature and was fixing related issues recently. @smerriman - what version of Ghidra are you running? I ask as I'm not seeing this behavior in master - will check 10.3.2, but am pretty sure there's already a fix in for this.

[smerriman]

I'm using 10.3.2.

[Nemoumbra]

I've got some questions too about this whole debugging stuff Ghidra can do. Excuse me, but what do you think of this error message?

The context: I'm exploring the possible debugging scenarios in my Windows Ghidra 10.3.2 and the first one is the gdb:

I enter my MinGW gdb path there and get this useless error message. Then I replace gdb.exe with lol.exe and the message remains the same. I highly doubt that's fine. Please tell me, what am I doing wrong?

[d-millar]

@Nemoumbra Hitting that "Details >>>" button and sending us the stack trace would be very very helpful.

[d-millar]

Also, this probably should be a new ticket as it does not appear to have anything to do with @smerriman's issue.

[Nemoumbra]

I suppose you're right. There is nothing interesting about the Details (and that's why I didn't include that info).

com.sun.jna.LastErrorException: GetLastError() returned 2
---------------------------------------------------
Build Date: 2023-Jul-11 1640 EDT
Ghidra Version: 10.3.2
Java Home: k:\Shared_storage\Data\JDK19\jdk-19.0.2
JVM Version: Oracle Corporation 19.0.2
OS: Windows 10 10.0 amd64

[Nemoumbra]

#5698
@d-millar

[d-millar]

Wow, ok - that is spectacularly uninformative. :)

The immediate thing that confuses me is the JNA error, given our implementation of the gdb agent doesn't use JNA directly. Any chance you could walk me through the exact steps you took? I.e. did Targets->Connect throw this error immediately? One thing to try for sure - try using double-slashes in your path (Java is not a fan of the backslash).

[d-millar]

@smerriman OK, spoke with @nsadeveloper789 - he confirmed this is a know issue. Basically, the fact that you're running a WOW target means that 32-bit registers are not being identified correctly in a 64-bit space. We have a ticket in to fix it - will keep you posted.