cbaud2000

Voici la notification qui s'affiche lorsque j'essaie la connexion FTP : encore cette fichue question d'autorisation, que je ne sais plus par quel bout attraper. J'ai fait l'essai sur les deux IP du PC Desktop (l'une pour le WiFi, l'autre pour l'Ethernet), et j'obtiens le même résultat dans les deux cas. Je voudrais explorer l'autre option de connexion (pour l'ouverture de session), à savoir le mot de passe, mais lorsque je clique sur "Se connecter avec le mot de passe de votre compte" dans Paramètres > Comptes > Options de connexion, il ne se passe rien ; la seule option disponible semble être "Modifier", qui m'envoie vers une modification du mot de passe de mon compte Microsoft, ce qui ne m'enchante guère, et surtout qui ne répond pas du tout à mes préoccupations du moment. Sur les deux machines, j'ai aussi un autre compte utilisateur (administrateur), le même, par prudence, dont pour l'instant je n'ai jamais eu à me servir. Comme ce ne sont pas des comptes Microsoft, les sessions s'ouvrent avec un mot de passe, là encore le même. Je ferai donc une autre tentative demain en me servant de ces comptes, afin de voir si j'ai une autre réaction. Merci pour ton aide.

Oui effectivement, j'avais fini par récupérer assez de débit Internet pour voir tout ça, et j'ai suivi à la lettre le topo de ton lien (c'était sur le forum d'Aski, je crois)...hélas sans résultat visible. Quant au sujet de Pilatus, il est à développements multiples avec plein de renvois en liens... il faut assimiler ! Mais je vois là-dedans une piste assez claire : c'est la création d'un compte utilisateur administrateur avec mot de passe, le même sur les deux machines. Ce serait relativement simple, mais je me trouverais, cela fait, exactement dans la même situation que celle où je me trouve, puisque c'est déjà avec le même compte Microsoft que j'ouvre mes sessions sur les deux ordis. Cela amène une question : comme je bloque sur cette fichue autorisation, en dépit du fait que l'identification par mot de passe ait été désactivée dans les paramètres de partage (il y a là déjà quelque chose qui ne va pas), est-ce que ce ne serait pas en rapport avec le remplacement du mot de passe par un code PIN à 4 chiffres (là aussi, le même pour les deux) ? En effet, si le système attend un "vrai" mot de passe...bien sûr j'ai essayé celui de mon compte Microsoft mais ça ne marche pas. D'ailleurs, lors de mon dernier essai, je ne suis pas arrivé à obtenir une nouvelle fois la fenêtre de demande d'identification avec mot de passe ; au lieu de cela, voici ce que me dit l'outil de dépannage de Windows. Il n'y a aucune constance dans les motifs d'échec...c'est désespérant ! Face à tout ça, la solution du PoissonClown me paraissait intéressante, mais voici ce que j'obtiens successivement en installant le serveur FTP. J'hésite à m'embarquer plus loin, et n'ai pas très envie de toucher à mon routeur. Le seul fait que quelqu'un de sa compétence ait opté pour cette méthode, tout de même un peu détournée, démontre clairement que la gestion des réseaux sous Windows relève de la pire daube.

Avec un tel raccourci, voici ce que j'obtiens, et c'est comme ça depuis des années, même avec une bonne douzaine de réinstallations de part et d'autre. Je précise de nouveau que dans les options de partage, j'avais désactivé l'option mot de passe, et que j'ai essayé tous les mots de passe possibles et imaginables sans succès. Avec des OS Apple ou Linux, le réseau est configuré en 15 secondes, pratiquement sans intervention, mais chez Windows, j'ai toujours connu ce bazar incompréhensible et imprévisible. On comprendra pourquoi, de guerre las, j'utilise de préférence TeamViewer, et comme c'est parti, je pense qu'il vaudra mieux que je continue ainsi. En effet, pour couronner le tout, après avoir par acquit de conscience mis 4 services en démarrage automatique ("Découverte SSDP", "Hôte de périphérique UPnP", "Hôte du fournisseur de découverte de fonctions", et "Publication des ressources de découverte de fonctions"), et avoir remis tous mes dossiers de bibliothèques en partage pour "tout le monde", j'ai obtenu le résultat très intéressant que le Desktop, qui affichait le dossier Users>Public du portable, ne connaît plus du tout ce dernier (autrement que comme diffuseur de médias avec WMP). J'ai donc retrouvé une symétrie dans mon installation : les deux machines s'ignorent superbement. Cool ! L'outil de dépannage Windows, à partir du portable sous 1809, m'indique de son côté, en analysant le "partage de fichiers", qu'il s'agit d'une question d'autorisations, et qu'il ne peut pas réparer. Accessoirement, j'ai été chercher les deux fichiers mentionnés dans "Détails" à cette occasion (route.print.txt et ipconfig.all.txt), que je joins. ipconfig.all.txt route.print.txt

Je me suis peut-être mal exprimé, Le PoissonClown. Depuis le desktop en 1903, j'ai accès au dossier "Users" du portable et à ses développements, avec les dossiers "Documents publics", "Images publiques" etc. Par conséquent, c'est suffisant pour exécuter des transferts, à partir du poste de travail. Mais si je me trouve à l'étage du dessous avec le portable, je ne peux rien faire à partir de ce dernier, puisqu'il ne "perçoit" le desktop que comme un diffuseur de médias, et ne me donne donc aucun accès à aucun de ses documents. Pourtant, sauf erreur de ma part, tous les paramétrages sont identiques sur les deux machines. C'est cette dissymétrie que je n'arrive pas à expliquer, et encore moins à corriger.

Décidément je confirme : sans défaillance (d'après une courte expérience, il est vrai), le Windows 10 1903 du desktop affiche le portable sur son réseau, mais uniquement le dossier "Public" (ce qui peut suffire, en fait - juste quelque déplacements de plus), mais le Windows 10 1809 du portable n'affiche, de son côté, que la bibliothèque musique via WMP. Un détail à préciser : dans les fonctionnalités optionnelles de Windows du W10 1809 du portable, l'option "Support de partage de fichiers SMB 1.0/CIFS" est absente ; à la place, j'ai coché "SMB 1.0/CIFS File Sharing Support", option qu'on ne trouve pas dans le W10 1903.

Je profite d'un répit entre deux interruptions de la connexion Internet pour donner de mes nouvelles : tous mes réglages étaient conformes à ceux décrits dans le tuto du Forum d'Aski, à l'exception de deux d'entre eux. Sur le 1903 (desktop), la fonctionnalité Windows "Client SMB 1.0/CIFS" n'était pas activée ; Sur le 1809 (laptop), le démarrage du service "FDResPub" était manuel, et je l'ai mis en automatique. Pour l'instant, le 1903 m'affiche de façon régulière l'autre PC (le dossier "Users"), et c'est suffisant en fait puisque ça me permet de réaliser mes transferts. Reste à découvrir pourquoi le 1809 refuse de "voir" son confrère, mais ça reste du domaine de la curiosité intellectuelle. Tout de même, j'aime bien comprendre ! J'ai encore un truc à vérifier et je reviendrai donner le mot de la fin (enfin j'espère). Merci de votre aide.

Pour commencer, les versions de Windows 10 : build 18362.239 (1903) pour le desktop, alors que le laptop en est resté à la 17763.615 (1809). Ensuite, pour calisto06, j'ai effectivement un antimalware tiers en service (EMISOFT) ; je vais donc le désinstaller pour tester. La réponse à propos des drivers est plus difficile, car j'avais l'habitude de me servir de TLD, qui nécessite évidemment une connexion Internet, et il se trouve qu'aujourd'hui, je n'ai pratiquement pas de connexion, en raison de travaux assez importants dans la ville pour installer le câble. Du coup, depuis plusieurs mois, on connaît des interruptions assez fréquentes. À cet instant, SPEEDTEST n'est même pas en mesure d'établir la liaison, et ne peut donc rien mesurer. J'arrive pourtant à recevoir la radio, par conséquent je devrais pouvoir faire passer le présent post. Mais pour TLD, rien à faire ; j'ajoute à la suite la notification d'échec qu'il affiche et que je ne sais pas déchiffrer, mais je comprends pourquoi il ne peut pas faire son job. Si je veux installer d'autres programmes de mise à jour de drivers, je vais aussi avoir des problèmes de téléchargement, et il vaut mieux que je patiente jusqu'à demain. Je vais aussi étudier en détail le tuto mentionné par calisto06 ; en mettant le temps, il finira bien par s'afficher. En résumé la suite demain. Merci pour vos réponses. Salutations cordiales.

Bonjour, j'ai lu avec intérêt l'article "[TUTO] Installer un partage réseau de fichier sur un routeur LEDE / OpenWrt", mais je recherche en fait une information plus simple, sans aucune urgence au demeurant. Il y a sur mon réseau domestique un certain nombre d'appareils, qui se contrôlent plus ou moins aisément, parmi eux : une clé Chromecast et un NAS qui fonctionnent bien et sont toujours présents sur le réseau, deux appareils YAMAHA (lecteur de CD et ampli-tuner) à la connexion plus fantaisiste, des téléphones et tablettes (iOS et Android) qui sont ceux qui posent le moins de problème, et enfin deux PC (bureau et portable) sous Windows 10 dont le comportement en matière de réseau est imprévisible. Leur connexion au routeur et à Internet ne pose pas de problème particulier, mais c'est la connexion entre les deux PC qui est la plus incertaine. Or, c'est cette dernière qui est d'utilisation courante et quelquefois impérative, si bien que pour contourner les dysfonctionnements fréquents, je me sers de TeamViewer qui est une alternative absolument sûre. Toutefois, j'aimerais comprendre ce qui motive ces caprices : tantôt les deux PC ne se "voient" même pas en tant qu'ordinateurs (ils peuvent se détecter en tant que diffuseurs médias), et ne permettent donc pas l'accès de l'un à l'autre ; dans les cas les plus favorables, l'un des deux, toujours le même, affiche l'autre dans le dossier "Réseau", et donne accès à "Users > Public", sans réciprocité. Dans cette dernière configuration, je peux me débrouiller, au prix de quelques déplacements supplémentaires de fichiers/dossiers, et me dispenser de TeamViewer. Je précise que le paramétrage de "Réseau et partage" a été fait de manière à ce que tout soit le plus possible "ouvert" et qu'il reste inchangé. Existe-t-il un moyen, relativement simple, d'obtenir une configuration stable et constante ?

Assez logique, évidemment, philbisca ! Pourtant, ce n'est pas exactement ce qui se passe : en réalité, le service WindowsSearch est activé, mais tout simplement, il s'embourbe dans ses recherches, qui n'aboutissent jamais. Maintenant que Wise JetSearch peut assumer cette fonction, ce qu'il fait très bien, voici la réponse que j'obtiens lorsque je veux arrêter WindowsSearch avec services.msc. Et bien sûr, quand je cherche à connaître l'état de l'indexation, la fenêtre des options s'ouvre mais reste inerte et vide, ne réagissant à aucune commande, si bien qu'on ne peut même plus la fermer. Étrange, non ?

Everything, je l'avais déjà essayé il y a au moins 7 ou 8 mois, et je ne l'avais pas gardé, mais je ne me souviens plus pourquoi. De toute manière, c'est inutile puisque Wise JetSearch, que je ne connaissais pas, fonctionne à merveille, et avec une rapidité étonnante. C'est parfait car avec ça, je peux attendre tranquillement que la version 1903 de Windows 10 soit disponible. Cependant, même avec un explorateur de fichier qui aurait retrouvé toutes ses fonctionnalités, je serais tenté de conserver ce merveilleux petit outil. Merci mille fois à Yves B.

C'est assez vrai, rodriguem7973 : il y a peu à attendre pour avoir la 1903, et en faisant une réinstall par dessus, ça devrait résoudre le problème.

Bonjour, j'arrive sans doute un peu tard sur ce sujet, mais il m'arrive exactement la même chose : l'indexation qui bugge carrément, à tel point que je ne peux même plus fermer la fenêtre des options, et suis obligé à chaque fois de fermer la session, car je ne sais pas quoi chercher dans le gestionnaire de tâches (je ne trouve pas WindowsSearch). J'ai aussi essayé le truc de 98ffe08d, avec le fichier Reset.cmd de Subinacl, mais hélas sans succès. Un moment, j'ai imaginé que l'utilisation d'un explorateur tiers (MultiCommander en l'occurrence, que je trouve très commode dès qu'on doit opérer des transferts importants d'un disque à un autre) pouvait avoir causé des interférences néfastes, et je l'ai donc complètement désinstallé, mais le problème subsiste. Apparemment, un service est aussi impliqué dans ce processus : Windows.WARP.JITService, dont je ne connais pas la fonction. D'après ce que je vois dans le gestionnaire de tâches, il y a même plusieurs entrées, qui ont tendance à se multiplier, pour ce service. Si je n'ai pas d'autres possibilités, je me rangerai à la suggestion de Calisto, sans conviction pourtant, parce que pour l'instant, lorsque l'indexation est désactivée, aucune recherche n'aboutit (même au bout de 2 ou 3 heures), que ce soit sur le SSD, qui abrite l'OS et une partition de données, ou les 3 autres disques. Et ça m'ennuierait beaucoup de devoir me passer définitivement de la fonction de recherche. Alors si vous avez une idée...

Cette fois, décidément, le mal est réparé : quatre jours sans aucun incident. Je mets donc le sujet en résolu. Un gros merci à Calisto06, et une dernière info sur mes disques, où j'ai fait un peu de ménage, comme suggéré. Je ne touche pas au disk 2, qui héberge mon OS, et sur le Disk 1, où j'ai récupéré un espace non alloué, je laisse encore subsister un moment l'OS qui fonctionne, avec ses petites partitions système et amorçage, au cas où...juste une assurance pour mon portable (ce disque est un 2,5) car en cas de malheur, j'ai plus vite fait de remplacer son disque (cet OS provient du PC portable, donc pas de problème pour les drivers et tout le bazar) par un autre tout prêt que d'effectuer une restauration. Salutations cordiales.

Oui, c'est juste, ça fait un peu bazar, parce que ça n'a pas été constitué d'un coup, mais est au contraire le résultat d'une suite d'ajouts et de retraits dont je ne saurais même plus refaire l'historique. Bien sûr, je voulais tout installer en UEFI et c'est pour cette raison que j'avais converti tous les disques en GPT. Mais je crois me souvenir que avions eu un échange en 2018 à propos des spécifications de ma CM, pour conclure qu'elle n'était pas compatible EFI, bien qu'elle comporte une option (et une seule) EFI se rapportant au mode de lancement des CD/DVD. De fait, elle m'a toujours refusé l'installation en EFI, et à cause de cela, j'ai remis en Legacy le SSD accueillant le système. Je te concède que c'est un peu bâtard, mais est-ce que ça vaut le coup de changer la CM ? Il faudrait que je reste en AM3 si je ne veux pas racheter en même temps un nouveau processeur, et ça date déjà un peu ; idem pour la RAM en DDR3, alors que la norme est maintenant le DDR4. Bref, il vaut mieux maintenir une certaine cohérence, qui implique la simultanéité dans l'achat des principaux éléments (j'ai bonne mine de dire ça quand la caisse de ma tour doit avoir une vingtaine d'années). Cependant, la gestion du disque de 3To ne m'a jamais posé de problème. J'ai seulement remarqué que, si le MiniTool Partition Wizard voit bien les partitions de ce disque, il n'en va pas de même d'AOMEI Partition Assistant...jamais compris pourquoi. Quoi qu'il en soit, je vais de ce pas procéder aux modification que tu suggères, et profiter de la circonstance pour éliminer les petites partitions système devenues superflues.

Bien sûr...le gestionnaire de tâches ! Je suis vraiment nul de ne pas y avoir pensé. Effectivement, ça n'a pas été long : c'était WD Sync Service, l'un des logiciels du NAS (Western Digital), qui absorbait jusqu'à 55% ou 60% de la puissance du processeur exactement en phase avec les pics ; une fois ce processus arrêté, tout est rentré dans l'ordre. Pour le reste, j'avais déjà le Mini Tool Partition Wizard, qui m'affiche mes disques ainsi. Le disque 2 est celui qui héberge mon Windows 10 actif (C) et une partition de données (D). Le disque 1 (Hitachi 1 To) est l'ancien DD d'un portable que j'ai équipé d'un SSD, et où la partition (R) abrite toujours un OS (Windows 10 également) en état de marche, que je gardais par mesure de précaution pour pouvoir le remettre dans le portable en cas de catastrophe, mais que je pourrais tout de même effacer maintenant ; (S) est une partition de données. Le disque 3 ne contient plus qu'une partition de données (E), mais a autrefois hébergé un OS Windows, dont subsiste la petite partition de 549 Mo sans lettre dite "Réservé au système". Le disque 4 est le seul qui n'a jamais contenu d'OS, bien qu'à un certain moment, il ait été préparé en vue d'une installation à laquelle j'ai renoncé. Il n'y a donc pas de fichiers système résiduels à chercher dessus. En résumé, le 1 et le 3 contiennent des fichiers système qui s'affichent dans mon explorateur, toujours paramétré pour tout voir, et les petites partitions sans lettre (amorçage, récupération, réservé au système) qui sont restées intactes. Faut-il que j'efface tout ça ?

La première détection a été faite avec DriversCloud, qui avait trouvé 3 ou 4 mises à jour dont une se rapportant à un élément AMD (mon processeur) que j'ai eu la bêtise de ne pas noter. Aujourd'hui j'en ai fait une deuxième avec TLD avec deux résultats : une MàJ iilyama concernant mon écran, tout à fait inutile sur les OS récents ; et une autre plus intéressante relative encore une fois à AMD, datant du 26/10/2018, que je me suis empressé d'installer. À noter : juste après l'installation, l'explorateur de fichiers a ouvert automatiquement deux fenêtres sur deux partitions (les deux seules affectées d'une lettre) situées sur l'un des 4 disques (le seul apparaissant dans le BIOS). Comme expliqué rapidement quelque part plus haut, ces partitions étaient déjà présentes dans l'explorateur, pourtant, il a dû se passer quelque chose pour que celui-ci prenne l'initiative de cette réaction. Autre précision d'importance : aucun BSOD ou apparenté aujourd'hui lors de ces deux démarrages ! La seule différence que je peux constater avec la situation antérieure est ce curieux pic d'activité du processeur à 70% qui revient toutes les minutes (et non à 3 ou 4 minutes d'intervalle, comme je l'ai dit auparavant) avec une régularité de métronome, mais ne s'accompagne d'aucun ralentissement. Autrement dit, si on ne l'observe pas sur le graphe de performances, on ne s'en rend pas compte. Aucune idée de ce qui provoque ces spasmes. Si le système continue comme ça sans incident pendant 48h, je mets le topic en résolu.

Oui, le cerberus64 était bien une composante de TRUSTEER (IBM), conseillé par plusieurs banques d'après ce que j'ai pu voir et en tout cas la mienne, ce qui ne m'a pas empêché de le désinstaller. Voilà toujours une cause éliminée. Je n'ai pas AVAST. Mon antimalware était EMISOFT, mais il est désinstallé en ce moment, ainsi que MALEWAREBYTES. Je ne tourne donc que sous Windows Defender. Effectivement, calisto06, il s'agit du même PC que celui qui était en cause dans le topic que tu évoques. Et tu as raison pour la reinstall toujours possible ; je peux aussi faire une récupération à partir d'une image système sauvegardée il y a deux mois. Pour ces raisons, je ne me sens pas en danger, et puisque ce problème n'est pas pénalisant pour moi du fait que je peux continuer à travailler, j'aimerais bien attendre encore un peu pour essayer d'en venir à bout. Voici un rapport de WHOCRASHED qui met en évidence 3 origines possibles : rapportcerberus64_1930247.sys dont nous venons de parler, ntoskrnl.exe que nous connaissons comme une réponse par défaut non signifiante, et enfin usbohci.sys , le dernier dans l'ordre chronologique, que je découvre. C'est un OHCI miniport driver (fichier de 30 ko, daté du 15/09/2018), par conséquent un processus Windows que je ne peux pas supprimer, et qui est à jour selon toute vraisemblance. Que puis-je faire de cette information ?

Il paraît que j'ai, malheureusement, eu raison d'être prudent, car en démarrant aujourd'hui, après m'être absenté 3 ou 4 minutes, j'ai retrouvé un écran bleu (mais pas le BSOD) déclarant : "il semble que Windows ne se soit pas chargé correctement", et proposant les mêmes options qu'en bootant sur un disque d'installation, à savoir en substance éteindre, options de réparation etc. Je me suis contenté de redémarrer, et cette fois le processus s'est déroulé normalement. Toutefois, une notification s'est affichée, dont je ne saisis pas la signification exacte, mais dont je suppose qu'elle se rapporte à un petit utilitaire que j'utilisais ces temps derniers et qui affiche en permanence sur l'écran dans des petits rectangles à transparence réglable les courbes d'utilisation du CPU, de la RAM, des disques et de la connexion Internet. Or, je ne dispose plus que de deux rectangles : la mémoire et le flux Internet. Je désinstalle donc ce programme.

J'avais déjà fait une vérification de la RAM avec Memtest (peut-être un peu courte : près de 2 passes), qui n'avait décelé aucune erreur ; j'ai refait un démarrage avec CHKDSK /f à tout hasard. J'avais aussi voulu faire une vérification supplémentaire avec HDAT2, inclus dans un UBCD bootable, mais ce programme est resté scotché après avoir commencé à se lancer, et je n'ai pas eu la patience d'attendre plus de 10 minutes pour forcer l'arrêt. Peut-être qu'il ne supporte pas les SSD ? Du reste, une observation en passant : le BIOS n'affiche qu'un seul disque, d'ailleurs ajouté récemment (HITACHI 1 To), alors que qu'il y en a 4 sur le PC, dont 2 SSD. J'ajoute que les 4 apparaissent dans l'explorateur de fichiers, et que je les utilise régulièrement. Une explication ? Par ailleurs, j'ai fait analyser tous mes drivers et trouvé deux mises à jour, dont une concernant un élément AMD (je regrette de n'avoir pas noté le nom exact). Comme le dernier BSOD (hier dimanche) pointait comme défaillant un élément système où figurait le mot "cerberus" (rapportcerberus64), j'ai désinstallé le programme IBM TRUSTEER SECURITY auquel il se rapportait. J'ai aussi désinstallé complètement EMISOFT et MALEWAREBYTES. Entre tout ce qui précède et des essais infructueux de lancer l'OS en mode sans échec, après avoir désactivé les mots de passe (ce que le mode sans échec semble ignorer complètement), j'ai exécuté au moins une demi-douzaine de redémarrages aujourd'hui...sans aucun BSOD, alors qu'auparavant, il y en avait au moins un à chaque démarrage. De plus, je constate que l'activité du processeur affiche une courbe beaucoup plus raisonnable, bien que subsiste, lorsque le système n'est pas sollicité du tout, un pic à environ 70 % toutes les 3 ou 4 minutes, dont je ne vois pas la cause. Est-ce suffisant pour mettre ce thread en résolu ? J'ai envie d'attendre encore 24 heures.

La réponse se trouve dans mon post d'hier à 18h35 (4 messages plus haut en comptant le tien) : le minidump fournit une réponse bateau qui n'en est pas une, et il faut donc déchiffrer le MEMORY.dmp, qui fait 773 Mo. Pour ça, j'ai besoin de l'outil de débogage contenu dans le kit DSK, que je ne peux pas lancer, comme expliqué dans le post précédant le tien. Conclusion : je vais me coucher !

Encore une précision : après avoir connu beaucoup de difficultés au téléchargement en raison d'interruptions constantes de la connexion par mon opérateur (on installe en ce moment la fibre dans mon coin, avec pour résultat que nous ne l'avons pas encore, mais que le réseau cuivre est gravement perturbé et que pendant de longues périodes, nous n'avons plus d'internet du tout), je suis confronté à cette notification lorsque je veux lancer winsdksetup. Je me trouve donc bloqué et ne peux plus suivre le tuto. À tout hasard, si quelqu'un dispose des outils nécessaires pour déchiffrer les fichiers .dmp, je mets à sa disposition le MEMORY.DMP où se trouvent les informations que je cherche.

Un petit addendum au post précédent : le lien vers le minidump est assez inutile, puisqu'il ne permettra pas d'ouvrir le fichier, tout juste de le télécharger. C'était précisément pour être en mesure de l'exploiter que j'avais besoin d'installer SDK.

Mille pardons calisto06 : effectivement, le lien n'ouvre rien ! Essayons une nouvelle fois. Depuis hier, j'ai vérifié à tout hasard la mémoire vive avec Memtest, que j'ai arrêté à 180 % de couverture : 0 erreur. Puis j'ai voulu faire l'essai en mode sans échec, mais cette fois, autre ennui : le PC ne reconnaît pas mon mot de passe, qui est du reste un code PIN à 4 chiffres, alors même qu'en mode normal, il n'y a aucun problème ; étrange, non ? Idem pour le compte administrateur que j'avais créé justement pour des occasions analogues. Dans le BIOS, j'ai modifié la seule option disponible pour le mot de passe, sans observer le moindre changement. Ensuite, j'ai suivi pas à pas le tuto du Crabe traitant de la question des écrans bleus (c'est du reste le seul à ma connaissance qui le fasse de façon aussi détaillée, mais en termes compréhensibles), et j'ai ainsi pu localiser deux fichiers à exploiter : le minidump (021519-31890-01.dmp) de 1,18 Mo, et le MEMORY.DMP de 773 Mo. S'agissant de ce dernier, il faudra attendre un peu que je le téléverse chez un hébergeur qui accepte les fichiers de cette taille ; j'essaie chez MEGA, où j'ai un compte. Comme on peut le voir, je me trouve dans la plus mauvaise configuration, à savoir : la cause du BSOD est semble-t-il imputable à ntoskrnl.exe, et voici ce que dit le Crabe à ce propos : Par conséquent, je suis bon pour le téléchargement de SDK, indispensable pour interpréter le gros MEMORY.DMP, et là encore un problème : notification de l'échec du téléchargement. On peut en trouver le log ici. Je crois que je ne suis pas au bout de mes peines.

Merci à Delta pour les précisions à propos de windows.old. Mais justement, pourquoi ces fichiers sont-ils pointés, alors qu'ils se trouvent dans un dossier inactif ? Et dans la version précédente : non, je n'ai pas connu d'occurrence semblable. Bien sûr, j'ai eu des BSOD (peu nombreux, heureusement), mais ils étaient, si je puis dire, définitifs en ce sens qu'il était impossible de lancer l'OS. AMD se rapporte seulement à mon processeur. D'ailleurs, voici un aperçu général de mon système, suivi du détail concernant le processeur. Ensuite voici le rapport de ZHPDiag. Pour le redémarrage en mode sans échec, je vous demande d'attendre un peu, car je vais profiter un peu de ce que le PC fonctionne assez bien pour me laisser travailler (en dépit d'une courbe d'occupation des processeurs au relief très accidenté, pour ne pas dire erratique), et je reviendrai ici rendre compte de l'expérience, plus tard dans la nuit. Merci pour vos réactions très rapides.

Un petit ajout pour donner une idée de l'activité des processeurs, mesurée par l'outil de Windows, décidément tout à fait excessive, puisque correspondant à une période où je me servais d'un autre PC (portable), et où j'avais seulement laissé la radio en fonction sur celui dont il est question ici. Là, je me pose vraiment des questions.