PowerShell

24
Jan
2020

Convert HRESULT to a human-friendly error (PowerShell)

In several places in Windows (but especially in functions and calls resolving around COM) the errors/warnings returned by Windows APIs are returned as 32-bit numbers HRESULT. The binary value of HRESULT adds a special meaning for certain bits, like information about the type of the error, origin and much more.

Let’s analyze an example value of HRESULT 0x800706BA, which may be also represented in decimal form –2147023174. When seeing that number being returned by the API, it is usually not quite clear what the actual error really is. Wikipedia has a really simple explanation of how the number is structured:

https://en.wikipedia.org/wiki/HRESULT

Based on the specification and a header file to find out the mappings between facilities and their identifiers, I created a simple PowerShell function, which – given a number representing HRESULT – returns a human-friendly structure. This way you can convert this:

0x800706BA

into this:

HResult : -2147023174
HResultHex : 0x800706BA
HResultBin : 10000000000001110000011010111010
Facility : FACILITY_WIN32
FacilityCode : 7
ErrorCode : 1722
IsFailure : True
Message : RPC server is unavailable
IsCustom : False
IsServerFailure : False

Much better, isnt’t it? Turns out, this particular HRESULT represents an error, code 1722 (RPC Server is unavailable. Some other information, including representation in different formats are also there.

The usage is simple as that:

 Get-ActualError 0x800706BA

and the full source code is available in the following gist:

https://gist.github.com/marcinotorowski/8c09fc556469b22a9df421be51e370b2

Posted by Marcin Otorowski in PowerShell, 1 comment
12
Jun
2019

Executing custom commands in MSIX context

Sometimes, for troubleshooting it may be necessary to invoke commands in the context of MSIX, so that all virtualized file and registry resources are available. There are three main use cases for it:

  1. Testing out whether the files and registry entries are visible inside the virtual package in the correct place as defined in the AppxManifest.xml.
  2. Testing out whether Modification Package correctly merges its VFS and virtual registry with the base package.
  3. Executing your app from the MSIX package with custom executables and/or parameters which are not necessarily exposed as entry points.

There exists a really useful PowerShell cmdlet which does the heavy lifting, the only thing the user has to do is to supply the right parameters. Its signature (from MSDN):

Invoke-CommandInDesktopPackage
      [-PackageFamilyName] <String>
      [-AppId] <String>
      [-Command] <String>
      [[-Args] <String>]
      [-PreventBreakaway]

Both PackageFamilyName and AppId are required, as well as the command to be executed. You can get the two values from another cmdlet Get-AppxPackage.

The command that is started in the “bubble” can be pretty much anything (it is validated before running), but some typical examples are:

  • cmd.exe
  • powershell.exe
  • regedit.exe
  • Executables being part of the package (indirectly)

For example, let’s execute a PowerShell session in MSIX container to verify the virtualized file structure.

Continue reading →
Posted by Marcin Otorowski in MSIX, PowerShell, 0 comments