cbaud2000

Difficile de préciser davantage, car il faudrait pour cela que je retrouve le fil de discussion où j'ai pioché cet avis, et je ne suis pas capable de m'en souvenir assez exactement pour le répéter ici. Le simple transfert de mes données sur le DD2 prend plus de temps que prévu, car lorsque je lance une série de déplacements qui devraient prendre 2 ou 3h, si je quitte le poste de travail, je peux être à peu près certain qu'au bout de 10 minutes, l'explorateur me proposera des options pour résoudre une difficulté, et s'il n'y a personne pour répondre, je retrouve 2 heures après le bazar pratiquement au même point que lorsque je l'ai quitté. Si donc je suis forcé de rester devant mon écran, j'en profite pour faire le tri dans le contenu des transferts et alors là…ça peut durer ! Je reviendrai demain donner le résultat de cette tentative.

D'abord la nouvelle du jour : j'ai pu récupérer le Windows 10 Famille sur le DD2 de mon précédent post, d'une manière inattendue. En effet, je voulais transférer les données restant sur ce disque sur un disque externe, et pour ce faire, j'ai démarré (en forçant le lancement en UEFI) un DVD bootable MACRIUM REFLECT, programme de backup qui permet la copie de partitions ; or, il propose aussi un outil de réparation de boot (que j'avais oublié) que j'ai utilisé à tout hasard...et qui s'est révélé efficace, le système acceptant de se lancer au redémarrage. Toutefois toujours avec cette lenteur extravagante qui montre qu'il y a tout de même là-dedans quelque chose d'anormal. Le PC n'a pas de marque car c'est un assemblage personnel, qui s'est composé de façon un peu hétéroclite. Le modèle de la CM : Gigabyte GA 78LMT-USB3 (n° de version indisponible). Ce soir, j'aurais tendance à penser qu'elle supporte bien l'UEFI, puisque le BIOS permet d'autoriser ou non le démarrage des CD/DVD d'une part, des périphériques USB d'autre part, en Legacy ; de plus, tu pourras voir sur cette capture d'écran que si l'on fait un clic droit dans la gestion du disque sous Windows, les options de conversion sont les suivantes : "convertir en disque dynamique" que l'on retrouve dans tous les cas, et "conversion en disque MBR" qui n'est disponible que si le disque est installé en UEFI ; dans le cas contraire, on trouverait "Conversion en disque GPT". Je libère sur le DD2 la partition de 437 Go (données) que je pourrais utiliser pour faire une tentative d'installation de Windows 10 Pro, ce qui finirait de me confirmer que ma CM supporte l'UEFI. En effet, j'ai lu quelque part que si l'on essaie de faire une install en UEFI d'un OS qui était auparavant sur ce même disque en GPT, ça merde souvent, ce qui pourrait expliquer mes échecs précédents. Donc, je pourrais changer mon organisation, essayer d'installer le W10 Pro 1803 sur le DD2 à la place où étaient les données, et si ça marche, j'effacerai ensuite le W10 Famille sur l'autre partition. Il ne me resterait plus qu'à convertir le DD1 en GPT, en effaçant le W10 Pro qu'il contient, et je retrouverais les capacités de stockage que je voulais ajouter, réparties sur 2 disques au lieu d'être sur un seul. Comme je suis en train de faire le transfert de mes données du DD2 sur le disque externe, je ne peux pas l'interrompre et ne peux donc pas te faire les photos des onglets du BIOS (je t'en avais jointes deux hier), mais en revanche, je te joins la documentation complète de la CM. mb_manual_ga-78lmt-usb3_v.4.1_e.pdf

Oui bien sûr ! Voici la liste des disques dans DISKPART : DD 0 : le Toshiba en GPT de 3 To, ne contenant que des données (mais il a hébergé un OS Linux, enlevé) DD 1 : le Seagate en MBR de 500 Go avec le Windows 10 Pro x64 que je voulais récupérer dès le début DD 2 : le Hitachi 2.5 en GPT de 1 To avec le Windows 10 Famille x64 provenant d'un laptop HP Envy m6-1162sf DD 3 : la clé bootable, évidemment. On voit sur la liste des partitions que le DD1 ne contient que 2 partitions : l'une de 549 Mo créée à l'installation avec l'étiquette "réservée au système", l'autre de 292 Go contenant le W10 Pro à l'origine de ce topic. Sur le DD0, il existe en fait des partitions cachées qui sont des résidus d'une ancienne installation d'un OS Linux ; il n'y en a que 3 visibles, la 3 de 488 Go étant sous BitLocker, et le reste n'est pas alloué. Enfin, le DD2 ne contient que deux grandes partitions, la 4 de 468 Go hébergeant le W10Famille et la 6 de 437 Go ne contenant que des données. Cette dernière est la seule partition que j'ai créée, toutes les autres étaient là dès l'origine (quand j'ai acheté le PC), ou bien ont été ajoutées au cours des migrations W8>W8.1>W10 : celle de 23 Go abrite le système initial (Windows 8) de secours, et je ne sais pas à quoi servent les autres, notamment les trois dites de récupération, puisque je n'ai jamais effectué de réinstallation sur ce disque, l'OS ayant évolué au cours de 4 ans par mises à jour et mises à niveau successives. À propos de la CM, tu as raison : mes doutes n'ont aucun sens. Ils proviennent essentiellement de plusieurs expériences malheureuses, à savoir des tentatives d'installation (presque toujours sur le DD1), dans la configuration où il ne restait qu'un seul disque, que j'ai voulu faire en UEFI après avoir converti le disque en GPT, à partir de clés bootables dûment paramétrées pour installation en UEFI, qui se sont toutes heurtées à un refus, précisément parce que mon disque était en GPT. J'en ai déduit, par dépit, qu'il y avait un os avec cette maudite CM, et pourtant si elle arrive à faire tourner le DD2, c'est véritablement qu'elle est adaptée UEFI tout en étant compatible avec le LEGACY. Du reste le fichier joint (CM_mentions-EFI.pdf) contient 3 captures d'écran du BIOS montrant les seules occurrences où l'on voit apparaître le mot EFI. J'ai aussi téléchargé le manuel complet de cette CM, que je ne joins pas maintenant (il pèse > 12 Mo), mais que je peux me débrouiller pour mettre à ta disposition. De fait, si je suis obligé de réinstaller de W10 Pro, j'aimerais bien le faire en UEFI, ce qui rendrait mon système plus homogène et pourrait sans doute supprimer des sources de problèmes. Pourtant, je suis presque certain, si je le tente encore dans les mêmes conditions, d'aboutir au même résultat. Merci pour ta patience. CM_mentions-EFI.pdf

Voici le BCDEDIT /v réalisé sur le C du W10 Pro que je voulais récupérer dès le début, dans la config 1 seul disque. Pour ma part, je ne vois pas où est l'erreur. Pourtant, BOOTREC m'a donné le même résultat que celui retranscrit dans le post de vendredi dernier à 0h42 : Nombre d'installations Windows identifiées : 0. Pardon pour mes tentatives dans la config 3 disques : je rappelle que deux seulement accueillent un OS (Windows tous les deux, 1 Famille sur le 2.5 provenant d'un portable (capacité: 1 To), 1 Pro sur celui que je veux restaurer depuis le début (capacité : 500 Go) avec l'intention, quand ce serait fait, d'effacer le W10 Famille pour récupérer de l'espace de stockage. Le troisième disque, un Toshiba de 3 To en GPT, ne sert que de stockage, mais garde des traces (un grub 2) d'une ancienne installation Linux retirée depuis longtemps. Mais c'est quasiment le plus important pour moi, car il stocke des données dont j'ai besoin pour faire un certain travail, et c'est pourquoi je le connecte quand j'ai des chances de démarrer un OS. Pour l'instant, ce n'est plus le cas, et je sens que nous nous dirigeons gentiment vers une réinstallation complète. Il me reste à faire la tentative de réparation via BOOTREC sur le disque de 1 To avec le W10 Famille, toujours en config 1 disque, mais là j'ai un doute : ce disque est en GPT, et l'installation de l'OS a été faite en UEFI. Alors les procédures de réparation sont-elles identiques ?

Je reprends là où nous en étions : voici d'abord le retour de DISKPARTdans la config 1 seul disque, démarrage sur clé d'installation. Ensuite, j'ai exécuté exactement les lignes de commandes copiées dans mon précédent post, ce qui a donné ce retour de BOOTREC. Ce dernier montre une différence que j'ai cru importante par rapport à mes tentatives antérieures : BOOTREC cette fois a trouvé mon système...c'est un progrès ! Cependant, il paraît encore insuffisant car au redémarrage (toujours sur la même config), j'ai retrouvé le BSOD habituel, avec la même cause (inaccessible boot device). Pour tenter encore quelque chose, j'ai voulu faire un Boot-Repair qui s'est révélé pire qu'inefficace, puisque maintenant, dans une config à 3 disques, j'arrive également sur un BSOD (même motif), et ne peux donc plus rien lancer. À toute fin utile, je joins les 2 rapports de Boot-Info : l'un avant exécution de Boot-Repair, l'autre après (le second à la suite du premier dans un seul fichier .PDF).

L'essai relaté dans mon post d'hier n'est pas très encourageant, puisque BOOTREC n'identifie aucun OS sur le disque où il se trouve. De toute manière, je ne pourrai tenter quelque chose de ce genre que demain, car pour l'instant mon PC tourne avec 3 disques, et qu'il faut donc que je l'éteigne et le rallume après en avoir débranché 2. Je me propose d'essayer la séquence suivante : bcdedit /export C:\BCD_Backup c: cd boot attrib bcd -s -h -r ren c:\boot\bcd bcd.old bootrec /RebuildBcd Pour me dérouter un peu plus, voici le rapport BOOT-INFO exécuté ce jour dans la configuration un seul disque (sda évidemment), où je ne distingue plus rien d'anormal. Qu'en penses-tu ?

C'est bien sûr ce que j'ai fait (redémarrer après l'opération), pardon de ne l'avoir pas précisé. Hélas, j'ai été accueilli par le même BSOD qu'auparavant. Puisque le Boot-info transmis dans mon avant-dernier message stipulait dans son sommaire : => No boot loader is installed in the MBR of /dev/sdb. => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sdc. => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sdh. => libparted MBR boot code is installed in the MBR of /dev/sdi. et que c'est précisément sur ce disque que se trouve l'OS que je veux démarrer, j'aimerais savoir comment je dois m'y prendre pour replacer un boot loader dans la MBR de ce disque. Il est évident que s'il n'y en a pas, je ne pourrai jamais le démarrer.

Voici le retour scrupuleusement retranscrit : X:\Sources>bootrec.exe /rebuildbcd Recherche d'installations Windows sur tous les disques. (il n'y en a qu'un) Veuillez patienter... Les installations de Windows ont été analysées. Nombre d'installations Windows identifiées : 0 L'opération a réussi. (on apprécie l'humour) X:\Sources>bootrec.exe /fixmbr L'opération a réussi. X:\Sources>bootrec /fixboot Accès refusé. Lorsque j'avais essayé il y a quelques jours, je m'étais arrêté à la première commande après avoir constaté qu'aucune installation n'était détectée, ce qui est bien sûr absurde. J'ajoute que j'ai aussi tenté la commande suivante : bcdboot c:\windows /l fr-FR /s c: suivie de la confirmation que le fichier de démarrage avait été copié avec succès. Je ne saisis pas la logique, par conséquent, je ne sais vraiment pas quoi faire.

Merci à toi Calisto06 ! Je crois avoir déjà essayé ces commandes depuis une clé d'installation W10, mais sans succès. Toutefois, comme je ne souviens plus du retour exact, je vais répéter l'opération afin d'en noter précisément le résultat. En attendant, voici un rapport de boot-info qui me paraît apporter une information capitale, dès la ligne 6. Je précise qu'il a été réalisé avec les deux disques durs connectés, et que celui que je tiens à restaurer est le sdc, l'OS étant installé sur sdc2, et sdc1 étant la partition réservée au système. Je pensais que le bootloader était le fichier winload.exe (en legacy) qu'on trouve dans :C\Windows\System32\ ; apparemment, ça n'est pas ça. Du coup, saurais-tu me dire quel fichier il faut que je recopie, et où exactement ? Merci d'avance. Salutations.

Bonjour, Sur un PC de bureau tournant sous Windows 10 Pro x64 (version 1803) et équipé de deux DD, j’ai ajouté récemment un troisième disque dur 2.5 de 1 To provenant d’un PC portable (HP Envy 1162 sf) sur lequel j’avais remplacé ce disque par un SSD de 500Go. Cet ajout était destiné à me procurer de l’espace de stockage supplémentaire, mais dans un premier temps, j’avais besoin de faire tourner son OS (Windows 10 Famille x64 également 1803), que je n’avais pas encore effacé. C’est donc ce que j’ai fait, en ajoutant par Boot-Repair une entrée au Grub2 déjà présent, souvenir d’un dual boot avec un OS Linux qui n’est plus présent. Effectivement, j’ai pu lancer le W10 Famille venant du portable, difficilement du reste puisque le système était anormalement lent, mais en revanche, impossible de revenir sur le W10 Pro : en cours de démarrage, je suis accueilli par un BSOD "INACCESSIBLE BOOT DEVICE". J'ai cherché à réparer le démarrage à l'aide d'une clé bootable d'installation de Windows 10 1803, mais sans succès (soit dit en passant, cette supposée réparation du démarrage n'a jamais fonctionné avec moi). Sur cette même clé, j'avais d'autres utilitaires embarqués, tels que FALCON 4, HIREN'S BOOT etc qui n'ont pas réussi non plus à résoudre le problème. Un CHKDSK s'est achevé sur la notification suivante : "Windows a analysé le système de fichiers sans trouver de problème. Aucune autre action n'est requise". En dernier lieu, je télécharge le live CD de 98ffe08d, l'installe sur une autre clé, et démarre le PC à partir de cette clé, en ayant au préalable débranché le disque de 1 To du portable, et là je fais deux constatations. La carte-mère de mon PC ne supporte apparemment pas l'UEFI, comme on peut le voir ici ou bien encore là, alors que l'OS W10 Famille venant du portable est précisément en UEFI, sur le disque de 1 To en GPT ; j'ai dit qu'il tournait avec difficulté sur le PC desktop…mais il fonctionne tout de même. Que signifie cette évidente contradiction ? Ensuite, on peut voir sur le FRST.txt (lignes 293 à 296) que 4 fichiers .dll sont pointés comme manquants ; pourtant, un SFC /SCANNOW ne révèle aucune "violation d'intégrité". Dois-je remplacer ces fichiers absents par ceux que je trouverai sur la clé d'installation de W10 Pro, ou dois-je croire le diagnostic de SFC, et ne rien faire du tout ? J'ajoute que EASYBCD embarqué dans le live CD de 98ffe08d ne fonctionne pas sur ma machine, et affiche la notification suivante : "The processor detected is not supported. AMD FX™-6300 Six-Core Processor". Merci d'avance à quiconque voudra bien m'éclairer sur ces points, et m'aider à récupérer le boot de mon W10 Pro.

Oui très probablement, car c'est cette clé qui m'avait servi pour réinstaller l'OS Windows 10 Pro dans sa version 1803. Je ne peux pas tirer de conclusion logique de mes essais, puisque je ne distingue pas les différences de conditions entre échecs et réussite. Par exemple, mon utilitaire de démarrage manuel a encore fonctionné tout à l'heure (sans réussir à faire démarrer le Windows 10 Pro), mais Macrium Backup, qui avait fonctionné hier, ne s'est pas lancé aujourd'hui. Cette incohérence a forcément une raison, mais je sèche. Je me demande du reste si tout ça n'aurait pas un rapport, justement, avec ma carte-mère (Gigabyte GA-78LMT-USB3) dont je n'arrive pas à établir clairement si elle est UEFI, Legacy (MBR), ou bien un curieux hybride. Je n'ai pu effectuer ma dernière réinstallation qu'en mode MBR : ça ne voulait pas marcher en UEFI. J'ai été obligé de recommencer la clé (avec YUMI ou RUFUS, je ne sais plus) pour faire l'install en MBR, alors que j'avais l'intention de profiter de l'occasion pour mettre tous mes disques en GPT. Dans la configuration présente, j'en ai deux en GPT et deux en MBR, et W10 tourne sur un MBR, parce que j'y ai été forcé. À noter tout de même que l'autre W10 que j'utilise en ce moment, qui provient d'un autre PC, tourne sur un disque en GPT, et a toujours fonctionné dans un appareil entièrement UEFI. Les utilitaires d'analyse des composants sont incapables, tout comme moi, d'identifier la version de cette carte, comme on peut voir ici avec SPECCY, ou encore là sous forme de texte. Salutations cordiales

Décidément, je ne suis pas sorti de l'auberge ! Lorsque j'ai démarré ce soir, l'OS s'est montré moins conciliant qu'hier, et a recommencé à bouder tous mes CD/DVD, quels qu'ils soient. En réalité, en écoutant bien, je note qu'à l'introduction d'un CD dans le lecteur (n'importe lequel), il y a bien avec un certain retard une tentative de démarrage du lecteur, mais qui retombe presque aussitôt, et c'est après ce qui apparaît comme un renoncement à tourner que surgit la notification : "insérez un disque...". Je redémarre pour changer une option dans le BIOS (lancer les CD/DVD en mode EFI, NON-EFI ou AUTO), et cette fois j'obtiens un superbe BSOD (ne trouve plus de "Boot Device"). J'essaie alors de démarrer sur un live CD sous Linux permettant d'opérer un boot manuel, mais il ne se lance pas (probablement pas le temps) et on repasse sur le DD d'amorçage habituel, avec le même BSOD à chaque fois. Un autre essai avec une clé bootable contenant le Windows installé se termine de la même façon. En revanche, le CD de récupération d'une image système (MACRIUM Backup, pour répondre à Firebird) se lance correctement, mais je ne vais pas chercher la dernière image sauvegardée, trop ancienne à mon goût, qui m'obligerait à refaire tout un chemin de mises à jour et mises à niveau. Pourquoi ce CD est-il accepté, et lui seul ? À moins que ce soit un hasard... En fait, je comprends de moins en moins. Pour écrire ce post, j'ai redémarré sur un DD 2.5 provenant d'un portable HP Envy (actuellement chez un réparateur pour changement de la dalle) et équipé d'un Windows 10 Famille 1803, que j'avais remplacé par un SSD. Par bonheur, je n'avais pas encore effacé la partition système pour récupérer de l'espace. Mais il a mis un quart d'heure avant d'être utilisable. Une question à Roro : qu'entend-il par Windows apps ? Suite au prochain numéro. Salutations à tous.

De toute manière, comme la voie de la restauration était bouchée, j'ai au contraire exécuté une mise à jour (de qualité : KB4345421) avant d'éteindre. Lorsque j'ai rallumé, j'ai refait un essai, et cette fois, j'ai obtenu une notification différente : "Une erreur s'est produite lors de l'éjection de Lecteur DVD RW (M:)" ; mais après un temps de réflexion de 2 ou 3 secondes, l'explorateur de fichiers s'est tout de même décidé à afficher le contenu du DVD (audio), et j'ai pu en faire jouer le contenu. Même notification lorsque j'éjecte le support. J'ai testé les deux lecteurs : même comportement. En revanche, échec sur un DVD de données (même notif qu'auparavant). Comprenne qui pourra ! Lors de ces essais, je n'avais pas encore lu le post de Firebird (merci à lui ou elle), à qui je réponds que le service de diagnostic n'a rien détecté ; pour les Upper et LowerFilters, j'utilise la recherche pour trouver la bonne UID, et effectivement, je n'en ai trouvé que deux qui appartenaient à la classe des lecteurs optiques, où j'ai supprimé les deux filtres après sauvegarde de la clé "CLASS". Nous verrons si ça va encore mieux après ça, mais pour moi l'essentiel était de retrouver les fonctionnalités audio. Pour les données, je n'en grave que sur des disques bootables, et je n'ai pas encore testé si mes outils de dépannage étaient affectés par cette étrangeté. Donc, soulagé mais pas très confiant, et surtout je n'ai pas bien compris les causes. Salutations cordiales.

Pour l'instant, le résultat est très décevant : après le dernier redémarrage suivant la restauration (au 11/07/2018, avant une mise à jour critique dont je ne trouve pas trace dans l'historique), le PC a pédalé dans le vide pendant une bonne demi-heure avant que je l'arrête. Je le démarre ensuite normalement et voici ce que j'obtiens : Cette histoire commence à me faire peur. Je ne sais pas trop si je dois insister pour tenter d'exécuter cette restauration, car je n'ai pas d'autre point de restauration, comme je le craignais eu égard à la fraîcheur de l'OS.

Juste avant la première fantaisie, je venais de les sortir tous les deux pour modifier la disposition des jumpers afin d'intervertir leurs emplacements. Au premier démarrage après cette modification, seul l'un des deux lecteurs optiques était visible dans le BIOS. Je n'ai rien fait immédiatement parce d'autres urgences s'imposaient, puis quand j'ai rallumé le PC le lendemain, les 2 lecteurs apparaissaient bien dans le BIOS...mais n'étaient plus fonctionnels. Maintenant, j'essaie une restauration me ramenant si possible avant ce bidouillage, et je reviens donner le résultat.

Bonjour, Sur un PC de bureau sous Windows 10 Pro (1803 version 17134.165), deux lecteurs de CD/DVD sont installés, tous les deux présents dans le BIOS, et également dans le gestionnaire de périphériques, pour lequel tout est en ordre (pas de point d'exclamation ou de triangle). Pourtant, lorsqu'on introduit dedans un CD ou un DVD (vidéo, audio ou données), ils ne le reconnaissent pas, et la seule notification que j'obtiens est : "Insérez un disque dans le lecteur X". J'ai déjà procédé aux mises à jour des drivers (recherchées chez les fabricants) ; j'ai aussi essayé de laisser Windows se charger de ce problème en désinstallant les deux lecteurs dans le gestionnaire de périphériques, et en redémarrant...aucun changement ! Quelqu'un aurait-il une idée de ce qui se passe ?

Je crois qu'il y a une méthode pour déplacer l'emplacement par défaut, en intervenant sur le registre, et j'ai pu le vérifier. Cependant, je ne l'ai pas fait parce que je risque fort de ne plus me rappeler cette manipulation, qui peut se révéler pénalisante en cas de bidouillage, ajout, remplacement ou changement de DD. Lorsque je veux faire suivre d'un PC à l'autre les fichiers de données qui m'intéressent, je me contente de les importer, et je me retrouve avec exactement les mêmes sur les deux machines. D'habitude, je n'aime pas laisser des dossiers auxquels je tiens sur le C:\ (j'ai le même dossier par défaut que toi), mais je recopie régulièrement les dossiers importants du C:\...\Appdata\local\ dans mes bibliothèques et pour l'instant, je n'ai pas eu à souffrir de pertes. Merci pour ta contribution.

Pas de quoi, Carmen ! N'empêche que je n'avais pas été fichu de trouver tout seul l'origine de l'anomalie. Il a fallu cet échange sur le forum pour m'indiquer où il fallait regarder. Merci et bonne journée.

Pour en finir avec ce sujet, il s'agissait bien de cela car, après une désinstallation minutieuse de QTTabBar, l'explorateur de fichiers a retrouvé sa configuration précédente, c'est-à-dire que l'onglet "Emplacement" des "Propriétés" dans le menu contextuel des fichiers/dossiers, qui était absent avec QTTabBar, a réapparu. Bon à savoir ! Avant la désinstallation, j'avais pu opérer les réglages qui ont replacé mes bibliothèques là où je les voulais, en paramétrant le registre à l'endroit suivant : HKEY_CURRENT_USER>Software>Microsoft>Windows>CurrentVersion>Explorer>User Shell Folders. Pour retrouver la possibilité d'afficher dans une même fenêtre deux emplacements distincts de l'arborescence, je me servirai de MultiCommander, qui offre en plus une foule de fonctionnalités. Salutations cordiales.

Merci pour cette suggestion, Carmen, à laquelle je n'avais pas pensé. Il se pourrait bien, en effet, que mon explorateur ait été modifié par l'addition il y a quelques mois d'un petit utilitaire : QTTabBar, qui permet d'ouvrir plusieurs onglets dans la même fenêtre de l'explorateur, à la manière de DOLPHIN dans LINUX-UBUNTU, ce que je trouve extrêmement commode. Cependant, comme cette QTTabBar n'était pas visible, ces derniers temps, parce que son affichage n'était pas activé dans les paramètres de l'explorateur, je l'avais perdu de vue, et ne me rappelais plus son existence. Il faut donc que je supprime ce module pour voir ce que ça donne. Je m'occuperai de cela ce soir ; pour l'instant, je ne me souviens même plus si c'est un programme installé ou portable. Pourtant, il doit être installé puisque, compte tenu de son nom, il nécessitait l'ajout d'une bibliothèque Qt, certainement pas native dans Windows 10. Je reviendrai ici donner le résultat de la tentative.

Bonjour, Après la dernière mise à niveau vers la version 1803 (17134.48) de Windows 10 Pro, j'ai observé que dans l'explorateur de fichiers, lorsqu'on affiche les propriétés d'un fichier ou d'un dossier dans le menu contextuel, l'onglet "emplacement" a disparu, si bien que je ne sais plus comment déplacer les dossiers de ma bibliothèque (documents, musique, pictures, téléchargements, vidéos) vers l'emplacement de mon choix (en fait : un disque dur différent de celui qui héberge le système). Quelqu'un pourrait-il m'indiquer une autre solution, simple de préférence, pour opérer ce déplacement, et pendant que nous y sommes, m'éclairer sur les raisons qui ont motivé cette nouveauté (suppression de l'onglet "emplacement") ? Question subsidiaire : les fichiers Outlook (*.pst et *.ost) sont par défaut stockés dans deux endroits possibles : C:\Utilisateurs\Utilisateur\Local\Microsoft\Outlook, ou bien le dossier "Outlook files" dans les "Documents" de la Bibliothèque. À votre avis, quel est l'emplacement le plus judicieux ? Merci d'avance. Salutations cordiales.

Bonjour à tous. Dans un sujet précédent, j'avais eu l'occasion de décrire le matériel qui me cause des soucis aujourd'hui. Et à ce propos, puisque ledit sujet n'avait pas été clos, je précise que j'ai en définitive procédé à une réinstallation complète, ce qui ne peut pas être considéré comme une solution satisfaisante, puisque c'est justement ce que je voulais éviter, et qu'ainsi, je ne faisais que contourner mon problème sans le résoudre à proprement parler. Le problème que je rencontre maintenant est du reste probablement cousin du précédent sus évoqué : dans le but d'avoir un ensemble plus homogène, j'ai voulu procéder à une réorganisation de mes disques durs (soyon,s franc : après un superbe BSOD annonçant une erreur fatale), en éliminant le plus petit (vieux MAXTOR de 80 Go sur la grosse nappe IDE, en esclave du lecteur de CD/DVD) sur lequel tournait un OS Linux, et en conservant les trois autres mais en convertissant deux (encore en MBR) en GPT (le troisième étant déjà en GPT). Pour ce faire, j'ai mis sur une clé bootable, à l'aide de YUMI, un Windows 10 Pro x64 1709 tout neuf, auquel j'ai ajouté HBCD (Hiren's Boot CD). J'ai démarré le PC avec cette clé, et exécuté la conversion des deux SEAGATE, 150 Go (destiné à l'OS Linux) et 500 Go (destiné à Windows 10), en GPT à l'aide de PartitionMagic (inclus dans HBCD) ; cela fait, j'ai redémarré sur la clé et installé cette fois Windows 10 sur le SEAGATE 500. L'installation s'est opérée sans difficulté, mais au redémarrage, pas de boot ! Je dois donc redémarrer sur la clé en lui demandant ensuite de me remettre sur le "main HDD" pour revenir dans mon Windows. En fouillant un peu pour comprendre les causes de cette bizarrerie, je m'apertçois que : Le SEAGATE 500 est toujours en MBR, malgré la conversion qui s'était pourtant "terminée avec succès" ; La raison du refus de booter sur le disque dur vient de l'absence du MAXTOR débranché : le BIOS déclare en effet qu'il ne peut trouver "76b3XXXXXXXXXXXX...." qui représentait l'ID de ce disque, et refuse en conséquence d'aller plus loin. D'où ma question : y avait-il une précaution à prendre avant de déconnecter ce disque (par suite de sa conversion en GPT, il était en espace non alloué) ? Ou bien suis-je condamné à conserver à tout jamais ce disque devenu inutile pour satisfaire les exigences à mon sens capricieuses de la carte-mère ? Quant à la conversion, j'aurai d'autres moyens d'y parvenir lorsque mes deux OS seront installés, puisque certains logiciels de souvegarde-restauration comme AOMEI ou MACRIUM permettent (en principe ; il faudra vérifier à l'usage) de restaurer en GPT une image-système sauvegardée en MBR. Cependant, j'aimerais bien tout de même comprendre ce qui s'est passé. Je précise encore sur ce point que le deuxième DD (SEAGATE 150 Go) converti par le même procédé est bien resté en GPT (il n'y a plus rien dessus : "espace non alloué").

Tout cela, bien entendu, je l'ai essayé, et je n'avais pas laissé le BIOS en "automatique", mais avais coché "EFI". Effectivement, j'ai aussi trouvé des traces de ces ennuis relatés dans divers forums, et lu qu'il fallait procéder dans ce sens pour les installations en multiboot. Aussi, c'est ce que je vais faire en réinstallant maintenant mon Kubuntu dans un autre emplacement, bien qu'il soit toujours accessible (pas directement car je n'ai pas reconstruit le multiboot, mais par un live DVD de boot manuel), si possible à partir de Windows. Je regrette que le développement de WUBI soit arrêté, et que son emploi ne soit plus trop conseillé à l'heure actuelle. Merci pour ce coup de main. Salutations cordiales.

De retour avec un petit peu de retard, j'ai donc effectué l'opération exactement comme je l'ai décrite dans mon post précédent, et selon les prescriptions du PoissonClown, en prenant même soin de télécharger une nouvelle image ISO toute neuve....et j'ai obtenu exactement le même résultat qu'auparavant, c'est-à-dire qu'au moment de désigner le disque sur lequel je voulais installer mon OS (préalablement "cleané" et converti en GPT), une notification m'informe que l'installation est impossible, précisément parce que le disque est "du genre GPT", ce qui m'avait déjà fait sursauter la première fois que je l'avais lue. Fatigué par cet énième échec, j'ai remis ce disque en MBR, débranché les 3 autres, et procédé à l'installation de la seule manière apparemment autorisée par ce PC (il faut même que je laisse le disque entier en espace non alloué : il ne m'a pas permis de le partitionner, comme il eût été logique de le faire, n'ayant tout ne même pas besoin de 500 Go pour faire tourner Windows 10 Pro). J'ai l'impression que je ne suis pas à la veille de comprendre le pourquoi de cette affaire. Maintenant que le Windows est réinstallé proprement, il me reste à remettre en route le LINUX, que je profiterai de l'occasion pour déplacer ; heureusement, ça devrait se révéler beaucoup plus rapide. Comme dit plus haut, les OS LINUX ne m'ont jamais fait ce genre de grimaces, et ils permettent d'arranger à mon gré les partitions sur le disque système. Le mystère demeurant entier, je reste à l'affût de toute explication. Salutations cordiales.

C'est très probablement le cas, en effet, car effectivement, je me suis servi de l'outil Microsoft pour préparer ma clé USB d'installation, et je l'ai fait à partir de du PC à réinstaller. Par conséquent, je vais refaire l'opération, mais en recréant la clef d'installation (avec Yumi ou Rufus, par exemple) avec une ISO téléchargée de chez Microsoft (je pourrais du reste me servir de celle qui est déjà sur la clé, en m'assurant qu'elle contient bien, dans les sources, les options UEFI), cela depuis un laptop HP qui tourne sous Windows 10 en UEFI. Simplement, comme je suis actuellement en déplacement, je ne pourrai le faire qu'à mon retour chez moi, dans une petite semaine. Merci pour cette suggestion. Salutations cordiales.