Open 0vercl0k opened 8 months ago
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.
When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:
Hmmm that would be a bug - let me check this tonight.
Cheers
On Sun, Feb 25, 2024 at 2:13 PM Tobias Mayer @.***> wrote:
When I place the found dll's into the wtf.exe directory, it will overwrite them with the SDK's:
grafik.png (view on web) https://github.com/0vercl0k/wtf/assets/15239745/a0b164fd-9589-4846-ae2f-a2b6e0013617
— Reply to this email directly, view it on GitHub https://github.com/0vercl0k/wtf/issues/196#issuecomment-1963078797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALIORIE7GGU6255VVFUELDYVOZR5AVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGA3TQNZZG4 . You are receiving this because you authored the thread.Message ID: @.***>
When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:
Okey, in a second test this did not happen, and the source code looks good to me. Might have been a random thing to happen or I did something wrong.
All right cool, that's good to know - thank you for checking it!
Cheers
On Mon, Feb 26, 2024 at 10:02 AM Tobias Mayer @.***> wrote:
When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:
Okey, in a second test this did not happen, and the source code looks good to me. Might have been a random thing to happen or I did something wrong.
— Reply to this email directly, view it on GitHub https://github.com/0vercl0k/wtf/issues/196#issuecomment-1964795759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALIORPAUM5IY2DG3XNMTMTYVTE2VAVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUG44TKNZVHE . You are receiving this because you authored the thread.Message ID: @.***>
Perhaps it would be useful to add some metadata to a state capture (via snapshot) that indicates the exact dbgeng version being used. If a different version is found by wtf when starting to fuzz then emit a warning. I don't know how granular the reported version of dbgeng is in the extension APIs, but I guess you can just use GetFileVersionInfo
on the loaded dbgeng.dll in both snapshot and wtf.
Currently,
wtf
tries to find thedbgeng.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:
Fixing it manually require to grab the
dbgeng.dll
& cie and copy them over wherewtf
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 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.