Guida alla risoluzione dei problemi di MSIX

Questa guida copre gli errori MSIX più comuni nell'installazione, la firma, il Programma di Installazione App, le dipendenze mancanti e il comportamento in fase di esecuzione. Ogni sezione include il sintomo, la causa radice e la risoluzione.

Per un log completo degli eventi di distribuzione, aprire Visualizzatore eventi e passare a: Applications and Services Logs → Microsoft → Windows → AppxDeployment-Server → Operational

Errori di installazione

0x80070005 - Accesso negato

Sintomo: Add-AppxPackage o Il programma di installazione app ha esito negativo con codice 0x80070005di errore .

Applica a: Windows 10 e versioni successive Windows 11

Cause e correzioni:

Installazione del pacchetto bloccata perché l'app è in uso

Sintomo: l'aggiornamento o la ripetizione dell'installazione ha esito negativo e viene visualizzato un errore che indica che il pacchetto è in uso. In Visualizzatore eventi si noterà che l'operazione di distribuzione è stata rifiutata.

Applica a: Windows 10 e versioni successive Windows 11

Correzione: chiudere tutte le istanze in esecuzione dell'app prima dell'aggiornamento. Se l'app è un servizio in background o ha un'attività in background registrata, potrebbe essere necessario terminare anche queste operazioni:

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

Per le distribuzioni aziendali, è consigliabile pianificare gli aggiornamenti durante le finestre di manutenzione usando Intune o Gestione configurazione.

MinVersion o disallineamento dell'architettura

Symptom: l'installazione ha esito negativo e viene visualizzato un errore simile a "Impossibile installare il pacchetto perché non è compatibile con questa versione di Windows" o "Il pacchetto non è applicabile a questo computer".

Applica a: Windows 10 e versioni successive

Cause e correzioni:

Add-AppxPackage ha esito positivo, ma l'app non è presente nel menu Start

Sintomo: PowerShell segnala l'esito positivo, ma l'app non viene visualizzata nell'elenco Start Menu o app.

Applica a: Windows 10 e versioni successive Windows 11

Cause comuni:

• Installazione per utente vs. per macchina: Add-AppxPackage installa solo per l'utente corrente. Se stai eseguendo come amministratore ma prevedi che l'app sia destinata a un altro utente, utilizza Add-AppxProvisionedPackage invece.
• Pacchetto registrato ma riquadro non aggiunto: l'app è installata ma il menu Start non è stato aggiornato. Disconnettersi e accedere di nuovo oppure selezionare Impostazioni → App per confermare l'installazione.
• Voce del menu Start mancante nel manifesto: verificare che l'elemento <Application> in AppxManifest.xml includa una VisualElements voce con un oggetto valido Square150x150Logo.
• Conflitto di nomi di famiglia di pacchetti duplicati: se una versione più recente o precedente dell'app è già installata con lo stesso nome della famiglia di pacchetti, la nuova installazione potrebbe sostituirla automaticamente. Controllare con Get-AppxPackage -Name "YourPackageFamilyName".

Errori di firma e certificato

Certificato non attendibile (0x800B0109)

Sintomo: l'installazione ha esito negativo e viene visualizzato l'errore 0x800B0109 "Catena di certificati elaborata, ma terminata in un certificato radice non considerato attendibile dal provider di attendibilità".

Applica a: Windows 10 e versioni successive Windows 11

Causa: il certificato usato per firmare il pacchetto non si trova negli archivi certificati attendibili del dispositivo. Ciò è comune quando si usano certificati autofirmato per lo sviluppo.

Correzione: importare il certificato di firma nel computer locale del dispositivo → archivio Persone attendibili (non l'archivio utenti corrente - Il programma di installazione app controlla solo l'archivio computer):

# 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

Per le app di produzione, usare un certificato emesso da una CA attendibile o Azure Artifact Signing (precedentemente Trusted Signing), che si collega all'Autorità di Certificazione Radice di Verifica dell'Identità Microsoft, considerata attendibile per impostazione predefinita su Windows 10 versione 1809 e successive, e su Windows 11.

mancata corrispondenza del nome Publisher (0x8007000B, ID evento 150)

Symptom: Il programma SignTool si è arrestato con 0x8007000B e Visualizzatore eventi (log operativo AppxPackagingOM) mostra 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).

