Guía de solución de problemas de MSIX

En esta guía se describen los errores MSIX más comunes en la instalación, la firma, la entrega del instalador de aplicaciones, las dependencias que faltan y el comportamiento en tiempo de ejecución. Cada sección incluye el síntoma, la causa principal y la resolución.

Para obtener un registro completo de eventos de implementación, abra Visor de eventos y vaya a: Registros de aplicaciones y servicios → Microsoft → Windows → AppxDeployment-Server → Operativo

Errores de instalación

0x80070005: acceso denegado

Síntoma: Add-AppxPackage o se produce un error en el instalador de la aplicación con el código 0x80070005de error .

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Causas y correcciones:

Instalación de paquetes bloqueada porque la aplicación está en uso

Síntoma: una actualización, reparación, eliminación o reinstalación falla con ERROR_PACKAGES_IN_USE (0x80073D02). El mensaje de implementación indica que los recursos que modifica la operación están actualmente en uso.

Se aplica a: Windows 10 y versiones posteriores, Windows 11

MSIX no modifica un paquete mientras un proceso lo usa. Los archivos ejecutables y las DLL se pueden mapear en procesos en ejecución, y una aplicación puede tener operaciones activas de archivos, registro o comunicación entre procesos.

Corrección preferida: pida al usuario que cierre la aplicación de forma limpia antes de volver a intentar el despliegue. Compruebe si hay procesos, servicios o componentes fuera de proceso que usan el paquete.

Para la implementación desatendida, elija uno de los siguientes comportamientos.

Cerrar la aplicación de destino

Utilice -ForceTargetApplicationShutdown para finalizar los procesos asociados al paquete de destino, forzosamente si es necesario:

Add-AppxPackage -Path .\updated-app.msix -ForceTargetApplicationShutdown

La opción equivalente Windows.Management.Deployment es AddPackageOptions.ForceTargetAppShutdown.

Esta opción puede forzar el cierre de la aplicación si esta no se cierra. No use el apagado forzado cuando la aplicación pueda perder el trabajo no guardado o interrumpir una operación de larga duración.

Aplazar el registro hasta que deje de estar en uso el paquete

Utilice -DeferRegistrationWhenPackagesAreInUse para preparar la actualización y aplazar el registro:

Add-AppxPackage -Path .\updated-app.msix -DeferRegistrationWhenPackagesAreInUse

La API equivalente es AddPackageOptions.DeferRegistrationWhenPackagesAreInUse. Windows completa el registro cuando el paquete se puede actualizar, por ejemplo durante una activación posterior.

En Windows 11, versión 24H2 y posteriores, un paquete puede declarar el uap17:UpdateWhileInUse elemento de manifiesto con un valor de defer. Esta configuración de nivel de paquete tiene prioridad sobre las opciones de apagado forzado. Consulte uap17:UpdateWhileInUse.

Las aplicaciones que utilicen el SDK de Aplicaciones de Windows pueden llamar a PackageDeploymentManager.IsPackageRegistrationPending para detectar un registro aplazado anteriormente para el usuario actual. Un administrador puede llamar a IsPackageRegistrationPendingForUser para comprobar el estado de otro usuario.

Aplazar la eliminación de paquetes

La eliminación normalmente solicita el cierre de la aplicación. Para aplazar la eliminación en su lugar, llame a PackageManager.RemovePackageAsync con RemovalOptions.DeferRemovalWhenPackagesAreInUse.

En el caso de las implementaciones empresariales, programe actualizaciones disruptivas durante las ventanas de mantenimiento y seleccione una directiva de aplazamiento o apagado que coincida con el riesgo de pérdida de datos de la aplicación. Para obtener más información, consulte Servicing While In Use y ERROR_PACKAGES_IN_USE.

Discrepancia de MinVersion o de arquitectura

Symptom: Se produce un error de instalación como "No se pudo instalar el paquete porque no es compatible con esta versión de Windows" o "El paquete no es aplicable a esta máquina".

Aplicable a: Windows 10 y versiones más recientes

Causas y correcciones:

Add-AppxPackage se ejecuta correctamente, pero falta la aplicación en el menú Inicio

