cbaud2000

Bonjour, Depuis deux jours mon PC desktop, tournant sous Windows 10 1809 (ver 17763.253), affiche des BSOD (écran bleu) à chaque démarrage, pour des raisons apparemment inconstantes, puisqu’elles changent à chaque fois. Je n’ai souvent pas le temps de les noter, mais l’avant-dernière fois, c’était un fichier qui était pointé (« élément ayant échoué ») : amdppm.sys, et la dernière, c’était un mystérieux RapportCerberus64 (je cite de mémoire) qui semblait être en cause. J’ai tenté de situer amdppm.sys, et j’ai été surpris de constater qu’on ne le trouvait que dans windows.old, ce qui me conduit à me poser la question : après une réinstallation, des éléments situés dans ce dossier sont-ils encore actifs dans le fonctionnement de l’OS ? Cela dit, je n’ai guère confiance dans la cause des défaillances affichée sur le BSOD en raison de leur diversité : il m’en invente une différente à chaque occurrence. Bien entendu, j’ai mis en œuvre toutes les méthodes habituelles pour déceler une possible infection : néant ! J’ai même été surpris que Malewarebytes antimalware ne détecte aucune menace, pas davantage qu’Emisoft. J’ai aussi vérifié chez AMD que le driver de mon processeur (AMD FX 6300 3,5 GHz) était à jour. J’ai aussi désinstallé hier la dernière mise à jour (KB4487044) qui avait précédé l’apparition du premier BSOD, mais sans résultat puisque celui-ci s’est reproduit aujourd’hui. De plus, SFC /scannow n’a décelé aucune anomalie, pas plus que ckhdsk. Du reste, concernant les disques durs (2 SSD + 2 HDD), CrystalDisk les a estimés en parfaite condition. J’ajoute que la BSOD ne se manifeste que dans les toutes premières minutes après le démarrage ; passé ce délai, l’OS fonctionne normalement. J’ai seulement remarqué que le processeur montrait un taux d’occupation anormalement élevé (à mon avis) pendant trop longtemps (cinq minutes environ) au démarrage, et par sursauts ensuite, sans que je ne le sollicite plus que pour écrire ce message, par exemple. Or, ces pics ne lui étaient pas habituels : ordinairement, son occupation était beaucoup moins capricieuse, et ne s’élevait pas souvent au-dessus de 50%. Quelqu’un aurait-il une idée de ce que je pourrais faire pour éliminer cet inquiétant symptôme ?

Pour finir, je dois avouer que j'ai manqué de confiance hier soir : il était tard et, pressé d'aller me coucher, je me suis contenté, au redémarrage, d'ouvrir le nouveau compte administrateur que je venais de créer, pour constater que ça marchait bien. Cependant, aujourd'hui, quand j'ai démarré le PC, j'ai ouvert une session sur l'ancien compte, et me suis aperçu que là également, tout était OK. Par conséquent, les réparations tentées, et injustement qualifiées d'infructueuses dans mon précédent post, avaient au contraire réussi. Voici le chemin suivi : Un vieux thread de 2012 sur Forum-seven m'avait fourni un lien vers une solution possible que j'avais déjà expérimentée il y a quelques mois pour résoudre avec succès le même problème, et qui consiste en réalité à faire une installation du même OS par dessus l'existant, en préservant tout, données et programmes installés. C'est un peu bourrin, mais ça fonctionne très bien...en ne résolvant pas vraiment le problème puisque ce dernier est réapparu quelques mois plus tard (il est vrai après une série de bidouillages dans l'organisation des disques de nature à perturber l'indexation). Avant de me résoudre à renouveler ce procédé, j'ai suivi un autre lien de ce même thread qui m'a conduit à une étude approfondie que l'on doit à un astucieux investigateur (Cool Raoul)...très instructive ! À la fin, on voit que les solutions suggérées ne sont pas bien différentes de celles proposées par le PoissonClown au début de cette discussion. Au bout du compte, je crois tout de même que les réparations décisives sont celles que j'ai trouvées dans un tuto de 98ffe08d (chapitre : "Réparer le service d'indexations de fichiers"), du reste également présent dans le forum de la communauté Microsoft. Je garderai quoi qu'il en soit le nouveau compte administrateur créé...ça peut toujours servir, et d'ailleurs, il en faut toujours au moins un deuxième. Bonsoir à tous ! Je mets le sujet en "Résolu".