Applica a: Windows 10 e versioni successive Windows 11

Cause: l'attributo Publisher in AppxManifest.xml deve corrispondere esattamente al nome subject del certificato di firma, inclusi tutti i campi dei nomi distinti nello stesso ordine.

Correzione:

1. Ottenere il nome del soggetto esatto dal certificato:

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

2. Aggiornare AppxManifest.xml in modo che corrisponda esattamente:

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

3. Ri-creare un pacchetto con MakeAppx.exe e firmare di nuovo.

Errori dell'installer delle app e consegna tramite Web

Mancata corrispondenza della versione dello schema nel file appinstaller

Sintomo: il programma di installazione app non riesce ad analizzare o elaborare il .appinstaller file, spesso con un errore generico relativo a un file non valido o a uno schema non supportato.

Applies to: Windows 10 e versioni successive (dipende dalla versione - vedi tabella)

Cause: L'attributo Uri dell'elemento radice <AppInstaller> specifica una versione dello schema non supportata dalla versione installata di Windows.

Versioni dello schema per release di Windows:

Correzione: impostare l'URI dello schema nel .appinstaller file sulla versione minima richiesta dal sistema operativo più basso supportato:

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

Evitare di usare la versione più recente dello schema se è necessario supportare le versioni di Windows 10 precedenti.

File serviti con tipo MIME non corretto o lunghezza contenuto mancante

Sintomo: il programma di installazione dell'app non riesce durante l'installazione da un endpoint HTTP/HTTPS. L'errore può essere generico, ad esempio 0x80072F76 ("Errore sconosciuto") o "Installazione dell'app non riuscita".

Applica a: Windows 10 e versioni successive

Causa: il server Web gestisce il .msixfile , .msixbundleo .appinstaller con un'intestazione non corretta Content-Type o omettendo l'intestazione Content-Length .

Correzione: configurare il server Web per gestire i file correlati a MSIX con i tipi MIME corretti:

Assicurarsi anche che ogni risposta includa un'intestazione valida Content-Length: questo si applica a entrambe le richieste GET e HEAD.

Per IIS, aggiungere mapping dei tipi MIME in web.config. Per App Web statiche di Azure o GitHub Pages, i tipi MIME per queste estensioni potrebbero richiedere una configurazione esplicita o una soluzione di hosting personalizzata.

Dipendenze mancanti

Pacchetto framework non installato (VCLibs, .NET, SDK per app di Windows)

Symptom: l'app viene installata correttamente ma si arresta in modo anomalo all'avvio o l'installazione ha esito negativo con un errore di dipendenza che fa riferimento a un nome della famiglia di pacchetti, ad esempio Microsoft.VCLibs, Microsoft.WindowsAppRuntime o Microsoft.NET.Native.

Applica a: Windows 10 e versioni successive Windows 11

Framework comuni e dove ottenerli:

Correzione per lo sviluppo: quando si esegue l'installazione tramite Add-AppxPackage localmente, aggiungere prima il -DependencyPackages parametro o installare i pacchetti 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

Correzione per la distribuzione: se si distribuisce all'esterno dello Store, includere i pacchetti del framework nel proprio file sotto .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 non trovato in CI/CD

Symptom: il pipeline CI/CD (GitHub Actions, Azure DevOps) fallisce con un errore simile a 'signtool' is not recognized as an internal or external command o SignTool.exe: not found.

Applica a: Windows 10 e versioni successive, Windows 11 (macchina di firma)

Cause: SignTool fa parte dell'SDK di Windows e non è incluso nelle immagini di runner CI standard di default.

Fixes:

Option 1 - Installare Windows SDK nella pipeline (GitHub Actions):

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

Opzione 2 : usare l'interfaccia della riga di comando di WinApp (più semplice per 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 }}

Opzione 3 — Utilizzo della Firma degli Artefatti di Azure (consigliato per la produzione):

- 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

Per una procedura dettagliata completa della configurazione della firma CI/CD, vedere Firmare il pacchetto MSIX - guida end-to-end.

Comportamento di runtime e virtualizzazione

I pacchetti MSIX vengono eseguiti all'interno di un contenitore di app leggero. Alcuni comportamenti che sembrano essere bug sono in realtà per progettazione: il contenitore intercetta le operazioni di file e registro per proteggere il resto del sistema.