Síntoma: PowerShell informa de éxito, pero la aplicación no aparece en el menú de inicio o la lista de aplicaciones.

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Causas comunes:

• Instalación por usuario frente a por máquina: Add-AppxPackage solo se instala para el usuario actual. Si se está ejecutando como administrador pero espera la aplicación para otro usuario, utilice Add-AppxProvisionedPackage en su lugar.
• Paquete registrado pero icono no anclado: la aplicación está instalada, pero el menú Inicio no se ha actualizado. Cierre la sesión y vuelva a iniciar sesión o active Configuración → Aplicaciones para confirmar la instalación.
• Falta la entrada menú Inicio en el manifiesto: compruebe que el <Application> elemento de AppxManifest.xml incluye una VisualElements entrada con un valor válido Square150x150Logo.
• Conflicto de nombre de familia de paquete duplicado: si ya hay instalada una versión más reciente o anterior de la aplicación con el mismo nombre de familia de paquete, la nueva instalación puede reemplazarla de forma silenciosa. Consulte con Get-AppxPackage -Name "YourPackageFamilyName".

Errores de firma y certificado

Certificado no confiable (0x800B0109)

Síntoma: se produce un error 0x800B0109 en la instalación: "Una cadena de certificados procesada, pero terminada en un certificado raíz que no es de confianza para el proveedor de confianza".

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Causa: el certificado usado para firmar el paquete no está en los almacenes de certificados de confianza del dispositivo. Esto es habitual cuando se usan certificados autofirmados para el desarrollo.

Corrección: Importe el certificado de firma en el equipo local del dispositivo → almacén de personas de confianza (no en el almacén de usuarios actual: el Instalador de aplicaciones solo comprueba el almacén de máquinas):

# Export the certificate from the package first (if needed)
$cert = (Get-AuthenticodeSignature -FilePath .\app.msix).SignerCertificate
Export-Certificate -Cert $cert -FilePath .\app-cert.cer

# Import into Trusted People (requires administrator rights)
Import-Certificate -FilePath .\app-cert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

En el caso de las aplicaciones de producción, use un certificado emitido por una autoridad de certificación de confianza o Azure Artifact Signing (anteriormente Trusted Signing), que se encadena a la entidad de certificación raíz de comprobación de identidades de Microsoft — confiable por defecto en Windows 10 versión 1809 y posteriores, Windows 11.

Discrepancia del nombre del editor (0x8007000B, Id. de evento 150)

Síntoma: SignTool produce un error 0x8007000B y Visor de eventos (registro operativo AppxPackagingOM) muestra Event ID 150:

error 0x8007000B: The app manifest publisher name (CN=Contoso) must match
the subject name of the signing certificate (CN=Contoso, C=US).

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Cause: El atributo Publisher en AppxManifest.xml debe coincidir exactamente con el nombre subject del certificado de firma, incluidos todos los campos de nombre distintivos en el mismo orden.

Corrección:

1. Obtenga el nombre exacto del firmante del certificado:

   (Get-Item Cert:\CurrentUser\My\THUMBPRINT).Subject
   # Example output: CN=Contoso, C=US
   

2. Actualice AppxManifest.xml para que coincida exactamente:

   <Identity Name="Contoso.MyApp"
             Publisher="CN=Contoso, C=US"
             ... />
   

3. Vuelva a empaquetar con MakeAppx.exe y vuelva a firmar.

Errores del instalador de aplicaciones y de entrega web

Desajuste de versión del esquema en el archivo .appinstaller

Síntoma: el Instalador de la aplicación no puede analizar o procesar el .appinstaller archivo, a menudo con un error genérico sobre un archivo no válido o un esquema no admitido.

Applies to: Windows 10 y versiones posteriores (dependientes de la versión; consulte la tabla)

Cause: el atributo Uri del elemento raíz <AppInstaller> especifica una versión de esquema que la versión instalada de Windows no admite.

Versiones del esquema por versión de Windows:

Corrección: establezca el URI del esquema en su archivo .appinstaller en la versión mínima que requiera su sistema operativo compatible más bajo:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://example.com/app.appinstaller"
              Version="1.0.0.0"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2017">

