Refactor WinDbg install #1058

naacbin · 2024-05-27T22:18:22Z

I rework WinDbg install to improve it (versioned + icon support #997)

Closes #997

Ana06

Thanks for working on this @naacbin. It is nice that the shortcut has the WinDbg icon! 🚀!

packages/windbg.vm/tools/chocolateyinstall.ps1

Ana06 · 2024-05-28T08:13:13Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+    $installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
+    $executablePath = Join-Path $installDir "DbgX.Shell.exe"


have you tested this code locally? I get an error when trying to run the shortcut:

The following code works:

Suggested change

$installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation

$executablePath = Join-Path $installDir "DbgX.Shell.exe"

$installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation

$iconLocation = Join-Path $installDir "DbgX.Shell.exe" -Resolve

$executablePath = "$(where.exe WinDbgX.exe)"

VM-Install-Shortcut -toolName $toolName -category $category -executablePath $executablePath -iconLocation $iconLocation -RunAsAdmin

Note I have also added a -Resolve to Join-Path to ensure the DbgX.Shell.exe exists.

Yes, I have tested locally strange...

How, did you test ? I have tried from Tools directory and the Windows bar, it seems to work. Maybe it was the RunAsAdmin that was needed. Can you try again ?

I have added the -Resolve parameter

I have tested the current code again. I install a package in an empty VM (setup as documented in the wiki) and double clicking the shortcut in the Tools directory shows the error:

Running DbgX.Shell.exe directly (without the shortcut) also shows the same error (even if run as admin).

Weird, the only difference between our setup is that my empty VM only has chocolatey, I don't have a snapshot with install.ps1 installed (yet). If I get some time, I will investigate on this, but anyway, your proposal seems to work for me too.

It seems that the CI of windows-2019 doesn't appreciate "$(where.exe WinDbgX.exe)".

Weird, the only difference between our setup is that my empty VM only has chocolatey, I don't have a snapshot with install.ps1 installed (yet).

After creating a snapshot as documented in the wiki but with my current VM (which is build 22621) it still works (without the where.exe. So the problem, comes from Windows version.

packages/windbg.vm/tools/chocolateyinstall.ps1

Ana06 · 2024-05-29T09:36:05Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+
+    $installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
+    $iconLocation  = Join-Path $installDir "DbgX.Shell.exe" -Resolve
+    $executablePath = "$(where.exe WinDbgX.exe)"


it seems like the windows-2019 run can't find WinDbgX.exe which likely mean it hasn't been installed... (likely it was also not working before, but we were not checking). The GH runner is using Windows 10.0.17763, locally I am using 10.0.19045 for testing.

Searching online about issues installing WinDbg, I see information about conflicts with the Windows Software Development Kit. For example: https://superuser.com/questions/1524982/windbg-repeatedly-downloads-but-doesnt-install. Maybe requiring windows-sdk-10.0 as dependency fixes the issue. 🤔

@mandiant/vms any other ideas how to fix this?

Unfortunately, I won't be able to test it myself as I don't have any Windows 10 VM and can't get one easily to test for now.

I have Windows 10, but newer than the one in GH actions and it works for me. I am also not sure how to get an older Windows 10 for local testing. We can use GH for testing by pushing new changes to this PR (or running the test in a fork to avoid the noise in the PR).

@mandiant/vms any ideas to fix or test this problem?

Searching online about issues installing WinDbg, I see information about conflicts with the Windows Software Development Kit. For example: https://superuser.com/questions/1524982/windbg-repeatedly-downloads-but-doesnt-install. Maybe requiring windows-sdk-10.0 as dependency fixes the issue. 🤔

I tried to add windows-sdk-10.0 as dependency but it still failed.

If we do not figure out what the issue is, we can keep running it as a console app with:

VM-Install-Shortcut -toolName $toolName -category $category -executablePath "start $toolName.exe" -consoleApp $true -runAsAdmin -iconLocation $iconLocation

@Ana06, I have tried another idea by catching the exception, it seems to work !

I do not like that we use $executablePath = Join-Path $installDir "DbgX.Shell.exe" as executing DbgX.Shell.exe does not work for me, so potentially this is broken for others too. I think without the start it should work and be equivalent to the code we had before:

VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -consoleApp $true -runAsAdmin -iconLocation $iconLocation

I have noticed I can't even accces C:\Program Files\WindowsApps\ where DbgX.Shell.exe is, likely why I can't execute it

I have noticed I can't even accces C:\Program Files\WindowsApps\ where DbgX.Shell.exe is, likely why I can't execute it

I don't think it's related, at least not directly. Since you should be able to accessC:\Program Files\WindowsApps\Microsoft.WinDbg_1.2402.24001.0_x64__8wekyb3d8bbwe. in my installation (which works with DbgX.Shell.exe) I don't have access to WinDbg either.

I do not like that we use $executablePath = Join-Path $installDir "DbgX.Shell.exe" as executing DbgX.Shell.exe does not work for me, so potentially this is broken for others too.

I only use it when which fails, so only for older versions of Windows 10, it seems. According to the current windbg.vm code, it shouldn't work for these older versions of Windows either because WinDbgX is hard-coded without VM-Assert-Path.

I think without the start it should work and be equivalent to the code we had before:

VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -consoleApp $true -runAsAdmin -iconLocation $iconLocation

If I do this, it will still not work for older versions of Windows 10, I think my solution might give it a chance to actually work.

packages/windbg.vm/tools/chocolateyinstall.ps1

Ana06 · 2024-06-18T10:58:19Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+        checksumType  = "sha256"
+        fileFullPath  = Join-Path ${Env:TEMP} "$toolName.msixbundle"
+    }
+    Get-ChocolateyWebFile @packageArgs


I think we should add a VM-Assert-Path $packageArgs.fileFullPath to ensure the file has been downloaded before installing it.

This is not necessary, as Get-ChocolateyWebFile will throw an error with "incorrect hash" if the file has not been downloaded.

Ana06 · 2024-06-18T11:02:14Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+
+    $installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
+    $iconLocation  = Join-Path $installDir "DbgX.Shell.exe" -Resolve
+    $executablePath = "$(where.exe WinDbgX.exe)"


I have noticed I can't even accces C:\Program Files\WindowsApps\ where DbgX.Shell.exe is, likely why I can't execute it

emtuls · 2024-06-26T01:20:29Z

So I'm looking into this and it looks like the same issue I ran into when I was trying to do the windows-terminal package for wt.exe (#934 (comment)) where it installed to the correct location for Windows Server 2022, but not for Windows Server 2019. Unfortunately, I never found a solution to do it properly for Windows Apps, and instead I went the route of using a Github package which doesn't seem to exist for WindbgX.

It seems that the Windows Server 2019 either installs the Windows Apps to a different location than the standard one (or installs it differently in general), or it's failing to install for some reason. But the fact that $iconLocation = Join-Path $installDir "DbgX.Shell.exe" -Resolve actually resolves leads me to believe that it is installing, just not how we expect.

Now the issue with not being able use DbgX.Shell.exe as the executable location is because it's in a highly protected folder, so @Ana06 is likely correct in that the shortcut to that as the executablePath in the catch statement is very unlikely to actually be working and I'm not sure if that's the route we want to take. There seems to be ways that we can possibly change the ownership of the directory and be able to potentially make it run, as noted here, but I don't think that's the best route.

I'm thinking that the better route might be what @Ana06 suggested with #1058 (comment) where we use a Console App, or an alternative that I think may be more suitable would be to just remove the Console App part:

VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin

In either case, the issue still remains that WinDbgX.exe may not actually be resolving, so it's possible that it does not -actually- work, but this is no different than what we currently have, just maybe slightly better to not run it as a console app, imo.

I will try to do a little more testing to see if I can find an alternative, but that's my current take at the moment. :)

emtuls · 2024-06-26T03:07:03Z

Judging from these posts, it sounds like the WinDbgX.exe and similar executables in Microsoft\WindowsApps are considered an "Execution Alias", which is not supported in Windows Server 2019 as noted here:
https://stackoverflow.com/questions/67495731/how-do-i-make-an-execution-alias-work-on-windows-server-2019
microsoftfeedback/WinDbg-Feedback#19 (comment)
This is why it's not created when we do Add-AppxPackage for the windows-2019 github runner.

A suggested alternative that may work for us would be to create a command similar to Explorer.Exe Shell:AppsFolder:<ApplicationID>!<AppID> which looks like it can potentially be done programmatically: https://www.andreasnick.com/106-starting-msix-and-appx-packages-with-powershell-from-the-command-line.html

Or a powershell command Invoke-CommandInDesktopPackage: https://learn.microsoft.com/en-us/powershell/module/appx/invoke-commandindesktoppackage?view=windowsserver2019-ps

I'm not sure what the best solution really is, but for it to truly work on Windows Server 2019 we'd likely need one of these options, as VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin is merely making a shortcut to something that may not actually be working. Unfortunately I do not have this sort of setup at the moment to test this.

I'd be willing to accept VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin, as it seems that there have not been any complaints as of yet for it.

@Ana06 thoughts?

emtuls · 2024-06-26T03:15:52Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+    if ($_.Exception.Message -match "INFO: Could not find files for the given pattern\(s\).")
+    {
+        $executablePath = Join-Path $installDir "DbgX.Shell.exe"
+        VM-Install-Shortcut -toolName $toolName -category $category -executablePath $executablePath -iconLocation $iconLocation -RunAsAdmin
+    }
+    else
+    {
+        VM-Write-Log-Exception $_
+    }


I'm not sure if this is the route we want to take, as noted in my comments on the PR.

I think our current route of just making a shortcut may be the better alternative for the moment, unless we want to take the time to properly test and confirm one of the possible working solutions I noted in my comments.

At least we need to continue on this error, or windows-2019 will fail on where.exe WinDbgX.exe.

naacbin · 2024-06-27T21:40:07Z

Now the issue with not being able use DbgX.Shell.exe as the executable location is because it's in a highly protected folder, so @Ana06 is likely correct in that the shortcut to that as the executablePath in the catch statement is very unlikely to actually be working and I'm not sure if that's the route we want to take. There seems to be ways that we can possibly change the ownership of the directory and be able to potentially make it run, as noted here, but I don't think that's the best route.

I don't think changing permission of the directory will solve anything, because on my side it's working with DbgX.Shell.exe without modifying the permission of the protected folder. However, I agree that it's unlikely to work on Windows Server 2019.

naacbin · 2024-06-27T21:41:54Z

I'd be willing to accept VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin, as it seems that there have not been any complaints as of yet for it.

So we merge this PR with the line provided and create an issue to find a better way with Explorer.Exe Shell:AppsFolder:<ApplicationID>!<AppID> or Invoke-CommandInDesktopPackage ?

d35ha · 2024-10-04T07:10:49Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+    Get-ChocolateyWebFile @packageArgs
+    Add-AppxPackage -Path $packageArgs.fileFullPath
+
+    $installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation


This normally resolves to %programfiles%\WindowsApps\xxx and %programfiles%\WindowsApps is a protected folder causing it to fail to execute DbgX.Shell.exe directly from it.

Modifying the owner and the access permissions fixes the problem, I'm not sure if it breaks any thing else though.

This is the error I got as well. @d35ha do you get the error for the icon or only when used as executable path?

d35ha · 2024-10-04T08:11:13Z

packages/windbg.vm/tools/chocolateyinstall.ps1

+
+    $installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
+    $iconLocation  = Join-Path $installDir "DbgX.Shell.exe" -Resolve
+    $executablePath = "$(where.exe WinDbgXA.exe)"


Actually where.exe doesn't throw exceptions, it returns 1 in case of failure and since $ErrorActionPreference is set to Stop; the non-zero return code is treated as an exception with the stderr as exception message.

It's a way better to use the powershell function Get-Command with the ErrorAction set to Continue and to check the returned path if empty or not instead of relying on exceptions.

It would be like this:

$executablePath = (Get-Command WinDbgXA.exe -ea 0).Path if (!$executablePath) { $executablePath = Join-Path $installDir DbgX.Shell.exe }

@d35ha your proposal could cause that $executablePath is set to Join-Path $installDir DbgX.Shell.exe which doesn't fail the package, but we know fails to open in Windows 10 because of being in a protected directory. This results in a broken shortcut without noticing during the installation, or am I missing something?

Ana06 · 2024-10-07T12:22:31Z

@naacbin sorry that it took that long to review the PR, I am not sure which the best solution is. @d35ha thanks for sharing your feedback, hopefully we can soon find a good solution. 😉

Ana06 requested changes May 28, 2024

View reviewed changes

naacbin force-pushed the windbg-install branch 2 times, most recently from 50b7c8b to 32e9234 Compare May 28, 2024 16:48

Ana06 reviewed May 29, 2024

View reviewed changes

naacbin force-pushed the windbg-install branch from df75318 to 889560b Compare June 7, 2024 08:56

naacbin mentioned this pull request Jun 11, 2024

Add Windows Time Travel Debugging Cli #965

Closed

Ana06 mentioned this pull request Jun 14, 2024

Add the Time Travel Debugging CLI package #1092

Merged

naacbin force-pushed the windbg-install branch 2 times, most recently from 9185d7d to dcc69b0 Compare June 14, 2024 18:25

emtuls requested a review from Ana06 June 14, 2024 21:57

Ana06 reviewed Jun 18, 2024

View reviewed changes

Refactor WinDbg install

aa25833

naacbin force-pushed the windbg-install branch from dcc69b0 to aa25833 Compare June 18, 2024 16:42

Ana06 requested a review from emtuls June 24, 2024 09:33

emtuls requested changes Jun 26, 2024

View reviewed changes

d35ha self-requested a review July 22, 2024 08:22

Ana06 assigned d35ha and naacbin Jul 25, 2024

Ana06 added this to the FLARE-VM 2024 Q3 milestone Aug 13, 2024

d35ha requested changes Oct 4, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor WinDbg install #1058

Refactor WinDbg install #1058

naacbin commented May 27, 2024 •

edited by Ana06

Loading

Ana06 left a comment

Ana06 May 28, 2024

naacbin May 28, 2024

naacbin May 28, 2024

Ana06 May 28, 2024

Ana06 May 28, 2024

naacbin May 28, 2024

naacbin May 28, 2024

naacbin May 28, 2024

Ana06 May 29, 2024

naacbin May 29, 2024

Ana06 Jun 3, 2024

naacbin Jun 7, 2024

Ana06 Jun 14, 2024

naacbin Jun 14, 2024

Ana06 Jun 18, 2024 •

edited

Loading

Ana06 Jun 18, 2024

naacbin Jun 18, 2024 •

edited

Loading

naacbin Jun 18, 2024

Ana06 Jun 18, 2024

naacbin Jun 18, 2024

Ana06 Jun 18, 2024

emtuls commented Jun 26, 2024 •

edited

Loading

emtuls commented Jun 26, 2024 •

edited

Loading

emtuls Jun 26, 2024

naacbin Jun 27, 2024

naacbin commented Jun 27, 2024

naacbin commented Jun 27, 2024

d35ha Oct 4, 2024

Ana06 Oct 7, 2024 •

edited

Loading

d35ha Oct 4, 2024

Ana06 Oct 7, 2024

Ana06 commented Oct 7, 2024

		$installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
		$executablePath = Join-Path $installDir "DbgX.Shell.exe"

Refactor WinDbg install #1058

Are you sure you want to change the base?

Refactor WinDbg install #1058

Conversation

naacbin commented May 27, 2024 • edited by Ana06 Loading

Ana06 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ana06 Jun 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naacbin Jun 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emtuls commented Jun 26, 2024 • edited Loading

emtuls commented Jun 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naacbin commented Jun 27, 2024

naacbin commented Jun 27, 2024

Choose a reason for hiding this comment

Ana06 Oct 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ana06 commented Oct 7, 2024

naacbin commented May 27, 2024 •

edited by Ana06

Loading

Ana06 Jun 18, 2024 •

edited

Loading

naacbin Jun 18, 2024 •

edited

Loading

emtuls commented Jun 26, 2024 •

edited

Loading

emtuls commented Jun 26, 2024 •

edited

Loading

Ana06 Oct 7, 2024 •

edited

Loading