Réparation Windows 10 problématique

[cbaud2000]

Bonjour,

Mon problème est apparu lorsque j'ai été invité (Windows insider) à réaliser la mise à niveau de la version 1607 (14393.1358) vers la version dite "Creator" 1703 : impossible de venir à bout de cette update ! Chaque tentative se soldait par un écran de ce genre. L'OS me signalait bien que le paramétrage de mon compte Windows Insider "requérait mon attention", mais sans précision complémentaire, si bien que je n'ai jamais compris ce qu'il convenait de modifier ; j'ai donc décider de désactiver cette option, de ne plus recevoir les Builds intermédiaires inabouties (depuis l'époque précédant la sortie de W10, ma curiosité s'était émoussée), et de m'en tenir aux versions stables.

Cependant, Windows Update ne me laissait pas en paix, et cherchait obstinément (en pratique chaque jour, à l'arrêt du PC) à installer les MàJs disponibles, notamment la KB 4025339, qui ne réussissaient jamais et se terminaient à chaque fois sur cette notification :

Citation

Impossible de terminer les mises à jour. Annulation des modifications. N'éteignez pas l'ordinateur.

Laquelle annulation reprenait au prochain démarrage, avec un redémarrage au passage (présence obligatoire, le PC étant en multiboot) : éteindre ou allumer la machine exigeait au total un bon quart d'heure. Pour éviter cela, j'ai apporté des modifications dans l'éditeur de stratégie (gpedit.msc), en arrêtant les MàJs de fonctionnalité et en ne conservant que les notifications des MàJs de qualité et de sécurité, et en choisissant l'option n° 2 : "notifier les téléchargements et les installations automatiques" dans ordinateur > Modèles d'administration > Composants Windows > Windows Update > Configuration du service mises à jour automatiques.

Ensuite, en parcourant tout ce que j'ai pu trouver sur ce sujet dans les tutoriels et les forums, j'ai pensé, après avoir essayé sans succès toutes les manières possibles et imaginables de ramener WU à de meilleurs sentiments, qu'il fallait probablement réparer des composants Windows détériorés, d'où le recours à SFC /Scannow et à DISM. Pour ce qui concerne SFC, j'ai obtenu dans le temps (c'est-à-dire au cours du mois écoulé) des résultats différents, le dernier en date ne détectant aucune anomalie, que je trouve donc inutile de fournir ici. Pour DISM, ils disent tous à peu près la même chose (fichiers sources introuvables) : celui du 24/07/2017, puis celui du 25, et enfin celui du 26. Or, je suis absolument formel : l'image ISO de mon Windows 1607, que j'ai montée en : N, est bien à l'emplacement indiqué dans ma commande, et ne contient dans le dossier "sources" qu'un fichier install.wim (et non .esd). Je joins ici le log CBS du 28/07/2017 : CBS_17-07-28.log, et le dernier, du 28 également, de DISM : dism_17-07-28.log. J'oublie de préciser que j'avais bien entendu utilisé l'utilitaire Windows de réparation de WU, dont voici le résultat datant du 28 juin dernier : Windows-Update_log_17-06-28.docx.

En lisant l'article cité en référence, il m'avait semblé avoir trouvé la solution idéale...hélas ! Voici ce que me notifie l'installateur en s'interrompant :

J'avoue que je commence à me lasser un peu, et que tout secours serait le bienvenu. Mon PC n'a rien de bien particulier, c'est un assemblage personnel pas très ancien, équipé de quatre disques durs. Cependant, j'ai déjà été obligé, pour installer la mise à niveau 1607 qui tourne actuellement, de procéder à une réinstallation complète, ce qui prouve que le problème rencontré maintenant existait probablement à ce moment. Du reste, je n'ai jamais pu procéder à une installation d'un OS Windows quel qu'il soit (depuis le 7 Ultimate qui était le premier sur ce PC) sans être obligé de débrancher manuellement les trois disques durs autres que celui sur lequel je voulais installer l'OS. Cela ne me semble pas tout à fait normal, alors que je ne rencontre aucune de ces difficultés avec les OS Linux installés en multiboot sur la même machine. S'agit-il là de coquetteries qui sont propres à Microsoft ?

Salutations cordiales

[Delta]

Slt,

Wouaw ... je dois bien avouer que avant de venir demander de l'aide vous avez combattu au corps pour tenter d'y arriver.

