Erreur 0x80070652 : une autre installation est en cours

L’erreur 0x80070652 veut dire une seule chose : le service Windows Installer travaille déjà sur une autre installation et refuse d’en démarrer une deuxième. Le code correspond à l’erreur Windows Installer 1618, ERROR_INSTALL_ALREADY_RUNNING, et se règle presque toujours en attendant la fin du travail en cours puis en redémarrant.

Points clés

• 0x80070652 traduit l’erreur 1618 du Windows Installer : « une autre installation est déjà en cours ».
• La cause technique est le mutex _MSIExecute : deux installations ne peuvent pas tourner dans le même processus.
• Une mise à jour Windows en attente de redémarrage suffit à bloquer toute nouvelle installation MSI.
• Le redémarrage règle la majorité des cas ; couper msiexec.exe à la main est le dernier recours.
• Un code voisin, 1500, dit la même chose côté message utilisateur.

Ce que signifie 0x80070652

Comme tous les codes en 0x8007, celui-ci enveloppe une erreur Win32 : 0x652 vaut 1618 en décimal. Dans la table officielle des messages d’erreur de MsiExec, 1618 se lit ERROR_INSTALL_ALREADY_RUNNING, « une autre installation est déjà en cours, terminez cette installation avant de poursuivre celle-ci ».

Le mécanisme est documenté par Microsoft. Le Windows Installer prend un verrou nommé, le mutex _MSIExecute, pendant qu’il traite les tables InstallExecuteSequence, AdminExecuteSequence ou AdvtExecuteSequence d’un paquet. Tant que ce verrou est posé, tout appel à l’API du programme d’installation renvoie 1618. Même réponse quand le processus courant traite les tables InstallUISequence ou AdminUISequence.

Autrement dit, l’erreur est un garde-fou, pas une panne. Deux installations ne peuvent pas s’exécuter dans le même processus, et le système préfère refuser la seconde plutôt que de laisser deux paquets réécrire les mêmes composants.

Ce qui occupe le programme d’installation

Quatre situations couvrent l’essentiel des cas rencontrés sur un poste Windows 11 ou Windows 10.

• Une installation lancée juste avant, encore visible ou déjà refermée mais dont le processus n’est pas sorti.
• Une mise à jour Windows en attente de redémarrage, qui garde la file de servicing occupée.
• Une mise à jour automatique d’un logiciel tiers déclenchée en arrière-plan, typique des suites bureautiques, des lecteurs PDF et des runtimes.
• Un paquet MSI dont l’exécution a échoué sans libérer le mutex, ce qui laisse msiexec.exe figé en mémoire.

Attendre, puis redémarrer

Commencez par le geste le moins risqué. Fermez tous les assistants d’installation ouverts, y compris les fenêtres réduites dans la barre des tâches, attendez deux à trois minutes, puis relancez votre installation.

Si le code revient, redémarrez la machine. Le redémarrage vide les mutex, termine les processus msiexec.exe orphelins et applique les mises à jour en attente. Choisissez « Redémarrer » et non l’arrêt suivi du rallumage, car le démarrage rapide ne remet pas le noyau à zéro. À la remise en route, laissez une minute avant de relancer l’installation.

Vérifier qu’aucune mise à jour n’attend un redémarrage

Une machine en attente de redémarrage après une mise à jour cumulative bloque durablement les nouvelles installations. Ouvrez Paramètres, Windows Update, et regardez si un redémarrage est demandé. S’il y a une mise à jour en cours de téléchargement ou d’installation, laissez-la finir avant toute autre opération.

Si Windows Update tourne en boucle ou échoue avant de finir, le blocage vient de là et pas de votre paquet. Les cas fréquents sont documentés à part, notamment l’erreur 0x80073701, opération de mise à jour incomplète et l’erreur 0x800f0831 sur une mise à jour cumulative. Réglez d’abord la mise à jour, l’installation passera ensuite.

Repérer et terminer le processus msiexec

Cette étape est plus intrusive, elle vient donc après le redémarrage. Ouvrez le Gestionnaire des tâches, onglet Détails, et cherchez les occurrences de msiexec.exe. En ligne de commande, tasklist /fi "imagename eq msiexec.exe" donne la même information de façon plus lisible.

Un point de vigilance avant de cliquer sur Fin de tâche : si un paquet est réellement en train d’écrire des fichiers, l’arrêt brutal laisse une installation à moitié faite, qu’il faudra réparer ou désinstaller ensuite. Ne terminez le processus que si aucune barre de progression n’est visible et si la machine ne fait rien depuis plusieurs minutes.

Dans la version documentée par Microsoft pour les développeurs, la bonne pratique consiste à interroger l’état du service Windows Installer avant de tenter une installation, plutôt qu’à forcer le passage. Sur un poste, l’équivalent pratique est d’attendre le retour au repos.

Le service Windows Installer lui-même