OK, compris. Note bien que je n'utilise pas constamment la recherche, et qu'une certaine lenteur de cette fonctionnalité ne me dérangerait pas beaucoup. J'ai potassé avec attention tout ce qui était en rapport avec les liens que tu m'as transmis, et ça m'a d'ailleurs emmené assez loin. Pour l'instant, néanmoins, les réparations tentées d'après ces indications n'ont pas vraiment donné de résultats probants. Pire : il me semble que l'indisposition du PC s'aggrave, en ce sens que maintenant, il y a des applications qui ne se lancent plus du tout. Une piste quant aux causes possibles : ces temps derniers, j'ai beaucoup joué avec les disques internes, externes et un NAS, après avoir changé le disque système pour un SSD, et modifié complètement (pour plusieurs machines) les stratégies de stockage et de sauvegarde. Notamment, j'ai repartitionné complètement des disques et changé des lettres de lecteurs (avec AOMEI Assistant Pro), si bien que cela a pu perturber l'indexation qui ne s'y retrouve plus. Enfin, j'ai testé la création d'un nouveau compte administrateur (anonyme si je puis dire, c'est-à-dire sans compte Microsoft) et cette fois, je retrouve le comportement attendu, normal. Voilà qui est rassurant, parce que je peux toujours récupérer ici les spécificités de mon compte "User", et d'une certaine manière, enjamber le problème sans l'avoir véritablement résolu. Je n'abandonne cependant pas complètement l'entreprise de récupération, mais elle n'est plus une urgence première. Je reviendrai en rendre compte ici.

Merci pour tes conseils : je vais m'y atteler, dans l'ordre où tu me les as donnés. Cependant, un truc que j'ai du mal à comprendre : pourquoi le MultiCommander, que j'utilise autant que possible à la place de l'explorateur Windows, est-il encore capable de faire des recherches avec succès (et, soit dit en passant, d'une manière que je préfère à celle de l'explorateur maison) ? Il me semble qu'il est pourtant obligé d'utiliser Windows Search pour ce faire, non ? À bientôt pour te dire où j'en suis.

