Try to find a way to copy WinDbgX dbgeng's DLLs instead of legacy WinDbg

[0vercl0k]

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.

[GanbaruTobi]

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.

[GanbaruTobi]

When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:

[0vercl0k]

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 <#196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORIE7GGU6255VVFUELDYVOZR5AVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGA3TQNZZG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[GanbaruTobi]

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.

[0vercl0k]

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: [image: grafik] <https://private-user-images.githubusercontent.com/15239745/307625770-a0b164fd-9589-4846-ae2f-a2b6e0013617.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg5NzA3NzYsIm5iZiI6MTcwODk3MDQ3NiwicGF0aCI6Ii8xNTIzOTc0NS8zMDc2MjU3NzAtYTBiMTY0ZmQtOTU4OS00ODQ2LWFlMmYtYTJiNmUwMDEzNjE3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAyMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMjI2VDE4MDExNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWVlMThkYmU4MzcxZDQzMmY3YmI2OGEwOWYxZDljY2I5ZThlMjI3NDU3YzFhYTQwMjczYjdkNzNiYmNlZDhmYTUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.JoEmT9tTVFkUBOOIuCEiGLS4ikBTrf8KpUkWVFnEQuk> 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 <#196 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORPAUM5IY2DG3XNMTMTYVTE2VAVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUG44TKNZVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[wumb0]

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.