Try to find a way to copy WinDbgX dbgeng's DLLs instead of legacy WinDbg
0vercl0k opened this issue · comments
Currently, wtf
tries to find the dbgeng.dll
DLLs in a path where the WinDbg that ships with the SDK is (cf https://github.com/0vercl0k/wtf/blob/main/src/wtf/debugger.h#L139).
This is problematic for users when they use the 'new WinDbg' to generate a dump file which is in a format that the WinDbg from the SDK doesn't understand. Those users see the below error message which is confusing:
Initializing the debugger instance.. (this takes a bit of time)
OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9
Fixing it manually require to grab the dbgeng.dll
& cie and copy them over where wtf
is but it is manual.
In theory if I find a way to detect if the WinDbg from the AppStore is installed and where, using those DLLs would always work as they'd be able to load dumps generated from old WinDbg, and the new ones. The issues that I have are:
- I do not know how to detect if the application is installed
- Even if I figure out how to get the path, it seems that you need some special rights to copy the files out of the directory which is annoying.
I guess if 1) is solved, we could try to copy the files for the users and if we fail we could tell them to copy the files over themselves or run as admin.
Detect if the App is installed in PowerShell:
Get-AppxPackage -AllUsers | Select-Object -ExpandProperty PackageFullName | Where-Object { $_ -like 'windbg' }
To copy the files into another directory:
robocopy "C:\Program Files\WindowsApps\FOUND_NAME_HERE" windbg_app /s /e
Then probably its needed to identify if x86 or x64 or arm. In my case
C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\dbgeng.dll has the dll I need.