Evite usar la versión de esquema más reciente si necesita admitir versiones anteriores de Windows 10.

Archivos servidos con un tipo MIME incorrecto o falta content-Length

Síntoma: se produce un error en el instalador de la aplicación al instalar desde un punto de conexión HTTP/HTTPS. El error puede ser genérico, como 0x80072F76 ("Error desconocido") o "Error de instalación de la aplicación".

Aplicable a: Windows 10 y versiones más recientes

Causa: el servidor web está sirviendo el archivo .msix, el archivo .msixbundle o el archivo .appinstaller con un encabezado Content-Type incorrecto u omitiendo el encabezado Content-Length.

Corrección: configure el servidor web para proporcionar archivos relacionados con MSIX con los tipos MIME correctos:

Asegúrese también de que todas las respuestas incluyan un encabezado válido Content-Length ; esto se aplica a las GET solicitudes y HEAD .

Para IIS, agregue asignaciones de tipos MIME en web.config. Para Azure Static Web Apps o GitHub Pages, los tipos MIME para estas extensiones pueden necesitar una configuración explícita o una solución de hospedaje personalizada.

Dependencias faltantes

Paquete de marco no instalado (VCLibs, .NET, SDK de Aplicaciones para Windows)

Symptom: la aplicación se instala correctamente, pero se bloquea al iniciarse, o se produce un error de dependencia que hace referencia a un nombre de familia de paquete como Microsoft.VCLibs, Microsoft.WindowsAppRuntime o Microsoft.NET.Native.

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Marcos comunes y dónde obtenerlos:

Corrección para el desarrollo: al instalar a través de Add-AppxPackage localmente, agregue el -DependencyPackages parámetro o instale primero los paquetes del framework:

# Install VCLibs dependency first
Add-AppxPackage -Path .\Microsoft.VCLibs.x64.14.00.Desktop.appx

# Then install your app
Add-AppxPackage -Path .\MyApp.msix

Corrección para la distribución: si distribuye fuera de la Store, incluya los paquetes de marco de trabajo en su archivo .appinstaller en <Dependencies>:

<Dependencies>
  <Package Name="Microsoft.VCLibs.140.00.UWPDesktop"
           Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
           Version="14.0.30704.0"
           Uri="https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx"
           ProcessorArchitecture="x64"/>
</Dependencies>

SignTool no se encuentra en CI/CD

Síntoma: la canalización de CI/CD (Acciones de GitHub, Azure DevOps) falla con un error como 'signtool' is not recognized as an internal or external command o SignTool.exe: not found.

Applies to: Windows 10 y versiones posteriores, Windows 11 (máquina de firma)

Cause: SignTool forma parte del SDK de Windows y no se incluye en imágenes de ejecutor de CI estándar de forma predeterminada.

Fixes:

Opción 1 — Instalar el SDK de Windows en la canalización (Acciones de GitHub):

- name: Install Windows SDK
  run: |
    winget install --id Microsoft.WindowsSDK.10.0.22621 --accept-source-agreements --accept-package-agreements

Opción 2: Usar la CLI de WinApp (más sencilla para la firma MSIX):

- name: Install WinApp CLI
  run: winget install -e --id Microsoft.WinAppCLI --source winget --accept-source-agreements
- name: Sign MSIX
  run: winapp sign output\MyApp.msix --cert ${{ secrets.CERT_THUMBPRINT }}

Opción 3 — Usar Azure Artifact Signing (recomendado para producción):

- name: Sign with Azure Artifact Signing
  uses: azure/trusted-signing-action@v0
  with:
    azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
    azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
    endpoint: ${{ secrets.AZURE_ARTIFACT_SIGNING_ENDPOINT }}
    trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    files-folder: ${{ github.workspace }}\output
    files-folder-filter: msix

Para ver un tutorial completo sobre la configuración de la firma de CI/CD, consulte Sign your MSIX package - end-to-end guide (Firmar el paquete MSIX: guía de un extremo a otro).

Comportamiento de tiempo de ejecución y virtualización

Los paquetes MSIX se ejecutan dentro de un contenedor de aplicaciones ligero. Algunos comportamientos que parecen ser errores son realmente por diseño: el contenedor intercepta las operaciones de archivo y registro para proteger el resto del sistema.

