Windows Debugger fails to launch with no terminal output, GetLastError 193

[CarePackage17]

Trying to launch a debugging session with dbgeng and it immediately fails with no output whatsoever on the terminal. Python 3.9.13 is installed via MS store and on PATH. Error 193 is ERROR_BAD_EXE_FORMAT, which doesn't make sense at first, unless...

My username has a space inside and whoever is handling paths for launching stuff doesn't like that, as after copying ghidra to another location without spaces and trying again I get at least a python stacktrace (might have missing dependencies).

To Reproduce Steps to reproduce the behavior:

1. Copy your Ghidra installation to a path with a space
2. Open an imported executable in the debugger tool
3. Launch using dbgeng
4. Get error 193 without any output

Expected behavior The debugger launching (or at least getting meaningful debug output)

Environment (please complete the following information):

• OS: Windows 10 19045.4894
• Java Version: Microsoft jdk-21.0.4.7-hotspot
• Ghidra Version: 11.2
• Ghidra Origin: GitHub

[d-millar]

@CarePackage17 Trying to recreate your issue, but having no real success. I launched git-bash.exe from dbgeng (traceRMI/python interface, not IN-VM) successfully - path includes "Program Files" and I left the path as loaded from the file browser, i.e. nothing escaped, no extra quotes. Any chance you could provide more details? Also, maybe, see if you have the same issue running something mundane.

[CarePackage17]

Maybe it's not any space in the path, but the username specifically (in my case).

I can repro this again, is there any useful logs you need and where do I find them?

[d-millar]

Re logs, anything that shows up in the Debug Console might help. If you run in debug mode (i.e. start with support/ghidraDebug vs.ghidraRun, anything that looks like an error in the console might help. And there is a log file for the debugger that’s generated (called something like debug.log?) but I’ll have check to see where that gets dropped.

[nsadeveloper789]

There's no longer a debugger-specific log file. (There used to be one that showed the GDB/MI conversation, but that was for gdb only.) Instead, the Terminal window may have important warning/error messages. Sounds like it didn't even get that far, though. I'd say, in the launch options, where it asks for your Python command/path, double-check that it's actually an executable file (PE, and not, say, a shell script.) IINM, Ghidra will also implicitly run cmd.exe to invoke the launcher batch script. I wouldn't think that's the problem, but you might check that the cmd on your PATH is in fact the usual Windows command prompt. Last is perhaps the .bat file is somehow corrupt. It should be at Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/local-dbgeng.bat (my memory may be fuzzy). Maybe check that it has CRLF and not just LF line endings? (Some of these ideas are real flimsy, I know, just trying to brainstorm a bit.)

[CarePackage17]

I checked the line endings, they're CRLF as expected.

My python command works fine when used in cmd or wherever, but I think it's a sort of redirect to the proper thing (command execution alias, because MS store installed python does that and you can have multiple versions installed).

That OPT_PYTHON env var the batch script uses, where is it set?

[d-millar]

Re OPT_PYTHON: when you use any of the launchers from the toolbar, e.g. dbgeng, the launcher with that title get selected, e.g. local-dbgeng.bat. The @env items in that launcher are used to populate the dialog that comes up. In the case of OPT_PYTHON_EXE, the value from the dialog is then executed immediately by the .bat.

[CarePackage17]

I got a stack trace via the Inspect Error window:

GetLastError() returned 193
com.sun.jna.LastErrorException: GetLastError() returned 193
    at ghidra.pty.windows.ConPtyChild.session(ConPtyChild.java:108)
    at ghidra.pty.windows.ConPtyChild.session(ConPtyChild.java:36)
    at ghidra.pty.PtyChild.session(PtyChild.java:68)
    at ghidra.app.plugin.core.debug.gui.tracermi.launcher.AbstractTraceRmiLaunchOffer.runInTerminal(AbstractTraceRmiLaunchOffer.java:485)
    at ghidra.app.plugin.core.debug.gui.tracermi.launcher.AbstractScriptTraceRmiLaunchOffer.launchBackEnd(AbstractScriptTraceRmiLaunchOffer.java:123)
    at ghidra.app.plugin.core.debug.gui.tracermi.launcher.AbstractTraceRmiLaunchOffer.launchProgram(AbstractTraceRmiLaunchOffer.java:649)
    at ghidra.app.plugin.core.debug.gui.tracermi.launcher.TraceRmiLauncherServicePlugin$ConfigureAndLaunchTask.run(TraceRmiLauncherServicePlugin.java:123)
    at ghidra.app.services.ProgressService.lambda$execute$0(ProgressService.java:123)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)

---------------------------------------------------
Build Date: 2024-Sep-26 1444 EDT
Ghidra Version: 11.2
Java Home: C:\Program Files\Microsoft\jdk-21.0.4.7-hotspot
JVM Version: Microsoft 21.0.4
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-58OMEIQ

Looks like the terminal setup code does something weird. Here's the line for reference.

I did make a procmon trace of the failing case and it starts conhost.exe from System32, no errors there at first sight, it just closes immediately. Not sure how we end up with error 193 of all things.

[d-millar]

OK, going to suggest one more test - apologies if I've already suggested this or you've already tried it:

(1) As before, use "Configure and Launch..." -> dbgeng to bring up the "Launch with dbgeng (in a Python Interpreter)" dialog (2) For "Image", use "C:\Windows\notepad.exe". Unselect "dbgmodel". Make sure "Arguments" and "Path to dbgeng.dll directory" are empty. Tell us what you have in "Python command". (I am using "py", which uses the default $PATH variable to find "C:\Windows\py.exe".

Does this fail with 193? My reason for suggesting this test: the place where you are failing basically uses none of the information in the dialog. This is an attempt to launch "local-dbgeng.bat", albeit with a bunch of other args and parameters, but putting junk in these fields will not cause the process to fail at that location. The only things, as far as I can see, that would cause a failure at that location are (1) local-dbgeng.bat has been corrupted in some way, (2) your system path is pointing to a missing or corrupt version of Kernel32.dll, or (3) the executable being used for "Python Command" is something odd. I feel like (1) and (2) are unlikely and/or would be obvious in other ways.

I have tested with various forms of garbage for the python executable, but haven't managed to come up with a 193 yet. For instance, pointing at, say, desktop.ini launches it as a .ini, or renaming desktop.ini to python.exe returns GetLastError=5.