O erro 0x80073D02 do Add-AppxPackage, também identificado como ERROR_PACKAGES_IN_USE, significa que o Windows não consegue concluir uma implantação AppX/MSIX porque um processo em execução está usando recursos que a operação do pacote precisa modificar. Ele se aplica a operações de instalação, atualização, remoção e novo registro no Windows 10 e no Windows 11. A primeira ação mais segura é ler a saída completa da falha para identificar o aplicativo ou pacote informado, fechar todas as instâncias visíveis desse aplicativo e repetir a mesma operação.

O que significa o erro 0x80073D02 do Add-AppxPackage

A falha completa pode começar com Deployment failed with HRESULT: 0x80073D02 ou informar que o pacote não pôde ser instalado porque os recursos que ele modifica estão em uso. De acordo com a referência da Microsoft para solucionar problemas de implantação AppX, o código representa especificamente uma condição de pacote em uso.

O recurso pode estar sendo mantido por uma instância visível do aplicativo, uma tarefa ou serviço em segundo plano associado ao aplicativo ou um arquivo aberto nos dados do aplicativo, como um arquivo de log. Portanto, fechar uma janela visível pode ser suficiente em alguns casos, mas não em todos.

Detalhe O que ele confirma
0x80073D02 A implantação foi rejeitada porque recursos do pacote estão em uso.
Aplicativo ou pacote informado O primeiro lugar onde procurar o processo que está mantendo o recurso em uso.
ActivityID, se retornado Uma referência que pode ser usada ao consultar o log de implantação associado.

Este guia não se aplica a uma falha de implantação com outro código nem a um erro do Windows Update. Essas condições exigem um diagnóstico separado.

Identifique o aplicativo ou pacote que precisa ser fechado

Quando se aplica: use este processo quando a saída do erro informar um aplicativo ou uma família de pacotes, ou disser que um ou mais aplicativos precisam ser fechados.

Pré-requisito: mantenha a saída original do erro disponível para comparar o nome do aplicativo ou pacote com os processos que você verificar.

  1. Leia toda a saída da implantação, não apenas a primeira linha com o HRESULT.
  2. Procure o aplicativo ou a família de pacotes indicada como estando em uso. A saída pode identificar explicitamente os aplicativos que precisam ser fechados.
  3. Feche todas as janelas visíveis pertencentes ao aplicativo informado.
  4. Abra o Gerenciador de Tarefas e procure uma instância restante desse mesmo aplicativo.
  5. Se você já souber o nome do processo correspondente, também poderá usar Get-Process para verificar se ele continua ativo.

Resultado esperado: você identifica um processo que corresponde claramente ao aplicativo ou pacote informado pela falha, ou confirma que não há nenhum processo correspondente evidente em execução.

Risco e aviso: a inspeção apresenta baixo risco, mas os nomes de famílias de pacotes não têm um mapeamento universal e documentado para nomes de processos. Não deduza o processo com base em um nome de pacote desconhecido, não encerre todos os processos com nomes semelhantes e não finalize um processo de sistema não relacionado. Os termos exibidos pelo Gerenciador de Tarefas também podem variar ligeiramente conforme a versão do Windows.

O guia da Microsoft para solucionar problemas do MSIX recomenda verificar instâncias em execução com o Gerenciador de Tarefas ou Get-Process.

Feche o bloqueador confirmado e repita a operação do pacote

Quando se aplica: use esta correção depois que a saída ou a inspeção dos processos identificar o aplicativo que está usando o pacote.

Pré-requisitos: salve seu trabalho no aplicativo afetado e confirme que o processo que você pretende fechar pertence ao aplicativo informado. Se a relação não estiver clara, consulte os logs de implantação da próxima seção em vez de encerrar o processo.

  1. Feche todas as janelas visíveis do aplicativo informado.
  2. Verifique no Gerenciador de Tarefas ou com Get-Process se ainda há uma instância em execução.
  3. Interrompa apenas o processo correspondente, se for seguro fechá-lo.
  4. Confirme que o aplicativo não está mais em execução.
  5. Repita a mesma operação de Add-AppxPackage, instalação, atualização, remoção ou novo registro que falhou originalmente. Não a substitua por um comando abrangente de reparo de pacotes.
  6. Se 0x80073D02 aparecer novamente, verifique a saída e os logs em busca de outro bloqueador.

Resultado esperado: o Windows poderá prosseguir quando nenhum processo estiver mantendo os recursos necessários para a operação do pacote. Uma nova tentativa ainda pode revelar outro bloqueador, portanto o sucesso não é garantido.

Risco e reversão: fechar um processo pode descartar alterações não salvas nesse aplicativo. Reabra o aplicativo depois que a implantação terminar ou quando você encerrar o diagnóstico. A referência oficial do Add-AppxPackage documenta o comando de implantação; reutilize a operação adequada à tarefa original sem adicionar parâmetros não documentados.