Le service msiserver est configuré en démarrage manuel par défaut : il se lance à la demande et s’arrête ensuite. Vérifiez dans services.msc qu’il n’est pas désactivé, ce qui produirait d’autres erreurs, et laissez son type de démarrage sur Manuel. La commande sc config documentée par Microsoft permet de rétablir ce réglage si un utilitaire l’a modifié.

Ne mettez pas ce service en Automatique « pour être sûr ». Il n’a rien à faire tourner en continu, et ce réglage ne libère aucun mutex.

Quand le code revient à chaque tentative

Un 0x80070652 qui persiste après un redémarrage propre indique une installation en attente côté servicing. Les composants Windows Update et le magasin de composants sont alors à remettre au propre. La procédure est détaillée dans notre guide pour réinitialiser les composants Windows Update en ligne de commande.

Contrôlez aussi l’espace disque libre. Microsoft recommande de garder de la marge sur le volume système ; en dessous, les opérations de servicing échouent et laissent des états intermédiaires. Enfin, si un paquet précis est le seul à échouer, cherchez son propre journal d’installation avant d’accuser le système : un paquet mal signé ou incomplet produit d’autres codes que 1618.

Lire le journal d’installation avant de conclure

Quand l’échec se répète sur un seul logiciel, le journal verbeux du Windows Installer tranche entre un verrou et un paquet défectueux. Microsoft documente l’option de journalisation en ligne de commande : msiexec /i paquet.msi /L*v C:\temp\install.log écrit chaque étape dans un fichier texte.

Ouvrez ce fichier, cherchez la première occurrence de « Return value 3 » ou du numéro 1618, puis remontez de quelques lignes. Si le journal s’arrête avant même la séquence d’exécution, le service était déjà occupé et la résolution reste le redémarrage. Si l’échec arrive plus loin, le problème vient du paquet ou de ses prérequis, et les logiciels de nettoyage n’y changeront rien.

Sur un ordinateur d’entreprise, vérifiez aussi qu’aucun déploiement automatisé ne pousse une installation au même moment. Une stratégie de groupe ou un outil de gestion de parc déclenche des installations sans interface : elles prennent le verrou exactement comme un assistant visible.

Les services à contrôler quand rien ne bouge

Trois services participent au cycle d’installation et de mise à jour. Ouvrez services.msc et vérifiez leur état, sans modifier leur type de démarrage par défaut.

• Windows Installer (msiserver) : démarrage manuel, il s’arrête de lui-même.
• Windows Update (wuauserv) : en cours d’exécution pendant une mise à jour.
• Service de transfert intelligent en arrière-plan (BITS) : il gère le téléchargement des paquets.

Si l’un d’eux reste bloqué en état « Arrêt en cours », le redémarrage de la machine est la seule sortie propre. Ne forcez pas l’arrêt d’un service de servicing depuis le Gestionnaire des tâches pendant une installation : c’est le meilleur moyen de laisser une étape à moitié faite.

Codes voisins à ne pas confondre

Le message « une autre installation est en cours » existe aussi sous le numéro 1500 dans la table des messages d’erreur du Windows Installer, avec le même sens fonctionnel. Le code 1705, lui, signale qu’une installation précédente du même produit est en cours et qu’il faut annuler ses modifications pour continuer. Ces deux cas se traitent comme 0x80070652.

Restent les codes de mise à jour qui ressemblent à un blocage mais viennent d’ailleurs, comme l’erreur 0x8024a105, liée au téléchargement plutôt qu’au verrou d’installation.

FAQ

Combien de temps faut-il attendre avant d’agir ?

Deux à trois minutes après fermeture des assistants suffisent dans la plupart des cas. Au-delà de cinq minutes sans activité disque, un redémarrage est plus efficace que l’attente.

Peut-on forcer l’installation avec msiexec en ligne de commande ?

Non. Le verrou _MSIExecute est global au service, la ligne de commande reçoit le même 1618. Aucune option ne le contourne.

Est-ce dangereux de terminer msiexec.exe ?

Cela l’est si une installation écrit réellement des fichiers à ce moment. Le produit concerné peut rester dans un état partiel, à réparer depuis la liste des applications installées.

0x80070652 vient-il toujours d’un fichier MSI ?

Il vient du moteur Windows Installer, que le paquet soit un MSI classique ou un installeur qui l’appelle en interne. Les runtimes et suites qui embarquent un MSI produisent donc le même code.

Faut-il désactiver l’antivirus ?

Ce n’est pas la piste ici. Un verrou d’installation n’est pas une violation de partage de fichier ; ce dernier cas remonte un code différent, 0x80070020.

_{Photo d’en-tête : capture de l’écran de mise à jour de Windows 10 version 22H2 par CSR2Forever, domaine public, via Wikimedia Commons. Elle illustre le contexte des installations en attente, pas le message d’erreur.
Sources : Microsoft Learn, messages d’erreur MsiExec.exe · Microsoft Learn, mutex _MSIExecute · Microsoft Learn, messages d’erreur du Windows Installer · Microsoft Learn, commande tasklist · Microsoft Learn, options de ligne de commande MsiExec · Microsoft Learn, commande sc config. Vérifié le 14 septembre 2026.}