Closed AddioElectronics closed 8 months ago
@AddioElectronics On the "good" news front, I was able to reproduce your results exactly. Will need a bit of time to diagnose, but...working on it!
Haha that is good. You guys are quick.
I put in a fix for the second exception.
@dragonmacher thanks! @AddioElectronics I think I understand the problem, but I don't have a fix yet. (Got sidetracked by a different problem which you will hit after this one - more on that in a minute.) Am pretty sure the problem is that the version of dbgeng.dll (or possibly one of its dependencies, e.g. dbgcore.dll, dbghelp.dll, dbgmodel.dll) being used by your copy of windbg is not the same as the version loaded accessed via JNA by Ghidra. Working on how to fix that....
OK, this is not the end solution but, if you don't mind, maybe a test. Try running:
"C:\however_you_get_to\java.exe" -XX:+ShowCodeDetailsInExceptionMessages -XX:+IgnoreUnrecognizedVMOptions -Djava.system.class.loader=ghidra.GhidraClassLoader -Xshare:off -Dfile.encoding=UTF8 -Duser.country=US -Duser.language=en -Dsun.java2d.pmoffscreen=false -Dsun.java2d.xrender=true -Dsun.java2d.d3d=false -Xdock:name=Ghidra -Dvisualvm.display.name=Ghidra -Djna.library.path="C:\Program File (x86)\Windows Kits\10\Debugger\x64" -classpath "C:\however_you_get_to\ghidra\Ghidra\Framework\Utility\bin\main;\Framework Utility\bin\default" ghidra.Ghidra ghidra.GhidraRun
Note: the two "however_you_get_to"'s that you'll have to replace. You may also have to check the path used for jna.library.path - should be wherever windbg lives.
If this works, you'll still have a problem. When the Objects Tree populates, you'll get Debugger->Sessions->[0]->Processes and nothing more. Select "Processes" and hit the Refresh button in the upper right corner of that window.
Hmmmm, I keep thinking I can navigate a solution using -Djna.library.path but....I seemed destined for failure in that regard. Falling back to my stupid but generally functional solution:
(1) Figure out where your copies of "java.exe/javaw.exe" live. (2) Figure out where your copy of windbg lives. (3) Copy the five DLLs beginning with "dbg" (core/help/eng/model/CredentialProvider (if you have that)) from the directory where windbg lives to the directory where java & javaw live.
Oh, one more note, I would run the "MS dbgeng.dll (WinDbg)" version rather than the "MS dbgeng.dll (WinDbg) via GADP" version, as the latter adds one more level of indirection and one more chance to confuse dbgeng.dll versions. The only time you really need the GADP version is if you're running the Ghidra agent (not windbg) and Ghidra on separate machines. Am also assuming you really need the Ghidra<->windbg connection, i.e. windbg running independently, for some reason. If not, just leave the parameters for "MS dbgeng.dll (WinDbg)" as "none"/"none", and launch your target using "Objects"->"Launch" or "Launch (X)".
Hope this helps (a little).
Oops my bad! Didn't expect an update from you so soon. Its a bit late right now so I'll have to try that out tomorrow and get back to you on that.
Man that must be a headache having to deal with all these different versions.
The reason I've been trying to use GADP and not IN-VM like I was initially trying is because after the application starts, it calls into a library which then seems to get another application to end the process, and restarts it with different parameters, which ends the debugging session. Or at least that's what I think is happening, because when I monitor it with Process Explorer it shows up as a child to another application, with "random" as a parameter instead of the "-debug" I gave it.
Is there any way to attach to an already running process without GADP?
And thanks, I appreciate the help.
Well thanks a lot man, I got debugging working.
Not sure how I missed "Attach" in the objects panel before, but that was pretty much all I was missing. I had actually copied the DLLs already because I read a post you had made in another issue.
One question though, I tried running the command you suggested while I was trying to get things working, but wasn't able to run it due to missing the class loader. In "Ghidra\Framework\Utility" I am missing the bin folder. The only thing inside Utility is lib\, license.txt, and Module.manifest. So I'm just wondering if there is anything important in there that could cause any issues in the future?
Glad you got things working! Not near my computer at the moment but will check the "Ghidra\Framework\Utility" issue tomorrow. Looking at the path in my comments above, something definitely looks off. I may have messed things up copying the cmdline. Apologies!
One question though, I tried running the command you suggested while I was trying to get things working, but wasn't able to run it due to missing the class loader. In "Ghidra\Framework\Utility" I am missing the bin folder. The only thing inside Utility is lib, license.txt, and Module.manifest. So I'm just wondering if there is anything important in there that could cause any issues in the future?
This is because you are running out of a prebuilt Ghidra release, and @d-millar is running out of Eclipse in development mode.
@AddioElectronics My apologies - @ryanmkurtz is right on the mark there. The cmdline should have been more like:
"C:\Program Files\Java\jdk-17\bin\java" -Duser.home="your_home_dir" -Djava.system.class.loader=ghidra.GhidraClassLoader -Dfile.encoding=UTF8 -Duser.country=US -Duser.language=en -Duser.variant= -Dsun.java2d.opengl=false -Djna.library.path="C:\tmp" -Djava.library.path="C:\tmp" -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3 -Dcpu.core.limit= -Dcpu.core.override= -Dfont.size.override= -Djna.library.path="C:\Program File (x86)\Windows Kits\10\Debugger\x64" -Xshare:off -Dsun.java2d.d3d=false -Dlog4j.skipJansi=true -cp "C:\where_ghidra_lives\Ghidra\Framework\Utility\lib\Utility.jar" ghidra.Ghidra ghidra.GhidraRun
Ahh ok, that clears things up. Well thanks again man. Cheers!
Describe the bug When trying to connect to a local process via windbg, ghidra never finishes connecting. After clicking connect, the windbg console says ghidra has connected, but in ghidra all I get are a few messages in the debug console, and the options pane has a blue "Connecting..." label that never stops.
Edit: While writing this I decided to try one more time just to get a fresh output from the debug console to copy, so I restarted ghidra and windbg, and now I am getting an actual error message. I'm not sure why, but I didn't get the error message the first 5 times I tried, now it is happening every time.
Here is the debug console output
To Reproduce
I followed the instructions @d-millar provided here.
Screenshots![ghidra_windbg_gapd_error_01](https://github.com/NationalSecurityAgency/ghidra/assets/59629419/68e2bcc7-fbe9-407a-8159-621358abe9ea)
Environment (please complete the following information):
Additional context
Here is another error I got just as I was exporting the debug console as CSV. It still managed to export though. Hopefully it helps you guys.