Perché le scritture di file sembrano scomparire (reindirizzamento di file VFS)

Sintomo: l'app scrive un file in un percorso come C:\Program Files\MyApp\config.ini in fase di esecuzione, ma il file non viene visualizzato. L'app legge correttamente il valore, ma altri processi o utenti non lo vedono.

Applica a: Windows 10 e versioni successive Windows 11

Spiegazione: MSIX usa il reindirizzamento VFS (Virtual File System). Le scritture nei percorsi di sistema protetti vengono reindirizzate automaticamente a un contenitore per utente:

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

Si tratta di una procedura predefinita, che impedisce alle app MSIX di modificare i percorsi di sistema condivisi, supportando la disinstallazione pulita.

Opzioni:

• Usare invece cartelle dati dell'app: scrivere in ApplicationData.Current.LocalFolder (WinRT) o %LocalAppData%\Packages\<PFN>\LocalState\ per i dati per utente che devono essere persistenti.
• Utilizzare AppData\Roaming per i dati che devono essere trasferiti tra dispositivi.
• Esaminare il contenitore VFS per visualizzare i file reindirizzati: %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

Per altri dettagli sui percorsi virtualizzati, vedere Risolvere i problemi di runtime in un contenitore MSIX.

Perché le scritture del Registro di sistema sembrano scomparire (virtualizzazione del Registro di sistema)

Sintomo: l'app scrive in HKEY_LOCAL_MACHINE\Software\MyApp\ in fase di esecuzione, ma il valore non è visibile ad altri processi né sopravvive a una reinstallazione.

Applica a: Windows 10 e versioni successive Windows 11

Spiegazione: MSIX intercetta le operazioni di scrittura HKLM\Software e le reindirizza a un hive del Registro di sistema per singolo pacchetto isolato dal resto del sistema. In caso di disinstallazione, l'hive viene eliminato.

Opzioni:

• Scrivere le impostazioni per utente in HKEY_CURRENT_USER\Software\<AppName> : queste impostazioni non sono virtualizzate e persistenti.
• Usare le API Windows ApplicationData per l'archiviazione delle impostazioni strutturate.
• Dichiarare le voci del Registro di sistema che devono essere condivise tra utenti o processi tramite il meccanismo AppxManifest.xml<Extensions> / <com:Extension>.

Per un'analisi più approfondita del comportamento del contenitore MSIX, vedere Informazioni sull'esecuzione delle app desktop in pacchetto in Windows.

Windows 10 limitazioni di MSIX

Alcune funzionalità MSIX richiedono Windows 11 o una versione Windows 10 specifica. Se si esegue la distribuzione su dispositivi Windows 10, tenete presente quanto segue.

Funzionalità che richiedono Windows 10 versione 2004 (build 19041) o successiva

Funzionalità che richiedono Windows 11

Windows 10 dispositivi precedenti alla versione 1709

MSIX non è supportato in modo nativo nelle versioni di Windows 10 precedenti alla versione 1709 (Fall Creators Update). Per distribuire pacchetti MSIX in tali dispositivi, usare MSIX Core, che fornisce un livello di compatibilità per le versioni di livello inferiore Windows 10.

Estensioni del file di manifest

Alcune estensioni dello spazio dei nomi AppxManifest.xml sono solo Windows 11. Dichiararle in un pacchetto per Windows 10 potrebbe far fallire la convalida dello schema durante l'impacchettamento o essere rifiutate durante l'installazione. Controllare il riferimento allo schema del manifesto del pacchetto app per l'elenco MinOSVersion per ogni estensione.

Suggerimento per il debug

Per verificare quali funzionalità MSIX sono disponibili in una build Windows 10 specifica, controllare le funzionalità MSIX e le piattaforme supportate pagina, che elenca la disponibilità delle funzionalità per versione del sistema operativo.

" output is necessary.)

• Panoramica della firma di un pacchetto MSIX
• Firmare il pacchetto MSIX - Guida end-to-end
• Problemi noti e risoluzione dei problemi per SignTool
• Risolvere i problemi con l'installazione delle app
• Risolvere i problemi di runtime in un contenitore MSIX
• Risoluzione dei problemi di confezionamento, distribuzione e query delle applicazioni Windows