Refactor WinDbg install

[naacbin]

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! 🚀!

[Ana06]

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.

[naacbin]

Yes, I have tested locally strange...

[naacbin]

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

[Ana06]

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:

[Ana06]

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

[naacbin]

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.

[naacbin]

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

[naacbin]

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.

[Ana06]

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?

[naacbin]

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.

[Ana06]

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?

[naacbin]

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.

[Ana06]

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

[naacbin]

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

[Ana06]

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

[Ana06]

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

[naacbin]

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.

[naacbin]

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.

[Ana06]

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

[naacbin]

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

[Ana06]

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]

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]

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]

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.

[naacbin]

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

[naacbin]

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]

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]

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.

[Ana06]

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]

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
}

[Ana06]

@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]

@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. 😉