Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor WinDbg install #1058

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Refactor WinDbg install #1058

wants to merge 1 commit into from

Conversation

naacbin
Copy link
Collaborator

@naacbin naacbin commented May 27, 2024

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

Closes #997

Copy link
Member

@Ana06 Ana06 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

packages/windbg.vm/tools/chocolateyinstall.ps1 Outdated Show resolved Hide resolved
Comment on lines 21 to 22
$installDir = (Get-AppxPackage -Name "Microsoft.$toolName").InstallLocation
$executablePath = Join-Path $installDir "DbgX.Shell.exe"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I have tested locally strange...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
@naacbin naacbin force-pushed the windbg-install branch 2 times, most recently from 50b7c8b to 32e9234 Compare May 28, 2024 16:48

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@Ana06 Ana06 Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

image

Copy link
Collaborator Author

@naacbin naacbin Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
checksumType = "sha256"
fileFullPath = Join-Path ${Env:TEMP} "$toolName.msixbundle"
}
Get-ChocolateyWebFile @packageArgs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

image

@emtuls
Copy link
Member

emtuls commented Jun 26, 2024

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
Copy link
Member

emtuls commented Jun 26, 2024

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?

Comment on lines +26 to +34
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 $_
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@naacbin
Copy link
Collaborator Author

naacbin commented Jun 27, 2024

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
Copy link
Collaborator Author

naacbin commented Jun 27, 2024

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 d35ha self-requested a review July 22, 2024 08:22
@Ana06 Ana06 added this to the FLARE-VM 2024 Q3 milestone Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Simplify Windbg code && fix icon
4 participants