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: se produce un error al actualizar o volver a instalarse, lo que indica que el paquete está en uso. En Visor de eventos, verá que se rechazó la operación de implementación.

Applies to: Windows 10 y versiones posteriores, Windows 11

Corrección: cierre todas las instancias en ejecución de la aplicación antes de actualizarla. Si la aplicación es un servicio en segundo plano o tiene registrada una tarea en segundo plano, es posible que tenga que finalizarlas también:

Get-Process -Name "MyApp" | Stop-Process -Force
Add-AppxPackage -Path .\updated-app.msix

En el caso de las implementaciones empresariales, considere la posibilidad de programar actualizaciones durante las ventanas de mantenimiento mediante Intune o Administrador de configuración.

Error de coincidencia de MinVersion o 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.

Applies to: 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 está ejecutando como administrador, pero la aplicación es para otro usuario, use 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".

Applies to: 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.

Error de coincidencia de 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).

Applies to: 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 a la versión mínima que requiere su sistema operativo más antiguo admitido:

<?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.

Applies to: 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 se distribuye fuera de la Tienda, incluya paquetes de marco en el archivo en .appinstaller<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

Symptom: la canalización de CI/CD (Acciones de GitHub, Azure DevOps) produce 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:

Option 1: instale Windows SDK 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 firma de artefactos de Azure (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 (redirección 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.

Applies to: Windows 10 y versiones posteriores, Windows 11

Explicación: MSIX usa el redireccionamiento del sistema de archivos virtual (VFS). Las escrituras en rutas protegidas del sistema se redirigen silenciosamente a un contenedor específico del 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 HKEY_LOCAL_MACHINE\Software\MyApp\ en en tiempo de ejecución, pero el valor no es visible para otros procesos o sobrevive a una reinstalación.

Applies to: 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, se elimina el subárbol.

Opciones:

• Escribir la configuración por usuario en HKEY_CURRENT_USER\Software\<AppName> : no se virtualizan ni se conservan.
• 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 del manifiesto del paquete de aplicación para obtener la MinOSVersion lista 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