Rufus est interrompu par explorer.exe presque à chaque fois
Récemment, j'ai un problème de fabrication de bâtons USB amorçables. Lorsque je veux écrire une image du système d'exploitation (Windows ou Centos) sur la clé USB avec Rufus, parfois, je reçois ce genre d'erreur:
L'appareil choisi est utilisé par un autre processus. Veuillez fermer le processus avant d'utiliser cet appareil.
C:\Windows\Explorer.exe (r)
Il semble que Windows pense que mon appareil est prêt à jouer à un moment donné et tente de le monter ou de quelque chose. Pourquoi Rufus ne peut pas bloquer cet appareil en l'utilisant? Il est vraiment ennuyeux de fermer explorer.exe à chaque fois que j'ai besoin d'un bâton USB amorçable.
Développeur Rufus ici.
Pourquoi Rufus ne peut pas bloquer cet appareil en l'utilisant?
Eh bien, nous essayons de faire exactement cela, avec un accès exclusif, mais Windows ne joue pas exactement bien.
Par exemple, ce que la plupart des gens ne savent pas, c'est que Windows (par exemple [~ # ~ ~] vds [~ # ~] ) ne vous permettra pas de nettoyer les partitions existantes d'un disque physique à moins que vous Ont déverrouillé ce disque d'abord ... qui est très intuitif et signifie que, pendant cette période, il n'ya aucun moyen d'empêcher d'autres applications d'accéder à ce disque.
En bref, Rufus essaie beaucoup de verrouiller à la fois le disque physique et les volumes logiques au besoin, mais ce n'est pas toujours aussi logique que l'on s'attend. Un autre exemple en est que, pour obtenir un volume nouvellement formaté reconnu, Windows vous oblige également à démonter le volume (selon les notes ici ), ce qui signifie que, même si vous avez acquis une serrure sur le Volume, vous n'avez d'autre choix que de le renoncer à garder Windows heureux. Par conséquent, alors qu'il existe de nombreux cas où Rufus ne voudrait rien de plus que de garder une serrure au lecteur pour prévenir les interférences externes, Microsoft a conçu leur système d'exploitation de manière à ce que nous ne puissions pas faire cela, ce qui ouvre bien sûr la porte pour Le genre de problème que vous avez observé.
Il suffit de noter que, selon votre message, il est peu probable qu'il soit réellement Explorer.exe lui-même c'est la question, comme le (r) Vous voyez signifie qu'il ne peut que demander un accès en lecture, ce qui ne devrait pas empêcher Rufus d'obtenir un accès exclusif au volume. Très probablement, le conflit réel provient de l'un des processus ou des services de Windows internes, suffisamment de haut niveau qu'elles ne peuvent pas être répertoriées (tandis que Rufus essaie de vous aider en répertoriant les processus qui accédent au lecteur, il n'y a que tant que cela peut faire Les processus privilégiés Windows, qui sont incroyablement difficiles à énumérer). Très probablement, vous voudrez vérifier que vous n'utilisez pas l'une des applications énumérées à la touche fin de la FAQ Rufus , car certaines d'entre elles sont connues pour être un peu trop déclenchées heureuses avec accéder aux volumes qu'ils ne devraient pas accéder quand ils n'ont aucune affaire à le faire.
Alternativement, depuis ironiquement, votre problème est probablement le résultat de Rufus ne pouvant être capable de "bloquer ce périphérique tout en l'utilisant" (en ne pouvant pas obtenir le Verrouillage exclusif Il demande de conserver d'autres applications de la baie), vous voudrez peut-être appuyer sur Alt-, (c'est le alt et virgule clés) à Rufus, de sorte qu'il ne va pas essayer de verrouiller des lecteurs.
Bien sûr, si vous le faites, il y a toujours un risque que tout autre processus essaie également d'accéder à ladite lecteur pourrait la modifier en même temps que Rufus effectue ses opérations, ce qui pourrait entraîner des données corrompues ou un lecteur inébranlable ( Quelle est la raison précise pour laquelle Rufus demande un verrou exclusif par défaut) ...
J'espère que cela pourra aider.