Impossible d’ouvrir le périphérique : GetLastError 32

Le message « impossible d’ouvrir le périphérique : GetLastError 32 » ne demande pas de formater. Ce code Windows indique un conflit de partage : un autre processus utilise la cible d’une manière incompatible avec l’accès demandé. Fermez d’abord les applications connues qui accèdent au périphérique. Vérifiez aussi si une tentative précédente a déjà modifié ses fichiers.

Un outil qui refuse de poursuivre peut justement empêcher une écriture dans de mauvaises conditions. Ne cherchez pas immédiatement à contourner son verrouillage. Vous devez d’abord savoir quelle cible vous avez choisie et quelles données elle contient encore.

Ce que le code permet de comprendre

Distinguez l’erreur 32 des messages voisins

Conservez le texte complet, le nom de l’application et les lignes précédentes du journal. Microsoft identifie le code décimal 32, ou 0x20, comme ERROR_SHARING_VIOLATION. Un accès refusé avec le code 5 constitue un autre résultat. Deux boîtes de dialogue semblables ne prouvent pas une cause identique.

GetLastError désigne un mécanisme de signalement Windows, pas un logiciel particulier. Plusieurs applications peuvent présenter son résultat. Vérifiez donc le programme réellement lancé au lieu de déduire automatiquement Rufus ou un autre outil depuis une phrase trouvée en ligne.

Repérez le moment du refus

Le journal parle-t-il d’ouverture, de verrouillage, de préparation des partitions ou d’écriture ? Un refus avant l’obtention de l’accès peut laisser les fichiers intacts. Des essais antérieurs ont cependant pu agir, même si le dernier s’est arrêté tôt. Examinez la chronologie complète.

Si les données s’ouvrent encore et que la lecture reste stable, copiez les éléments importants ailleurs avant tout nouvel essai. Un dossier disparu après une tentative d’écriture demande de protéger ce qui reste. Relancer la création du support peut écraser des données encore récupérables.

Fermez les consommateurs ordinaires avant de chercher plus loin

Commencez par les applications que vous reconnaissez : lecteur vidéo, visionneuse photo, éditeur, terminal ou sauvegarde. Enregistrez leur travail et quittez-les normalement. Arrêter au hasard des processus inconnus risque de créer une seconde panne tout en masquant le véritable propriétaire de l’accès.

Terminez les transferts et les documents ouverts

Laissez une copie finir ou annulez-la dans sa propre interface. Fermez les documents et médias ouverts depuis le périphérique. Quittez un terminal dont le répertoire courant se trouve dessus. Dans l’Explorateur, passez à un autre emplacement et fermez les fenêtres supplémentaires, surtout si leur volet d’aperçu affiche un fichier de la cible.

Attendez la fin réelle de l’activité. Une fenêtre fermée ne signifie pas forcément qu’une sauvegarde en arrière-plan a libéré le périphérique. Consultez son état avant de retenter l’accès. Un voyant ou un écran apparemment immobile ne remplace pas cette vérification.

Contrôlez les machines virtuelles et les tâches planifiées

Une machine virtuelle peut avoir capturé un périphérique USB pour son système invité. Terminez l’usage dans cet environnement, puis libérez le périphérique avec les commandes du logiciel de virtualisation. Ne débranchez rien pendant une écriture. Pour une sauvegarde, utilisez la pause ou l’arrêt prévu par son application.

Une analyse de sécurité peut aussi participer aux accès. Examinez une notification concrète ou un processus explicitement mentionné, sans désactiver toute la protection. Sur un ordinateur professionnel, transmettez le problème au support. Une exception autorisée vaut mieux qu’un contournement improvisé.

Utilisez un redémarrage normal comme test limité

Après avoir enregistré le journal et fermé les transferts, quittez l’outil puis redémarrez Windows normalement. Cela peut terminer des accès ordinaires encore ouverts. À la reconnexion, ne relancez pas immédiatement tous les programmes qui utilisent le périphérique. Ouvrez seulement l’application nécessaire et vérifiez sa cible.

Le même code qui revient aussitôt est une information utile, pas une invitation à redémarrer sans fin. Un service peut reprendre son activité et une règle de gestion demeure applicable. Conservez ce résultat pour la suite du diagnostic.

La prochaine tentative doit avoir une cible et une sauvegarde vérifiées

Ne vous fiez pas uniquement à la lettre

Comparez la capacité, le nom ou le modèle disponible, et les fichiers présents. Une lettre de lecteur peut changer après reconnexion. Retirer proprement les périphériques amovibles inutiles peut clarifier le choix, à condition qu’ils ne servent plus. Cette simplification ne dispense pas d’identifier précisément celui qui reste.

Si vous créez un support d’installation, la réussite du verrouillage peut conduire directement à une écriture destructive. Ne cliquez pas sur Démarrer pour vérifier seulement si le message a disparu. Vous devez être prêt à accepter les conséquences de l’opération complète.

Ouvrez les copies de sauvegarde

Une copie rangée ailleurs sur le même périphérique n’est pas indépendante. Placez les fichiers nécessaires sur une autre destination saine et ouvrez plusieurs exemples. Dans le cas d’un projet, contrôlez aussi les médias ou documents associés. Un répertoire visible ne prouve pas que tout son contenu est utilisable.

Après cette vérification, une tentative planifiée permet de voir si le conflit est résolu. Obtenir l’accès ne certifie pas la fin de l’écriture ni le démarrage du support créé. Suivez ensuite la vérification propre à l’application, sans confondre ces étapes.

Un conflit persistant mérite des indices, pas une suppression forcée

Utilisez un processus nommé dans le bon contexte