alors ma question est de vous demander les marques et série de votre carte mère etc. Je pense que cela vas nous aider.

 

et puis voir un peut se qui passe car une chose m’inquiète :

ceci :

il y a une heure, cbaud2000 a dit :

sans être obligé de débrancher manuellement les trois disques durs autres que celui sur lequel je voulais installer l'OS. Cela ne me semble pas tout à fait normal,

cela n'est pas normal du tout, car il est très fréquent de voir un ou deux voir 3 DD même 4 DD si ont possède 6 connexion SATA sur la carte mère, et cela ne dois pas posé de problème.

la seul chose qui me vient en tête directement, est ce que le DD ou vous désiré mettre le système windows est bien sur le SATA I. cela peut paraitre bête ... mais bon .. et voir dans le bios si il est bien renseigner et parametré

la suite ceci :

il y a une heure, cbaud2000 a dit :

Du reste, je n'ai jamais pu procéder à une installation d'un OS Windows quel qu'il soit (depuis le 7 Ultimate qui était le premier sur ce PC)

a savoir que Windows 7 ne requière pas de UEFI alors que 8 et 10 bien il le demande! alors si vous arriver juste a mettre 7 mais jamais su procéder a un OS plus récent tel que 8 et 10.. je me demande si vous en êtes équipé.

 

puis votre screen là plus haut windows cite qu'il ne peut pas déterminé si votre pc peut exécuté windows...

cela me parait assez ennuyeux

 

++

 

Modifié le 31 juillet 2017 par Delta

[Le PoissonClown]

Salut !

Quelle belle description détaillée !  Mes félicitations !

Pour la vérification des fichiers système, vu que la commande « sfc /scannow » ne retourne aucune erreur, tout va bien. Inutile de réécrire l'image DISM.

Si je résume :

Tu es en multiboot (GNU/Linux), et Windows 10 ne veux pas passer à la "build" suivante.

Je n'ai jamais testé le comportement de l'outil de M-À-J de version dans le cadre d'un multiboot, ça le perturbe peut-être.

As-tu essayé de faire la mise-à-jour depuis l'assistant du site Microsoft ?

Au pire des cas, une réinstallation depuis un support externe (DVD/Live-USB) comportant le support d'installation de la dernière version de Win10 devrait régler le souci normalement.

Bon courage pour ton souci et bonne journée.

[cbaud2000]

Merci pour vos réponses, et mille pardons pour mon retard à réagir (une courte absence).

Au PoissonClown, je précise que j'ai naturellement essayé d'utiliser l'assistant de Windows (creation-tool, je crois), mais sans plus de succès, bien que je ne me souvienne plus avec quelle notification il m'a signifié l'échec de la manœuvre. En revanche, je me rappelle très bien celle qui a mis fin à l'installation depuis un support externe (clé USB, en l'occurrence, sur laquelle j'avais chargé à l'aide de "WintoFlash" une image ISO dont le hash avait été vérifié) :

"The boot selection failed because a required device is inaccessible"

Ce qui m'amène à dire à Delta qu'il a probablement pointé quelque chose de sensible. D'abord je réponds à sa question: ma carte-mère st une Gigabyte GA 78LMT-USB3, qui supporte effectivement UEFI et Legacy, et est équipée d'une double connexion ATA (la grosse nappe pour connecter 2 lecteurs de CD/DVD, le plus souvent) et de 6 connections SATA ; socket M2, chipset AMD 780G (révision 00) ; southbridge AMD SB700 ; BIOS FA du 23/04/2013. Nulle part je n'ai trouvé d'indication sur la version de cette CM, du reste Speccy de Piriform ne peut renseigner que x.x.

Dans le BIOS, les disques apparaissent correctement, avec une petite bizarrerie tout de même : l'ensemble de ce PC ayant été constitué progressivement (mais la CM, le processeur, la carte graphique et les RAM sont de la même date : 2014) au gré de remplacements d'éléments antérieurs, il se trouve que le disque le plus ancien (un MAXTOR de 80 Gb), qui héberge un OS LINUX (Kubuntu 16.04) peu gourmand en espace se trouve sur la double connexion ATA (cavalier maître-esclave), avec un lecteur de CD/DVD ; or, à des moments où il a fallu toucher au multiboot en raison d'installations, je me suis aperçu qu'au démarrage, ce disque n'était pas présent dans le CMOS (je l'ai constaté parce que l'amorce de GRUB2 était sur ce disque), et qu'il réapparaissait après quelques secondes, le temps d'un redémarrage. J'ai cherché des explications à ce phénomène curieux, et même contraire à ce qu'on pourrait intuitivement attendre, mais je n'en ai pas trouvé sur les forums. Au demeurant, je n'ai pas insisté outre mesure, car il était facile de pallier cette fantaisie en changeant de place l'amorce de Grub2, que j'ai mise sur un disque plus constant.

Enfin, à propos d'UEFI, je dois ajouter que trois disques, dont les deux sur lesquels tournent les deux OS, sont en MBR, alors que le quatrième (un TOSHIBA de 3 To, d'où la nécessité de passer en GPT) est en GPT. Je laisse la CM se débrouiller toute seule, en choisissant l'option "automatique" pour le choix entre démarrage EFI ou NON-EFI des lecteurs. Mais il est possible que cet assemblage hétéroclite ait des effets secondaires indésirables (sur un autre forum, quelqu'un m'avait soutenu qu'une telle combinaison n'était pas possible), bien que la machine, dans les intermèdes entre deux mises à niveau, fonctionne parfaitement sous ses deux OS. La seule difficulté que j'ai parfois se rapporte, sous Linux, à la mise en réseau avec d'autres appareils (sous Windows ou MAC, un NAS aussi) : probablement une affaire dépendant de Samba qu'il faudra creuser dans un autre fil.