Por qué las escrituras de archivos parecen desaparecer (redireccionamiento de archivos VFS)

Síntoma: la aplicación escribe un archivo en una ruta de acceso como C:\Program Files\MyApp\config.ini en tiempo de ejecución, pero el archivo no aparece allí. La aplicación lee el valor correctamente, pero otros procesos o usuarios no lo ven.

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Explicación: MSIX usa el redireccionamiento del sistema de archivos virtual (VFS). Las escrituras en las rutas del sistema protegidas se redirigen silenciosamente a un contenedor por usuario:

%LocalAppData%\Packages\<PackageFamilyName>\LocalCache\Local\VFS\

Esto es así por diseño: impide que las aplicaciones MSIX modifiquen las ubicaciones del sistema compartidas, lo que admite la desinstalación limpia.

Opciones:

• Use carpetas de datos de la aplicación en su lugar: escriba en ApplicationData.Current.LocalFolder (WinRT) o %LocalAppData%\Packages\<PFN>\LocalState\ para los datos por usuario que deben conservarse.
• Uso AppData\Roaming para los datos que deben desplazarse entre dispositivos.
• Inspeccione el contenedor VFS para ver los archivos redirigidos: %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

Para obtener más información sobre las rutas de acceso virtualizadas, consulte Solución de problemas en tiempo de ejecución en un contenedor MSIX.

¿Por qué las escrituras del registro parecen desaparecer (virtualización del registro)

Síntoma: la aplicación escribe en HKEY_LOCAL_MACHINE\Software\MyApp\ en tiempo de ejecución, pero el valor no es visible para otros procesos ni sobrevive a una reinstalación.

Se aplica a: Windows 10 y versiones posteriores, Windows 11

Explicación: MSIX intercepta las escrituras en HKLM\Software y las redirige a un subárbol del registro por paquete que está aislado del resto del sistema. Al desinstalar, la colmena se elimina.

Opciones:

• Escriba la configuración por usuario en HKEY_CURRENT_USER\Software\<AppName>; estas no se virtualizan y persisten.
• Use las API Windows ApplicationData para el almacenamiento de configuración estructurado.
• Declare las entradas del registro que se deben compartir entre usuarios o procesos mediante el AppxManifest.xml<Extensions> / <com:Extension> mecanismo.

Para obtener un vistazo más profundo al comportamiento del contenedor MSIX, consulte Introducción a la ejecución de aplicaciones de escritorio empaquetadas en Windows.

Limitaciones de MSIX en Windows 10

Algunas características de MSIX requieren Windows 11 o una versión de Windows 10 específica. Si va a implementar en dispositivos Windows 10, tenga en cuenta lo siguiente.

Características que requieren Windows 10, versión 2004 (compilación 19041) o posterior

Características que requieren Windows 11

Windows 10 dispositivos anteriores a la versión 1709

MSIX no se admite de forma nativa en Windows 10 versiones anteriores a la 1709 (Fall Creators Update). Para implementar paquetes MSIX en esos dispositivos, use MSIX Core, que proporciona una capa de compatibilidad para versiones de Windows 10 de nivel inferior.

Extensiones de manifiesto

Algunas extensiones de espacio de nombres AppxManifest.xml son solo para Windows 11. Declararlos en un paquete que tenga como destino Windows 10 puede producir un error en la validación del esquema durante el empaquetado o rechazarse durante la instalación. Compruebe la referencia del esquema de manifiesto del paquete de aplicación para la MinOSVersion indicada para cada extensión.

Sugerencia de depuración

Para comprobar qué características de MSIX están disponibles en una compilación de Windows 10 específica, consulte la página MSIX y las plataformas compatibles, que enumera la disponibilidad de características por versión del sistema operativo.

Recursos relacionados

• Descripción general de la firma de un paquete MSIX
• Firmar el paquete MSIX: guía completa
• Problemas conocidos y solución de problemas de SignTool
• Solución de problemas del instalador de aplicaciones
• Solución de problemas en tiempo de ejecución en un contenedor MSIX
• Solución de problemas de empaquetado, despliegue y consulta de aplicaciones de Windows