Bonjour, Je suis confronté à un problème récurrent concernant un dysfonctionnement essentiel de l'explorateur de fichiers : la plupart des options offertes par les onglets (Fichier Accueil Partage Affichage) ne sont pas disponibles (en grisé), et plus généralement, tout clic droit entraîne un plantage (l'explorateur ne répond plus, indéfiniment). J'ai déjà fait une réinstallation complète à cause de ce problème, et après deux mois, voilà qu'il surgit à nouveau. J'ajoute que SFC et DISM n'ont absolument rien trouvé d'anormal : intégrité totale du système. L'utilitaire de réparation affiche la réponse suivante : autorisations incorrectes sur le répertoire de données (variante : du service de recherche) ; non corrigé (capture d'écran ci-jointe). Ma question : comment faire pour rectifier ces autorisations, et où faut-il intervenir ? Salutations cordiales.

Je reprends le fil là où je l'avais laissé. Après avoir reçu le SSD commandé, j'ai choisi dans le BIOS le mode AHCI et pris toutes les options de lancement des CD/DVD et des clés USB en UEFI exclusivement, pour essayer d'installer W10 Pro en UEFI. Tout d'abord j'ai été fort dépité de constater que la CMOS ne "voyait" aucun disque, déduisant que mon essai allait s'arrêter là...mais non : j'ai tout de même démarré sur ma clé d'installation, qui, elle, a parfaitement reconnu le SSD, où j'ai créé une partition pour mon OS, et l'installation s'est parfaitement déroulée, conformément aux prédictions de calisto06. Et juste encore en ce qui concerne cette fichue carte-mère, car c'est en MBR que l'install s'est opérée. J'ai voulu faire une ultime vérification à ce propos, après avoir connecté sans aucun problème un second disque, le SEAGATE de 500 Go qui hébergeait le W10 Pro ; je l'ai converti en GPT (à ce sujet j'ai constaté qu'on pouvait le faire sans perte de données avec AOMEI Partition assistant Pro), et j'ai tenté une nouvelle installation…. qui a été refusée, au motif que mon disque était en GPT. Du reste, on peut voir dans le fichier joint que le résumé du système (msinfo32) donne le BIOS en Legacy. La question est donc réglée. J'avais douté de cette conclusion en me souvenant d'un tuto du Crabe, qui présentait plusieurs manières de déterminer si une CM était en mode UEFI, dont une, la première et la plus simple, consistait à regarder si le BIOS contenait le mot "UEFI" : dans l'affirmative, la CM était en mode UEFI. Cependant, je me demande alors à quoi exactement servent les options de la CM qui mentionnent EFI. Et surtout, comment se fait-il que le W10 Famille sur le DD Hitachi de 1 To venant du portable, intégralement et exclusivement en UEFI, a fonctionné pendant plus d'un mois sur ce PC (mal et lentement, il est vrai) ? En tout cas, je peux clore le sujet en le déclarant résolu, bien que la question à son origine n'ait été que contournée, sans vraiment recevoir de réponse directe.

Il me semble en effet que ce serait le plus simple, et le moins risqué. Quant à l'histoire le la carte-mère, j'ai interrogé GIGABYTE pour en avoir le cœur net et ils m'ont répondu ; je vous soumets notre échange dans le fichier joint, et vous me direz, si vous voulez, ce que vous en pensez. Pour ma part, je trouve la réponse un petit peu ambigüe, mais tout de même, je pencherais vers la capacité UEFI, car sinon, quelle serait le sens de cette option évoquée dans la réponse? Je la connaissais bien pour m'en être servi plusieurs fois, mais ne la trouvais pas assez "décisive" pour me faire une opinion définitive. Une autre question : dois-je formater au préalable le disque de 500 Go contenant le W10 Pro à effacer, que j'installerai en second, après le SSD, comme vous le décrivez ? Capacité UEFI.pdf

Oui c'est très juste ! Simplement, j'étais encore sur la lancée d'un problème de réparation de boot, et j'ai toujours des difficultés à l'abandonner sans avoir compris le pourquoi du comment. Cependant, l'efficacité commande de m'employer à élaborer une config propre, stable et aussi rapide que possible compte tenu des composants dont je dispose. Pour ce faire, dans l'optique d'une installation en AHCI, je m'efforce de trier mes données pour ne sauvegarder que ce qui en vaut la peine, et de disposer de disques prêts, donc vides. Pour ça, je n'ai besoin que de démarrer le Windows 10 Famille qui rame, mais qui est suffisant pour faire des transferts. Au fait, j'y pense : ce W10, dans le portable d'où il vient, était installé en AHCI. Je crois d'ailleurs que je n'installerai que deux DD dans la nouvelle config, au moins pour commencer : le SEAGATE de 500 Go sur lequel se trouve le W10 Pro qui sera effacé, et le SSD CRUCIAL de 480 Go que j'attends. Ces 2 disques suffiront pour contenir les données "vivantes" sur lesquelles je travaille, et je pourrai ensuite exécuter "à froid" les transferts et sauvegardes sur/de mes autres disques, un externe déjà en service, le NAS existant, et les disques internes écartés, connectés au moyen d'un dock que j'attends également. Par conséquent, dès maintenant, je suis prêt à réinstaller le SEAGATE de 500 Go, qui ne contient plus que l'OS W10 Pro que nous sacrifierons. Une question à ce propos : il a été sauvegardé (avec MACRIUM REFLECT) alors qu'il avait déjà ce problème de démarrage ; comme d'habitude dans une sauvegarde système, cette dernière contient deux partitions : la C de l'OS, et une petite de l'ordre de 500 Mo tagée "Réservée au système". La sauvegarde ayant été faite en MBR, ne serait-il pas possible, une fois exécutée une installation neuve en UEFI, de se servir seulement du C sauvegardé pour une restauration partielle qui me ferait gagner beaucoup de temps ? Cela me semble une manip assez improbable, mais ça ne coûte rien de poser la question.

Oui, n'est-ce pas ? J'en ai fait il y a quelques jours, sans trouver aucune anomalie, mais par acquit de conscience, je recommence et le même résultat est visible ici. Cela étant, j'arrête pour ce soir. Je reprendrai demain, mais pas avant le soir.

Bien compris ! À mon tour, je te montre les mêmes répertoires chez moi, et tu verras que si les fichiers DEFAULT, SAM, SECURITY, SOFTWARE et SYSTEM sont bien présents dans REGBAK, ils sont vides (0 octet).

Voilà, c'est fait, mais il semble que j'aboutis à une impossibilité !

C'est le C, partition de 292 Go !

Question pour LincolnFan93 : d: c'est la clé bootable, on est bien d'accord ? Pour plus de précision, voici ma config un seul disque, celui du W10 Pro à récupérer.

Oui je sais bien ! S'il en était besoin, je m'en aperçois encore mieux lorsque j'ai besoin de l'expliquer sur ce forum : un vrai casse-tête ! Alors évidemment, je suis OK pour une réinstall complète qui, de toute manière, est devenue quasi inévitable. Au fait, comme il y aura une petite interruption, le temps que je reçoive le matériel et que j'effectue mon petit ménage dans ce souk, est-ce qu'il ne vaudrait pas mieux que j'ouvre un autre topic quand je serai prêt pour m'y mettre ? Up to you !

Le mieux, évidemment, serait de l'installer sur le SSD à venir (480 Go). Pour l'heure, celui que j'essayais de récupérer, c'était le W10 Pro sur le DD 1 (Seagate MBR 500 Go), que j'ai perdu le jour où j'ai ajouté dans le PC le DD 2, le HITACHI UEFI 1 To qui venait d'un portable où je l'avais remplacé par un SSD. Il était encore équipé, sur une partition, d'un OS W10 Famille dans lequel j'avais besoin d'aller une ou deux fois. Après cela, je n'ai jamais pu revenir dans le W10 Pro, mais en revanche, j'ai eu l'accès (précaire, car perdu quelquefois) du W10 Famille, mais ramant épouvantablement, ce qui n'était pas tellement grave puisque j'attendais d'avoir terminé mes récupérations dans cette partition pour l'effacer complètement et affecter l'espace au stockage de données. Je précise que la plupart des tentatives faites pour retrouver le boot du W10 Pro l'ont été dans une configuration où je n'avais conservé que le seul disque qui héberge le système.

Oui, bien sûr. Je reprends une description faite page 1 : 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. Je commence par ailleurs le ménage, mais comme dit précédemment, cela risque de durer un peu, d'autant que je n'ai plus beaucoup d'espace de stockage externe, en dehors d'un NAS (mais les transferts sont lents)….je crains de lasser votre patience. De toute manière, comme je suis bloqué dans un trou, je suis obligé de me faire livrer mes achats par AMAZON ou consorts, et j'attends donc les miens.

Pardon à Delta, à qui je n'avais pas répondu. S'agissant du DD1 (cité dans la description incluse dans mon post du 29 août dernier), à savoir le DD de 500 Go en MBR hébergeant le W10 Pro dont j'essaie depuis le début de ce thread de récupérer le boot, je n'ai aucune donnée dessus, rien que l'OS. De toute manière, je sépare toujours la partition système des partitions de données, dont l'essentiel se trouve sur le DD0, le TOSHIBA en GPT de 3 To, qui ne sert qu'au stockage. Bien entendu, dans l'optique d'une réinstallation complète de l'ensemble en AHCI (dont j'ignore la procédure), c'est celui qui me posera le plus de problèmes, car il me faut trouver de la place ailleurs pour sauvegarder, même provisoirement, tout ce qu'il contient. En réalité, je n'ai certainement pas l'utilité de tout conserver, mais m'engager dans une opération de tri sélectif, pourtant maintenant quasi inévitable, m'effraie un peu en raison du temps qu'elle risque de prendre. Je vais acheter en même temps un dock (pour disques 3.5, 2.5 et IDE) de manière à avoir accès à tous les disques ; à terme, le HITACHI en UEFI de 1 To (avec le W10 Famille), par exemple, ne restera pas dans la tour, mais servira de stockage externe.

Effectivement, s'il y a un os avec l'option AHCI, il vaut mieux tout remettre à plat. De fait, j'ai voulu faire un "Clear CMOS" en ôtant la pile, et j'ai constaté que cette dernière (d'origine sur la CM : une cr 2032) ne fournissait plus que 0,18v, alors qu'elle est donnée pour 3v. Dommage qu'il n'y ait aucune alerte pour ce genre de défaillance, dont on ne peut se rendre compte qu'en enlevant la pile. Je l'ai donc remplacée par une neuve, mais en rallumant le PC, surprise : le disque dur (même config mono DD que la dernière fois) n'était plus détecté. La raison en était que la CM avait conservé en mémoire la dernière configuration que j'avais essayée et enregistrée (un seul disque et tentative de démarrage en mode AHCI), et qu'elle était donc repartie dans ce même mode, alors que l'option par défaut est : Native IDE. À propos de la CM, j'ai enfin pu déterminer qu'il s'agissait de la REV 5.0 : bizarre que les utilitaires ne parviennent pas à le savoir. Maintenant, je n'ai toujours pas de boot sur le W10 Pro, mais le BSOD a modifié son libellé. Pourtant, une vérification dans DISKPART m'a montré que cette fois, tout était en ordre : la partition de l'OS était bien active, avec la petite étoile, et portait la lettre C. Question incidente : comment dois-je faire pour remettre à l'heure le BIOS, qui affiche la date du 1er janvier 2012 ? Je ne peux agir qu'au moyen du clavier, et lorsque j'appuie sur "entrée" quand le focus se trouve sur la date ou l'heure, ce dernier se déplace seulement d'un cran, sans rien me proposer. D'accord avec le programme suggéré par Calisto06 : je vais profiter de l'attente de mon matériel pour récupérer tout ce qui doit l'être sur les disques qui devront probablement être reformatés, d'après ce que j'entrevois. Je sais par expérience que ce genre de bricolage absorbe pas mal de temps, mais aussi que ce n'est pas du temps perdu. Je risque toutefois de manquer de capacité de stockage pour mettre de côté toutes les données contenues dans le DD de 3 To, mais on verra ! Pas de problème pour les clés de licence etc. qui sont sauvegardées autrement.

Nos deux derniers posts se sont croisés : pas de problème !

Cela semble pourtant curieux, puisque dès le début, mon OS était un Seven Ultimate x64, suivi d'un Windows 10 Pro x64 insider preview avant la sortie officielle vers la mi-2015, et de toutes les versions successives jusqu'à la 1803, et toujours en x64, comme du reste les OS Linux (AMD 64) que j'ai installés en dualboot. Certes, on peut faire tourner des programmes en 32 bits sur une architecture 64, mais l'inverse est-il possible ?

Oui j'avais les deux sortes : un vieux MAXTOR de 80 Go, et tous les autres en SATA. J'ai ôté le MAXTOR, qui ne montrait aucune défaillance, parce qu'il n'était plus judicieux d'utiliser une baie pour un volume de stockage aussi faible, et aussi parce que je préférais utiliser l'unique nappe IDE pour les 2 lecteurs optiques (bien qu'il existe des adaptateurs IDE-SATA). La CM (Gigabyte GA-78LMT-USB3) a toujours été configurée, en ce qui concerne les options décrites dans mon post précédent, sur l'option par défaut, à savoir Native IDE. Comme l'option AHCI est présente, cela signifie qu'en principe, elle peut être activée, mais si je le fais, le BIOS ne "voit" plus aucun de mes DD (je n'ai pas encore le SSD). Ce PC n'a pas de marque, il a été assemblé à l'occasion de remplacements de composants, de façon un peu hétéroclite. La CM, le CPU (AMD FX-6300 Vishera) et la RAM (2 barrettes KINGSTONE DE 4Go) ont toutefois été achetés à peu près en même temps, il y a 4 ans.

J'ai affecté C à la partition Windows et rien à la partition winre, ensuite j'ai activé C....et ça n'a rien changé. J'ai aussi remarqué qu'en sortant de DISKPART, en revenant dans les options (continuer sur W10, options avancées, réparer le démarrage), puis en ouvrant de nouveau la console et en listant les partitions dans DISKPART, l'étoile avait encore disparu, et aucune partition n'était active. Tu avais donc raison pour l'histoire des lettres : ça n'a probablement guère d'importance. En revanche, si aucune partition n'est active, c'est plus embêtant, et ça ne risque pas de booter. Si les instructions données sous DISKPART n'ont aucune permanence et sont "oubliées" dans les deux minutes qui suivent, les moyens d'action se réduisent. Autre chose : si je choisis l'option AHCI dans Integrated Peripherals > OnChip SATA Type (3 options : Native IDE, RAID et AHCI ; Native IDE étant l'option par défaut), mon DD disparaît carrément de mon CMOS. Est-ce qu'il n'y aurait pas intérêt à réinitialiser le BIOS en enlevant et remettant la pile de la CM ?

Absent la semaine dernière ; pardon pour l'interruption ! Avec le recul pris pendant cet intervalle, je m'étais décidé à faire une réinstallation complète, mais sur un SDD à acheter, tant qu'à faire, et non sur la partition Datas de mon DD 2 (Hitachi avec le W10 Famille), car je m'étais aperçu que la sauvegarde desdites données était incomplète, si bien que je voulais préserver mes chances de récupérer les fichiers effacés en ne touchant pas à cette partition. En conséquence, je n'ai pas fait l'essai d'installation en UEFI sur cette partition. Revenu à la maison, et en attendant mon SSD, je fais à tout hasard un nouvel examen avec Diskpart de la configuration chargée avec le seul DD 1 (le Seagate 500 Go avec le W10 Pro qui ne boote plus), et là je vois que les lettres des volumes 2 et 3 sont inversées : C est attribué à la petite partition de 549 Mo (Réservé au système), tandis que E l'est à la partition qui héberge l'OS. Est-ce que ça ne peut pas suffire pour motiver le "Inaccessible boot device" ?

Pardon pour les captures ! Les voici réunies dans un fichier PDF (vérifié par mon antimalware EMISOFT), ce qui sera plus commode à consulter que neuf liens successifs. La configuration était celle à un seul disque, le DD2 avec le W10 Famille dont je viens de récupérer le boot. Ma tentative d'installation n'a pas encore été faite, car je viens seulement de finir mes nettoyages et transferts des données contenues dans la partition "DATAS" vers un disque externe. Au reste, il me semble bien que ma CM est la même, ou de la même série, que celle qui est photographiée dans un tuto du Crabe. J'ai oublié de préciser que le manuel de cette carte transmis il y a deux jours se rapportait à la version 4.1, qui semble la plus répandue, et c'est pourquoi je l'ai prise par défaut, puisque ni moi, ni aucun des utilitaires tels que SPECCY, SISOFT SANDRA ou CPUZ, ne sommes capables de l'identifier. Bon week-end et à + pour la suite. CM_Photos.pdf