Ses précisions vous aideront-elles à affiner vos diagnostics ? c'est ce que j'espère.

Salutations cordiales.

Modifié le 3 août 2017 par cbaud2000
Fautes de frappe

[Delta]

il y a une heure, cbaud2000 a dit :

(un MAXTOR de 80 Gb), qui héberge un OS LINUX (Kubuntu 16.04) peu gourmand en espace se trouve sur la double connexion ATA (cavalier maître-esclave),

pas moyen de le deconnecté

je pense qu'il y a un probleme lié avec lui

 

+

[cbaud2000]

Il y a 16 heures, Delta a dit :

pas moyen de le deconnecté

je pense qu'il y a un probleme lié avec lui

 

+

Si bien sûr, ça n'est pas bien difficile : je vais faire une sauvegarde de mon système Kubuntu (ce soir seulement, car pour l'instant je travaille sur l'autre OS), que je serai ensuite en mesure de récupérer ailleurs. Ne serait-il pas opportun de profiter de la situation pour passer en GPT le disque, quel qu'il soit, sur lequel je déciderai de le placer ?

Un détail de plus : à chaque fois que je me suis servi de l'utilitaire (sous Linux) BootRepair, bien utile pour apporter des modifications au boot, il m'a demandé si ce disque (le vieux MAXTOR) était amovible ou pas, alors que la question ne s'est jamais posée pour les autres. Est-ce en raison de sa taille réduite, ou de sa connexion différente de celles des autres ? Je ne sais pas si c'est significatif.

Modifié le 4 août 2017 par cbaud2000

[Delta]

windows 8 et windows 10 sur un DD au format GPT en effet   car windows 8 et 10 vont avec le UEFI et GPT 

 

++

[cbaud2000]

Je me lance dans des grandes manœuvres, car la tâche n'est pas aussi aisée qu'attendu : je ne peux pas sauvegarder mon Kubuntu, actuellement sur un disque en MBR, sous la forme d'une image-système, car la restauration en UEFI ne sera pas possible ; le clonage de la partition système serait inopérante pour la même raison. Du reste, je constate sur les forums dédiés à Linux que la restauration d'une image-système n'est pas un procédé très courant. Il lui est souvent préféré une méthode consistant à réinstaller purement et simplement le système, le "Home" ayant été préalablement sauvegardé (le mien est de toute façon sur une partition séparée), de même que la liste des paquets installés (en fait toutes les applications non intégrées dans le système), qu'il est possible, semble-t-il, de réinstaller automatiquement au moyen de cette liste. Même si je devais le faire manuellement, ce serait tout de même beaucoup (vraiment beaucoup) plus rapide que sous Windows. C'est ce que je suis en train de faire.