Verifique os logs de implantação AppX quando o bloqueador não estiver claro

Os logs são apropriados quando o texto do erro está incompleto, o aplicativo visível já foi fechado ou a falha reaparece depois que o bloqueador evidente foi removido. A leitura desses logs é uma etapa de diagnóstico e não repara a implantação por si só.

Consulte o log AppxDeployment-Server no Visualizador de Eventos

Quando se aplica: use o Visualizador de Eventos quando precisar de mais detalhes sobre o motivo pelo qual o Windows rejeitou a implantação.

Pré-requisito: você precisa conseguir abrir o Visualizador de Eventos. Nenhum requisito de administrador é afirmado aqui, pois isso pode variar conforme o ambiente examinado.

  1. Abra o Visualizador de Eventos.
  2. Acesse Logs de Aplicativos e Serviços > Microsoft > Windows > AppxDeployment-Server > Operational.
  3. Consulte os detalhes da rejeição da implantação associados à operação que falhou.
  4. Identifique o aplicativo, pacote, processo, tarefa em segundo plano, serviço ou recurso aberto relevante sem deduzir um processo a partir de um nome de pacote incerto.
  5. Feche apenas o bloqueador confirmado e repita a operação original do pacote.

Resultado esperado: o log fornece informações mais específicas sobre a implantação e pode ajudar a diferenciar o bloqueador relevante de processos em execução que não têm relação com a falha.

Risco e reversão: a leitura do log não altera o sistema, portanto nenhuma reversão é necessária. Não limpe nem modifique os logs como parte deste procedimento.

Use Get-AppxLog para a implantação que falhou

Quando se aplica: use Get-AppxLog depois de uma falha do Add-AppxPackage ou Remove-AppxPackage, principalmente quando a saída retornar uma ActivityID.

Pré-requisitos: acesso ao PowerShell e, quando disponível, a ActivityID presente na saída da falha.

  1. Use Get-AppxLog para a implantação mais recente ou para a ActivityID disponível.
  2. Leia os erros e avisos registrados.
  3. Use esses detalhes para identificar o pacote ou processo que está mantendo os recursos necessários em uso.
  4. Feche apenas o bloqueador confirmado.
  5. Repita a mesma operação e consulte o log novamente se o erro reaparecer.

Resultado esperado: o log de implantação fornece evidências sobre a operação de pacote que falhou e pode revelar um bloqueador que não estava evidente na saída original.

Risco e reversão: esta é uma etapa de diagnóstico somente leitura e não exige reversão. Não considere a presença de um nome de processo semelhante como evidência suficiente para encerrá-lo.

Lide com um componente do shell do Windows que reinicia automaticamente

Quando se aplica: use esta alternativa somente quando o bloqueador confirmado for um componente do shell ou de segundo plano do Windows que reinicia automaticamente e não permanece fechado pelo tempo necessário para concluir a operação do pacote.

Pré-requisitos: salve seu trabalho em todos os aplicativos abertos e confirme, pelo erro ou pelos logs de implantação, que o componente que reinicia é o bloqueador.

  1. Saia do Windows e entre novamente, ou reinicie o Windows.
  2. Depois de entrar, repita a operação de implantação original.
  3. Se o mesmo componente reaparecer e a operação voltar a informar 0x80073D02, consulte novamente o log AppxDeployment-Server ou o Get-AppxLog.

Resultado esperado: sair da sessão ou reiniciar pode encerrar as instâncias que estavam em execução na sessão anterior, criando outra oportunidade para realizar a implantação. Um componente do shell pode reiniciar, portanto esta alternativa talvez não resolva todos os casos.

Risco e reversão: sair da sessão ou reiniciar fecha os aplicativos e pode descartar alterações não salvas. Salve seu trabalho primeiro e reabra os aplicativos depois de entrar novamente. Não encerre repetidamente processos do shell.

Correções não sustentadas para o erro 0x80073D02

As orientações específicas da Microsoft para esse erro se concentram em fechar o processo que está usando o pacote e examinar os logs de implantação. As evidências fornecidas não sustentam as seguintes ações como correções para ERROR_PACKAGES_IN_USE:

  • Redefinir o cache da Microsoft Store como resposta padrão.
  • Registrar novamente, em massa, todos os pacotes AppX ou os pacotes de todos os usuários.
  • Reduzir as restrições da política de execução do PowerShell.
  • Editar o Registro.
  • Redefinir ou restaurar o Windows.
  • Encerrar processos não relacionados porque seus nomes se parecem com uma família de pacotes.

Essas ações abrangentes não corrigem a condição confirmada de que um recurso necessário do pacote está em uso e podem causar outros problemas. Uma falha de acesso negado do Windows Update exige um diagnóstico separado e não equivale a este erro AppX/MSIX.