Certains outils peuvent indiquer une application ou un service qui accède au volume. Un éditeur connu peut se fermer par sa fenêtre normale. Avec un service système inconnu, identifiez son rôle avant toute intervention. Son nom dans le journal ne prouve ni qu’il est inutile ni qu’il est malveillant.

Forcer la fermeture d’un handle individuel peut interrompre une opération et laisser l’application dans un état incohérent. Si les fermetures normales ne suffisent pas, demandez de l’aide pour identifier le processus qui garde le périphérique ouvert. Le but reste de retrouver un accès propre, pas de supprimer toute protection.

Préparez un dossier de support court et précis

Notez la version affichée du programme, la version de Windows, l’identité du périphérique et l’étape exacte du refus. Ajoutez les applications déjà fermées et le résultat d’un redémarrage. Masquez les noms confidentiels, les chemins personnels et les données de licence avant toute publication du journal.

Une nouvelle erreur comme « périphérique non prêt », des déconnexions répétées ou des lectures gravement défaillantes modifie le problème. Préservez aussi ce message. Une source instable demande une évaluation adaptée, éventuellement une image ou une récupération spécialisée, plutôt qu’une recherche prolongée de verrou logiciel.

DiskPart clean, l’initialisation, la suppression de partitions et le formatage modifient le stockage. Ce ne sont pas des commandes destinées à demander poliment à une application de libérer son accès. Écartez-les de ce diagnostic tant que des fichiers importants restent en jeu.

Si une tentative a supprimé les fichiers, récupérez avant de réécrire

Cette branche concerne une perte locale réelle, pas le simple message de verrouillage. Vérifiez les sauvegardes indépendantes avant de lancer une analyse. Pour une cible amovible, la page de récupération USB explique cette situation plus largement. N’écrivez pas un nouveau support d’installation sur les données recherchées.

Drecov récupère des fichiers locaux perdus dans Windows. Son mode en lecture seule, Quick Scan, Deep Scan, les filtres et les aperçus compatibles aident à identifier des candidats. Lost Partition Recovery s’applique aux données d’une partition disparue. Fermer l’accès d’un autre processus, réparer le matériel et reconstruire une table de partitions sont des opérations distinctes de la récupération de fichiers.

Préparez la destination avant l’étape 1

Arrêtez les écritures sur la source et prévoyez un autre appareil sain. N’installez pas Drecov sur la partition touchée. Des erreurs graves ou des déconnexions répétées justifient un avis sur l’imagerie ou une aide spécialisée. Les écrasements ultérieurs et TRIM sur SSD peuvent réduire les possibilités.

Étape 1 : ouvrir Drecov sur l’ancien emplacement

Choisissez le périphérique ou volume stable qui contenait les documents avant l’écriture. Utilisez Lost Partition Recovery lorsque la partition elle-même a disparu. Vérifiez l’identité réelle de la source au lieu de vous fier seulement à une ancienne lettre.

Étape 2 : lancer Quick Scan et reconnaître les originaux

Recherchez les dossiers familiers, les noms attendus et les types nécessaires. De nouveaux fichiers d’installation peuvent apparaître sans être vos anciens documents. Comparez les chemins et dates disponibles avec vos propres repères avant de sélectionner un groupe.

Étape 3 : passer à Deep Scan si nécessaire

Continuez uniquement lorsque Quick Scan ne trouve pas les éléments voulus et que la lecture reste stable. Arrêtez si elle se dégrade. La page de récupération de fichiers traite d’autres pertes locales. Une recherche plus profonde ne recrée pas des données entièrement écrasées.

Étape 4 : filtrer et examiner les aperçus disponibles

Affinez avec le nom, le type, le chemin et la date lorsqu’ils existent. Prévisualisez des exemples compatibles. Une page visible ne garantit pas toutes les pages du document. Pour la récupération photo, examinez les détails sans confondre une petite miniature avec l’original.

Étape 5 : enregistrer ailleurs et tester les fichiers

Récupérez la sélection sur l’autre appareil sain, jamais sur la source. Vérifiez Drecov Folder ou Recovery Folder si la sortie semble absente. Ouvrez les documents et testez les éléments importants des archives ou projets. Attendez cette validation avant un formatage ou une nouvelle création de support.

FAQ sur GetLastError 32

Le code 32 indique-t-il un périphérique cassé ?

Il décrit d’abord un conflit de partage. Des erreurs de lecture ou des déconnexions apportent d’autres indices qui demandent une évaluation distincte.

Les droits administrateur suffisent-ils ?

Ils ne terminent pas forcément l’accès incompatible d’un autre programme. Utilisez les droits nécessaires, puis fermez normalement le véritable consommateur.

Faut-il formater pour libérer le périphérique ?

Le formatage modifie les structures. Résolvez l’accès et protégez les données avant d’entreprendre une écriture intentionnelle.

Ce message appartient-il uniquement à Rufus ?

Non. Plusieurs applications Windows peuvent afficher un résultat GetLastError. Identifiez le programme et lisez son journal complet.

Puis-je réessayer jusqu’à ce que cela fonctionne ?

Une réussite peut lancer immédiatement l’écriture. Vérifiez d’abord la sauvegarde et la cible, puis effectuez un essai contrôlé.

Conclusion

Face au code 32, identifiez l’application qui utilise le périphérique, enregistrez son travail et fermez-la normalement. Effacer le support ne doit pas servir à lever ce conflit. Confirmez la cible et vérifiez une sauvegarde avant toute nouvelle écriture. Si une tentative précédente a déjà supprimé des fichiers, Drecov peut examiner la source stable. Contrôlez les résultats enregistrés sur un autre appareil avant de reprendre l’opération.