Du coup, il va me falloir aussi déplacer mon OS Windows, et toujours en raison du problème susvisé (passage de MBR en GPT), les images-systèmes de sauvegarde que j'ai ne pourront pas me servir : je peux tout effacer ! Par conséquent, je ne peux pas échapper à une réinstallation complète, qui va me prendre un temps fou. Je vais quand même essayer de faire une sauvegarde des drivers,  ce sera toujours ça de gagné.

Tout ça pour dire qu'il faudra attendre un peu pour connaître la fin de l'histoire, d'autant plus que je dois m'absenter une quinzaine de jours dès lundi. Cependant, je viendrai ici faire part de mon expérience quand tout sera fini…et peut-être avant, car rien ne dit que je n'aurai pas besoin de vos lumières en cours de route.

Merci encore, et salutations cordiales.

[Le PoissonClown]

Ok. Désolé pour ce souci. Si ça avait été de simples données (et non un système), tu aurais pu faire une conversion sans perte.

Pour réinstaller d'un seul coup la plupart des logiciels courants, il y a Ninite qui est pas mal.

[cbaud2000]

Merci, le PoissonClown. S'agissant de la conversion sans perte, c'est exactement la méthode que j'ai suivie, décrite sur la page même que tu m'indiques. En réalité, je n'avais pas vraiment besoin de préserver les quelques données qui traînaient sur ce disque, sauvegardées de toute manière, mais je voulais tester ce procédé qui n'oblige pas à "cleaner" le disque, comme le fait DISKPART. Et ça marche parfaitement, comme j'ai pu le vérifier avec GPARTED, puis avec l'explorateur de fichiers, qui m'a confirmé que rien n'avait bougé.

Quant à NINITE dont j'ignorais absolument l'existence, c'est génial ce truc ! Bien sûr, ça ne réinstalle pas tout, mais ça représente tout de même un sacré gain de temps et d'énergie. Je suis ravi de cette découverte, grâce à toi. Pour les drivers, j'en ai fait une sauvegarde avec DRIVERBACKUP (de Sourceforge), qui promet aussi une réinstallation facile.

Cette dernière, pourtant, n'est pas encore commencée, car après avoir passé un disque de MSDOS en GPT (j'en laisse encore un pour faire tourner au moins un OS, en l'occurrence Windows 10) et déconnecté le plus ancien de mes DDs (sur lequel était installé Kubuntu 16.04), et en lançant pour installation un live DVD avec une ISO de Windows 10 1703 (15063.296), je n'obtiens, après quelques minutes, que cette notification sur écran bleu :

Recovery

There was a problem with a device connected to your PC.

An unexpected I/O error occured.

Error code : 0xc00000e9

This problem can happen when a removable storage device is removed while it's in use or is failing. Properly connecting any removable storage and restarting your PC may fix this problem.

Je n'attache pas grande importance aux codes d'erreur en général, car ils m'ont fait perdre trop de temps en vaines recherches, et j'ai pu constater que le même phénomène répété pouvait générer des codes d'erreur différents. Mais après tout, puisque on a booté sur un support externe (DVD), qu'est-ce que ça peut lui faire qu'il manque un disque ? Naturellement, je sais bien que mon boot est fusillé, mais en l'occurrence, on n'en a pas besoin. Pour accéder au Windows restant, je me sers d'un live CD Linux contenant un programme de boot manuel, qui détecte les systèmes installés, quels qu'ils soient. Inutile de réparer le boot avant d'avoir réinstallé mes deux OS.

Dernière question : comment se fait-il que Windows 10 Pro x64, supposé exiger l'UEFI, tourne depuis presque 3 ans (je recevais les builds "insider preview" avant la sortie officielle) sur un disque avec une table MBR, et presque parfaitement si l'on met de côté cette impossibilité de procéder à des mises à niveau ?

Je retourne à mes tentatives d'installation, et vous tiendrai au courant, bien qu'avec un délai de 10 à 15 jours, comme expliqué précédemment.

Salutations cordiales

 

[cbaud2000]

