El error 0x80073D02 de Add-AppxPackage, también identificado como ERROR_PACKAGES_IN_USE, significa que Windows no puede completar una implementación AppX/MSIX porque un proceso en ejecución está usando recursos que la operación del paquete necesita modificar. Se aplica a operaciones de instalación, actualización, eliminación y nuevo registro en Windows 10 y Windows 11. La primera medida más segura es leer el resultado completo del error para localizar la aplicación o el paquete indicado, cerrar todas las instancias visibles de esa aplicación y reintentar la misma operación.

Qué significa el error 0x80073D02 de Add-AppxPackage

El mensaje completo puede comenzar con Deployment failed with HRESULT: 0x80073D02 o indicar que el paquete no pudo instalarse porque los recursos que modifica están actualmente en uso. Según la referencia de Microsoft para solucionar problemas de implementación de AppX, el código representa específicamente una situación en la que un paquete está en uso.

El recurso puede estar retenido por una instancia visible de la aplicación, una tarea o un servicio en segundo plano asociado con ella, o un archivo abierto en los datos de la aplicación, como un archivo de registro. Por tanto, cerrar una ventana visible puede ser suficiente en algunos casos, pero no en todos.

Detalle Qué permite determinar
0x80073D02 La implementación se rechazó porque hay recursos del paquete en uso.
Aplicación o paquete indicado El primer lugar donde buscar el proceso que retiene el recurso.
ActivityID, si aparece Una referencia que puede usarse al revisar el registro de implementación asociado.

Esta guía no se aplica a un error de implementación con otro código ni a un error de Windows Update. Esas situaciones requieren un diagnóstico independiente.

Identificar la aplicación o el paquete que debe cerrarse

Cuándo se aplica: Usa este proceso cuando el resultado del error indique una aplicación o familia de paquetes, o señale que deben cerrarse una o varias aplicaciones.

Requisito previo: Mantén disponible el resultado original del error para comparar el nombre de la aplicación o del paquete con los procesos que revises.

  1. Lee el resultado completo de la implementación, no solo la primera línea del HRESULT.
  2. Busca la aplicación o familia de paquetes indicada como en uso. El resultado puede identificar de forma explícita las aplicaciones que deben cerrarse.
  3. Cierra todas las ventanas visibles de la aplicación indicada.
  4. Abre el Administrador de tareas y busca una instancia restante de esa misma aplicación.
  5. Si ya conoces el nombre del proceso correspondiente, también puedes usar Get-Process para comprobar si continúa activo.

Resultado esperado: Identificas un proceso que corresponde claramente a la aplicación o al paquete indicado por el error, o confirmas que no queda ningún proceso coincidente evidente.

Riesgo y advertencia: La inspección tiene un riesgo bajo, pero no existe una correspondencia universal documentada entre los nombres de las familias de paquetes y los nombres de los procesos. No deduzcas el proceso a partir de un nombre de paquete desconocido, no finalices todos los procesos con nombres parecidos ni cierres un proceso del sistema que no esté relacionado. El texto del Administrador de tareas también puede variar ligeramente según la compilación de Windows.

La guía de Microsoft para solucionar problemas de MSIX respalda la comprobación de instancias en ejecución mediante el Administrador de tareas o Get-Process.

Cerrar el bloqueo confirmado y reintentar la operación del paquete

Cuándo se aplica: Usa esta solución después de que el resultado o la inspección de procesos identifique la aplicación que está usando el paquete.

Requisitos previos: Guarda el trabajo de la aplicación afectada y confirma que el proceso que pretendes cerrar pertenece a la aplicación indicada. Si la relación no está clara, consulta los registros de implementación de la siguiente sección en lugar de finalizar el proceso.

  1. Cierra todas las ventanas visibles de la aplicación indicada.
  2. Comprueba en el Administrador de tareas o mediante Get-Process si queda alguna instancia.
  3. Detén únicamente el proceso coincidente si es seguro cerrarlo.
  4. Confirma que la aplicación ya no se está ejecutando.
  5. Reintenta la misma operación de Add-AppxPackage, instalación, actualización, eliminación o nuevo registro que falló originalmente. No la sustituyas por un comando general de reparación de paquetes.
  6. Si vuelve a aparecer 0x80073D02, revisa el resultado y los registros para localizar otro bloqueo.

Resultado esperado: Windows puede continuar cuando ningún proceso retiene los recursos necesarios para la operación del paquete. Un nuevo intento aún puede revelar otro bloqueo, por lo que el éxito no está garantizado.

Riesgo y reversión: Cerrar un proceso puede descartar el trabajo no guardado de esa aplicación. Vuelve a abrirla después de completar la implementación o de finalizar el diagnóstico. La referencia oficial de Add-AppxPackage documenta el comando de implementación; reutiliza la operación correspondiente a la tarea original sin agregar parámetros no documentados.

Consultar los registros de implementación de AppX cuando el bloqueo no esté claro

