Find MSIX Package Name and AUMID From a Running Process Using TASKLIST and PowerShell

This is a procedure for developers and admins, not a new Windows feature. It is still useful when you're debugging a packaged app, writing an app-control rule, or working out whether a process runs with package identity at all.

Two identifiers, two tools​

A packaged process carries two related identities:

• Package full name: the complete package identity string. It includes the version, architecture and publisher ID, for example Microsoft.AzureVpn_4.0.5.0_x64__8wekyb3d8bbwe.
• Application User Model ID (AUMID): the identity of a specific app inside a package, for example Microsoft.AzureVpn_8wekyb3d8bbwe!App. It pairs the package family with an app ID.

TASKLIST gives you the first. PowerShell and the Windows package-query APIs give you both.

Step 1: TASKLIST /APPS​

Kapustein's running example is the packaged app AzVpnSysTrayApp.exe, with process ID (PID) 7664. His earlier posts in the series cover how that PID was found.

TASKLIST /APPS lists packaged processes with these columns:

• Image Name
• PID
• Mem Usage
• Package Name

The /APPS switch is not new. Winhelponline's older walkthrough says it works in Windows 8.1 and higher.

Output for every packaged process is a lot of noise when you want one app. Add a filter:

TASKLIST /APPS /FI "PID eq 7664"

You can also filter by executable name:

TASKLIST /APPS /FI "IMAGENAME eq AzVpnSysTrayApp.exe"

Both queries return the same process in the post. The sample shows AzVpnSysTrayApp.exe (App), PID 7664, and the package Microsoft.AzureVpn_4.0.5.0_x64__8wekyb3d8bbwe. The two samples show slightly different memory figures, 33,004 K and 33,008 K. These are just separate runs. The post doesn't treat the difference as meaningful.

The key detail is that the Package Name column is the package full name, not the short package name. In the post's example, the Calculator row's package name is cut off in the console. If you need the whole string, filter down to one process or use /FO LIST. Winhelponline documents that format switch for /apps.

Step 2: PowerShell for the AUMID​

TASKLIST doesn't show the AUMID. The post's workaround is a script, Get-Identity.ps1, that takes a PID and calls the package-query functions through P/Invoke. P/Invoke lets PowerShell call native Windows APIs through C# type definitions compiled with Add-Type.

What the script does​

1. It takes a mandatory integer ProcessId, turns on strict mode, and sets errors to stop.
2. It declares OpenProcess, CloseHandle, GetPackageFullName and GetApplicationUserModelId from kernel32.dll.
3. It opens the target process with PROCESS_QUERY_LIMITED_INFORMATION (0x1000) and no handle inheritance.
4. It calls GetPackageFullName with a 128-character buffer. That is the documented 127-character maximum plus the null terminator.
5. If a package is found, it calls GetApplicationUserModelId with a 130-character buffer.
6. It returns an object with PID, ImageName, PackageFullName and ApplicationUserModelId.
7. A finally block always closes the process handle.

You run it like this:

pwsh -c .\Get-Identity.ps1 7664

The post's sample result:

The example invokes pwsh, which is PowerShell 7. The post doesn't say whether Windows PowerShell 5.1 would also work, so I won't claim it does.

What the results mean​

The script treats "no identity" as a normal outcome and not as an error:

• Error 15700 (APPMODEL_ERROR_NO_PACKAGE): the process has no package identity. The script returns the PID and process name, with null package and AUMID fields.
• Error 15703 (APPMODEL_ERROR_NO_APPLICATION): the process has package identity but no application identity. The script returns the package full name and a null AUMID.
• Any other non-zero code: the script writes a warning with the PID and the numeric error, then returns nothing.

Microsoft Learn's reference pages for the two functions say the same thing. APPMODEL_ERROR_NO_PACKAGE is not documented there, but the Learn pages for GetPackageFullName and GetApplicationUserModelId describe these two return codes. They also describe ERROR_INSUFFICIENT_BUFFER, which the script never has to handle because it preallocates maximum-size buffers.

Practical caveats​

• The process must be running and reachable. Both queries need a handle to a live process. If OpenProcess fails, the script only warns "Failed to open process". It doesn't show the underlying Windows error. A failure to open a process does not mean the app is unpackaged. It could be a permissions problem or a process that has already exited. Microsoft's C examples on Learn print GetLastError in that case, and the blog script doesn't.
• PIDs change. The 7664 in the example belongs to that machine and that session. Look up the current PID each time, for instance with TASKLIST /APPS /FI "IMAGENAME eq yourapp.exe".
• Don't treat the Azure VPN values as universal. The version number and memory figures are sample output from the author's system. Your package version may differ.
• Version scope. Learn lists GetPackageFullName as available from Windows 8 and Windows Server 2012, as desktop-app APIs. GetApplicationUserModelId has no minimum-version row in the Learn page I reviewed.

Why this matters​

Package full names and AUMIDs turn up in many admin tasks. Package family names drive app-control rules. Microsoft's guidance on managing packaged apps with App Control for Business says you must choose between signer rules or Package Family Name (PFN) rules. AUMIDs also come up when you work with notifications and shell activation. Being able to read these values from a live process means you don't have to guess from a Start menu entry.

If you only need to know whether a process is packaged and which package it belongs to, TASKLIST /APPS with a filter does the job. If you need the AUMID too, or a scriptable object you can pipe elsewhere, the PowerShell script covers it with no compiler or SDK.

This is also the third entry in a short series. The earlier posts, dated September 29 and October 6, 2026, cover how to tell if a process is packaged and how to find package identity with APIs. Part 3 is the shell-friendly version of those two.

Bottom line​

• TASKLIST /APPS /FI "PID eq <pid>" shows the package full name under the "Package Name" heading.
• It does not show the AUMID.
• The Get-Identity.ps1 approach calls GetPackageFullName and GetApplicationUserModelId and returns both values.
• Null values in the output tell you whether the process is unpackaged (15700) or packaged without application identity (15703).
• Open-process failures are reported only as a warning, so check permissions and process lifetime before drawing conclusions.