Entorse à mon planning, décalé d'un jour, qui me permet d'apporter un complément d'information, pas très réjouissant : que ce soit à partir d'un DVD ou d'une clé USB, absolument impossible d'installer Windows ! Sur le disque converti en GPT (conversion vérifiée avec GPARTED), j'obtiens une notification me disant en substance que je ne peux pas installer Windows sur ce disque parce qu'il est en GPT ; c'est le comble !  J'ai ensuite essayé sur un autre disque, cette fois en MBR, et là, il m'est de nouveau rappelé qu'il manque un lecteur à mon PC, comme expliqué dans mon précédent post. Revenu à l'emplacement initial, sur le disque reconverti en MBR, et après avoir reconnecté le MAXTOR, l'installation échoue une fois de plus avec cette notification :
Nous n'avons pas pu créer de partition, ni localiser une partition déjà existante. Pour plus d'information, voir les fichiers journaux d'installation.
En passant, ils sont où ces fichiers journaux ? Bref, j'ai tout essayé, aussi bien en vidant complètement le disque réservé à l'installation de Windows (espace non alloué), qu'en le préparant avec les partitions idoines, rien n'y a fait. Si bien qu'en désespoir de cause, j'ai débranché tous les autres disques, et cette fois, exactement comme pour les mises à niveau précédentes, l'installation a accepté de se faire sans anicroche. Et me voilà revenu à la même configuration qu'auparavant.

Le ‎04‎/‎08‎/‎2017 à 17:23, cbaud2000 a dit :

Si bien sûr, ça n'est pas bien difficile

S'appliquant à la déconnexion du disque MAXTOR, c'était un peu vite dit de ma part ! J'aimerais bien comprendre un jour le pourquoi de cette particularité tout de même un peu gênante.

Salutations cordiales

[Le PoissonClown]

il y a 43 minutes, cbaud2000 a dit :

j'obtiens une notification me disant en substance que je ne peux pas installer Windows sur ce disque parce qu'il est en GPT ; c'est le comble !

J'ai l'impression que certains média d'installation, s'ils sont créés avec l'outil de Microsoft depuis un Windows installé en MBR, ne peuvent installer qu'une version de Windows 10 pour disque dur en MBR (et inversement, en GPT, que pour du GPT).

Est-ce avec l'outil de Microsoft que tu as réalisé tes supports d'installation ?

Si oui, essayes ceci :
Récupères l'image .iso de Windows 10 comme indiqué ici. Puis répliques-la sur un DVD ou avec Rufus, sur ta clé USB.

Bon courage.

[cbaud2000]

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.

[cbaud2000]

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.

[Le PoissonClown]

Il y a 12 heures, cbaud2000 a dit :

Le mystère demeurant entier, je reste à l'affût de toute explication.

J'ai déjà constaté des soucis de compatibilité de Windows avec les partitions Linux. Et je ne me suis jamais aventuré à réinstaller Windows par-dessus ce type de multiboot. À lire les témoignages sur le Net, c'est une opération qui cause souvent des ennuis. Donc j'ai toujours commencé par installer les plus vieilles versions de Windows avant d'installer les plus récentes, puis finir par Linux.

Pour le reste, peut-être fallait-il tout simplement débrancher les 3 autres disques et laisser tout le disque en partition non-allouée, sans forcément remettre le disque en MBR. Ou alors, peut-être que la sélection automatique du mode BIOS choisissait "Legacy" et que du fait, le média d'installation ne voulait que du MBR (alors que le disque était en GPT)…

Voilà mon ressenti, mais vu les seules données que j'ai, je ne suis sûr de rien, désolé.

[cbaud2000]

Citation

Pour le reste, peut-être fallait-il tout simplement débrancher les 3 autres disques et laisser tout le disque en partition non-allouée, sans forcément remettre le disque en MBR. Ou alors, peut-être que la sélection automatique du mode BIOS choisissait "Legacy" et que du fait, le média d'installation ne voulait que du MBR (alors que le disque était en GPT)…

Tout cela, bien entendu, je l'ai essayé, et je n'avais pas laissé le BIOS en "automatique", mais avais coché "EFI".

Il y a 3 heures, Le PoissonClown a dit :

J'ai déjà constaté des soucis de compatibilité de Windows avec les partitions Linux. Et je ne me suis jamais aventuré à réinstaller Windows par-dessus ce type de multiboot. À lire les témoignages sur le Net, c'est une opération qui cause souvent des ennuis. Donc j'ai toujours commencé par installer les plus vieilles versions de Windows avant d'installer les plus récentes, puis finir par Linux.

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.