Los registros son apropiados cuando el texto del error está incompleto, la aplicación visible ya está cerrada o el error vuelve a aparecer después de eliminar el bloqueo evidente. Leer estos registros es una medida de diagnóstico y no repara por sí misma la implementación.

Revisar el registro AppxDeployment-Server en el Visor de eventos

Cuándo se aplica: Usa el Visor de eventos cuando necesites más detalles sobre el motivo por el que Windows rechazó la implementación.

Requisito previo: Debes poder abrir el Visor de eventos. No se afirma que sea necesario tener permisos de administrador, ya que esto puede variar según el entorno examinado.

  1. Abre el Visor de eventos.
  2. Ve a Registros de aplicaciones y servicios > Microsoft > Windows > AppxDeployment-Server > Operativo.
  3. Revisa los detalles del rechazo de implementación asociados con la operación que falló.
  4. Identifica la aplicación, el paquete, el proceso, la tarea en segundo plano, el servicio o el recurso abierto correspondiente sin deducir un proceso a partir de un nombre de paquete incierto.
  5. Cierra únicamente el bloqueo confirmado y vuelve a intentar la operación original del paquete.

Resultado esperado: El registro proporciona información más específica sobre la implementación que puede ayudar a distinguir el bloqueo relevante de otros procesos en ejecución que no están relacionados.

Riesgo y reversión: Leer el registro no modifica el sistema, por lo que no se necesita ninguna reversión. No borres ni modifiques los registros como parte de este procedimiento.

Usar Get-AppxLog para la implementación fallida

Cuándo se aplica: Usa Get-AppxLog después de un error de Add-AppxPackage o Remove-AppxPackage, especialmente cuando el resultado haya proporcionado un ActivityID.

Requisitos previos: Acceso a PowerShell y, cuando esté disponible, el ActivityID del resultado del error.

  1. Usa Get-AppxLog para la implementación más reciente o para el ActivityID disponible.
  2. Lee los errores y las advertencias registrados.
  3. Usa esos detalles para identificar el paquete o proceso que retiene los recursos necesarios.
  4. Cierra únicamente el bloqueo confirmado.
  5. Reintenta la misma operación y vuelve a consultar el registro si el error reaparece.

Resultado esperado: El registro de implementación proporciona evidencias sobre la operación fallida del paquete y puede revelar un bloqueo que no resultaba evidente en el resultado original.

Riesgo y reversión: Este es un paso de diagnóstico de solo lectura y no necesita reversión. No consideres que un nombre de proceso parecido constituye evidencia suficiente para finalizarlo.

Gestionar un componente del shell de Windows que se reinicia automáticamente

Cuándo se aplica: Usa esta alternativa solo cuando el bloqueo confirmado sea un componente del shell o un componente en segundo plano de Windows que se reinicie automáticamente y no pueda permanecer cerrado el tiempo suficiente para completar la operación del paquete.

Requisitos previos: Guarda el trabajo de todas las aplicaciones abiertas y confirma mediante el error o los registros de implementación que el componente que se reinicia es el causante del bloqueo.

  1. Cierra la sesión de Windows y vuelve a iniciarla, o reinicia Windows.
  2. Después de iniciar sesión, reintenta la operación de implementación original.
  3. Si el mismo componente vuelve a aparecer y la operación informa de nuevo del error 0x80073D02, revisa otra vez el registro AppxDeployment-Server o Get-AppxLog.

Resultado esperado: Cerrar la sesión o reiniciar puede finalizar las instancias que se ejecutaban en la sesión anterior y ofrecer otra oportunidad para realizar la implementación. Un componente del shell puede volver a iniciarse, por lo que esta alternativa no resolverá todos los casos.

Riesgo y reversión: Cerrar la sesión o reiniciar cierra las aplicaciones y puede descartar el trabajo no guardado. Guarda primero y vuelve a abrir las aplicaciones después de iniciar sesión. No finalices repetidamente procesos del shell.

Soluciones no respaldadas para 0x80073D02

La orientación específica de Microsoft para este error se centra en cerrar el proceso que está usando el paquete y examinar los registros de implementación. Las evidencias proporcionadas no respaldan las siguientes acciones como soluciones para ERROR_PACKAGES_IN_USE:

  • Restablecer la caché de Microsoft Store como respuesta predeterminada.
  • Volver a registrar de forma masiva todos los paquetes AppX o los paquetes de todos los usuarios.
  • Reducir las restricciones de la directiva de ejecución de PowerShell.
  • Editar el Registro.
  • Restablecer o restaurar Windows.
  • Finalizar procesos no relacionados porque sus nombres se parecen a una familia de paquetes.

Estas medidas generales no resuelven la situación confirmada en la que un recurso necesario del paquete está en uso y pueden introducir problemas adicionales. Si el error corresponde a una condición de acceso denegado de Windows Update, requiere un diagnóstico independiente y no equivale a este error de AppX/MSIX.