Discussion :

[Trebly]

Bonjour,

Une machine tournant sous Windows 7 pro est tombée en panne. Je venais de transférer le système vers un disque SSD et je récupère au démarrage de Windows un BSD (tellement éphémère qu'il a fallu filmer à 50 images secondes pour capturer l'écran) qui est suivi d'un arrêt instantané. L'origine semble pouvoir être un driver vidéo, pourtant la machine fonctionne normalement lorsque l'on boot à partir du DVD d'installation ou à partir d'un DVD GPARTED (ubuntu)

J'ai essayé après remise en place du disque d'origine mais l'erreur est la même.

Le rapport d'erreur indique qu'il n'y a pas d'anomalie de BOOT et ensuite la trace d'erreur donne comme information utile "bad-driver".

Comme l'erreur se produit avec le disque d'origine on peut penser soit un problème matériel soit un problème de mise à jour Windows. Je penche pour le cas numéro 2 parce que l'ensemble des tests effectués avec des systèmes démarrant à partir du DVD ne montrent aucune anomalie.
La cause serait donc que après une mise à jour Windows (qui ne se serait pas terminé correctement, ou dont la phase de configuration après boot n'aurait pas démarré) un driver devienne incompatible.
Cette mise à jour aurait démarré automatiquement sans qu'un point de restauration ait été généré.

Problème N°1 : trouver et réparer un driver qui provoque un crash de Windows au démarrage en mode normal et en mode protégé

J'essaye de réparer en utilisant un DVD d'installation.
En mode "réparation" le système propose de "charger des pilotes".
J'ai créé sur un disque USB un répertoire comprenant tous les drivers, proposés sur le site ASUS pour ce Rogue G73SW (qui date de fin 2011 mais est en parfait état et reste un machine assez performante).

"Charger des pilotes" demande de choisir un répertoire, et (cela est assez prévisible) le message émis est « il n'y a aucune donnée correspondant à cette machine dans ce répertoire »

Pour ceux qui utilise Windows depuis ses origines, ce message est celui de l'installation de drivers à partir de fichiers «.inf » lorsqu'il n'y a pas de «.inf » ou des «.inf» ne correspondant pas au système.

Le téléchargement de drivers à partir du site ASUS permet de télécharger des fichiers zip comprenant des exécutables réalisant l'installation, en aucun cas des fichiers «.inf ».

J'ai pris contact avec l'assistance ASUS qui ne semble pas savoir ce qu'est le mode « réparation » sous Windows 7 et alors que j'expliquais que je cherchais à réparer l'installation m'a envoyé un « guide » (quelques lignes) expliquant comment réinstaller Windows en reformatant la partition courante ou en installant sur une autre partition.

Je pense ne pas pouvoir obtenir une assistance d'un niveau suffisant auprès d'ASUS. Mes interlocuteurs ne comprennent manifestement pas un mot sur 5 de ce que j'explique, leur rôle se borne à vérifier mon identité et m'envoyer un mail standard à partir de quelques mots-clés.

Pensez-vous qu'il existe un moyen de réparer des drivers à partir des téléchargements de l'assistance ASUS, sachant que des téléchargements qui semblent disponibles sont des exécutables qui supposent que Windows fonctionne ? Par conséquent en cas de panne de windows aucune "réparation" ne semblerait possible ?

Problème N°2 - Test matériel de la machine ASUS et re-installation des pilotes minima pour permettre un démarrage en mode protégé (permettant à son tour la mise à jour des pilotes à partir des exécutables fournis par ASUS)

Avez-vous une idée de la solution ?

Cordialement

Trebly
_____________________________________________________________________________________________________________________________
Nota : Cette machine sous Windows 7 est la seule à pouvoir me permettre d'exécuter un ordinateur virtuel (.VHD) créé par virtual PC et exécutant Windows XP SP3 sous lequel je peux exécuter des logiciels ayant entre 15 et 20 ans d'âge seuls capables de lire et d'exploiter (CAO) des données essentielles créées à l'époque et auxquelles j'ai besoin d'accéder aujourd'hui.

[JML19]

Bonsoir

As-tu testé un Démarrage en mode sans échec, F8 au démarrage juste après le BIOS il faut faire rapidement et essayer plusieurs fois ?

Normalement ton exe du pilote est un auto décompactable, il doit ce décompacter sur le disque C: avant l'installation.

Tu le fais sur un autre PC puis tu copies le dossier sur une clé USB ou même sur le disque dur du portable, si tu peux le mettre en second sur un autre PC.

Tu peux aussi le décompacter avec un clic droit sur ce fichier et cliquer sur l'option décompacter.

S'il s'agit du pilote NVidia du Chipset GT 460M tu peux essayer de désactiver ce Chipset dans le BIOS.

[Trebly]

Bonjour,

Je voulais réduire la question à un des aspects : "installer les drivers fournis par Asus", c'est pourquoi je n'ai pas donné d'autres informations sur le dépannage que j'essaye de mener à bien.

La question des drivers

Oui j'ai décompressé les drivers et j'y ai accès depuis un disque USB en mode "dépannage" (via un DVD d'installation).
La décompression des drivers (au moins la décompression du zip) ne mène à aucun ".inf" mais à un exécutable "setup.exe" et plusieurs dizaines de dll en général.
Bien qu'ayant quelques idées sur la question je n'ai pas de solution simple.

Maintenant revenons à la panne.

j'ai un BSOD dès le lancement de Windows que ce soit en normal ou en protégé.
Toutes les options de réparation échouent pour différentes raisons que je ne détaille pas ici.
La seule possibilité et le mode commande.

SFC m'a donné du fil à retordre par ce que pour obtenir le BSD Log quand l'exécution a lieu de manière externe il faut définir la variable d'environnement WINDOWS_TRACING_LOGFILE (set WINDOWS_TRACING_LOGFILE=<nom de fichier> fichier sur le disque externe USB par exemple. Sinon SFC ne produit rien (c'est pour cela que j'ai abandonné cette réparation il a 2 ans, laissé en plan et réinvesti dans une nouvelle machine), mais :
- comme j'exploitais sur ce win7pro virtualPC un ordinateur virtuel winXP SP3 et qu'il n'y a de solution pour récupérer (lire et exécuter) le VHD qu'avec l'environnement d'origine win7pro, je me suis lancé à nouveau il y a 8 jours dans le dépannage (j'ai sur le disque des exe spécifiques qui sont eux seuls capables de lire des données qui me sont aujourd'hui indispensables), à moins de reprendre des années de travail et de re-dépenser plusieurs dizaines de milliers d'euros que je n'ai pas... donc alors fin de l'histoire.

Finalement hier soir j'ai obtenu le BSD.log qui explique je pense la plantage de windows au démarrage.
Windows attend la dll mfc60.dll avec une signature (signature + hash) différente de la dll courante.
Comment cela s'est-il produit ? mais c'est la seule erreur détectée par SFC est celle là.

Nous sommes donc loin d'un problème de driver. A noter que l'écran BSOD s'affiche 1/50s et que j'ai pu le capturer grâce à un vidéo en 50i/s... Il signale un arrêt de sécurité mais ne donne pas de nom de driver, juste l'adresse de plantage.

L'erreur scannow (on est bien loin de la question de départ) est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
00010ec5 [SR] Verify complete
00010ec6 [SR] Verifying 1 components
00010ec7 [SR] Beginning Verify and Repair transaction
00010ec8 Hashes for file member \??\C:\Windows\WinSxS\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0\mfc90.dll do not match actual file [l:18{9}]"mfc90.dll" :
  Found: {l:20 b:vY9LxXwfveaKqgYArrDRlC18PG0=} Expected: {l:20 b:IIe4CNdBeX0YlGkOBxK7lNpivgg=}
  Found: {l:20 b:vY9LxXwfveaKqgYArrDRlC18PG0=} Expected: {l:20 b:J076fqQv2gkl6mddEI3ozBikssg=}
00010ec9 [SR] Cannot repair member file [l:18{9}]"mfc90.dll" of Microsoft.VC90.MFC, Version = 9.0.30729.4974, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral, PublicKeyToken = {l:8 b:1fc8b3b9a1e18e3b}, Type = [l:10{5}]"win32", TypeName neutral, PublicKey neutral in the store, hash mismatch

Je cherche donc le mfc90.dll attendu par le système... qui une fois copié au bon endroit aura des chance de supprimer la panne (dont l'origine reste totalement inexplicable)
Il s'agit donc de : "mfc90.dll" of Microsoft.VC90.MFC, Version = 9.0.30729.4974

Pourquoi le hash du fichier n'est plus conforme au hash référencé en bibliothèque ?


La question de départ reste cependant valide, parce que on ne voit pas l'utilité de la fonction de réparation "charger les drivers" s'ils n'existent pas sous la forme attendue. Cette fonction de réparation qui correspond aux mises à jour de drivers sur les systèmes jusqu'à XP devant alors caduque ; une panne de driver interdisant le démarrage y compris en mode protégé, rendant le système irréparable par une mise à jour "externe".

Cordialement

Trebly

[JML19]

Bonjour

Tu ne peux pas supprimer cette dll en la renommant .old ?

Tu auras surement une autre alarme mais pas un BSOD.

Pour renommer cette dll, il faudrait mettre le disque dur en second sur un autre ordinateur.

[chrtophe]

Tu as un BSOD car les pilotes disques sont profonds dans le système. et si tu changes de carte mère (ou de machine), ceux-ci seront différents. Tu peux t'en sortir en utilisant MergeIDE depuis un WinPE (possible depuis un simple iso d'installation), attention pas forcément à la portée d'un utilisateur standard.

Et attention, ceci sous réserve que ton problème ne soit pas lié au disque (par rapport à ton autre post sur les probs d'attribution de droits)

[Trebly]

Bonsoir,

WinPE ou le boot avec un DVD d'installation c'est la même chose.

Donc j'ai bien un système "X" qui gére réparation / installation et me donne accès au mode commande (et d'ailleurs la possibilité de charger des compléments d'environnement à partir d'un disque externe connecté en USB et une clef USB pour transférer facilement des données ou softs depuis une autre machine).

Il est prévu de renommer la dll courante qui donne un hash erroné (pourquoi ? c'est une autre histoire)

La dll mfc90.dll est la dll principale (Microsoft Foundation Classes pour MFC bibliothèque de base de C++ - Visual studio) du runtime C++ 2008. autrement dit sans elle on ne fait pas grand chose.
Celle qui est installée est la version SP1 (que je n'ai disponible nulle part : valide en 2008/09 : 9.0.30729.4974 et qui a fait l'objet d'une mise à jour de sécurité - origine du problème ? - la version 2019 étant : une 14.2 j'ai aussi la 30729 mais en sous version 9.0.30729.6161 - C++ 2012. Peut-être est-elle quelque part dans d'anciennes sauvegardes - je n'ai pas encore cherché j'ai quelque 40To, mais en rédigeant ça me donne une idée...). Il eu a eu de nombreux packages du runtime C++ avec des version différentes de cette dll, chaque machine en comportant plusieurs pour être compatible avec les différents soft Microsoft et autres - en fonction de la version de compilateur utilisée (sur ma machine sous win10pro il doit y en avoir 8 - durée de vie 20 ans mini - la plus ancienne datant de 1993)

Donc ce qui est prévu c'est de la renommer et de la remplacer immédiatement par la dll correcte, c'est à dire ayant un même hash. En effet si ça c'est facile à faire, réinstaller la version complète du runtime est une autre paire de manche (modifier aussi la base de registre mais aussi d'autres références introuvables). Noter que le N° de version figure dans le nom de répertoire de la MFC dans WinSxS.

En conclusion remplacer la dll par la bonne n'est rien à faire, mais sans la dll jamais la machine ne redémarrera correctement tellement cette MFC conditionne l'exécution du système.

Merci de votre aide, la seule question est de trouver cette dll.

Cordialement

Trebly

[chrtophe]

modifier une dll des redistributables Windows ne te permettra en rien de faire repartir ton système, elle n'est pas nécessaire à celui-ci mais aux applis s'appuyant dessus.
Comme déjà dit, regardes du coté de MergeIDE. Tu devras charger les ruches de la base de registre de l'OS planté depuis regedit du WinPE que tu trouveras dans C:\Windows\system32\config. Remplacer C par la lettre adéquate contenant. Une fois les modifs faites, il faut décharger proprement la ruche avant de quitter regedit.
C'est fourni avec un batch qui est sensé fonctionner tout seul, echec lors de ma première utilisation, je le fais donc à la main.

[Trebly]

Bonjour,

Merci de la réponse.

Mais la manip et MergeIDE sont censés réparer quoi ?

J'ai bien compris la manip.

Tu as donc diagnostiqué la panne, c'est quoi la panne que la manip est donc censée réparer ?

Cordialement

Trebly

[chrtophe]

MergeIDE va en gros mettre un pilote disque générique. Ça peut suffire ou non. Tu peux aussi avoir des services liés au chipset en général (exemple intelppm, processor) qui crashent (l'info BSOD permet de trouver lesquels), qu'il faut désactiver en chargeant la ruche du système planté depuis un WinPE.

Une fois que tu arrives à booter, le plug-n-play détectera les nouveaux composants, et tu pourras installer les bons pilotes;

[Trebly]

Bonjour,

J'ai trouvé la solution, j'ai réparé, la machine fonctionne maintenant parfaitement, je vous explique

• comment j'ai fait pour trouver l'(les)origine(s) du problème
• pourquoi il y avait ce BSOD
• pourquoi c'était si compliqué : où étaient les pièges

Historique et démarche

Pour éviter à celui qui s'intéresse à ce sujet de relire le long historique des messages j'en fais un résumé :
il y a 3 ans mon ordinateur principal un ASUS G73SW refuse de redémarrer avec un BSOD aussi bien en mode normal qu'en mode sans échec. Le log de démarrage et le mini dump ne sont pas générés. Ceci se produit alors que j'étais en train de changer le disque système. Je n'en sors pas, je suis contraint de mettre la machine à l'arrêt en attente de réparation.
Trois ans plus tard...
En filmant en 60 images secondes l'écran au démarrage j'ai pu récupérer l'affichage du BSOD (ne s'affiche que 1/50s), je trouve que le plantage intervient sur ndis.sys
L'analyse des fichiers de minidump ne donnait que très peu d'informations : l'adresse du crash ce qui a permis de retrouver qu'il s'agissait bien de ndis.sys et dans probablement un appel de fonction générique de ndis.sys invalide.
À partir de là le plus probable était que en amont un driver non identifiable appelait une fonction de ndis.sys de manière invalide, pourtant il n'y avait pas eu de mise à jour récente.

Pour réparer j'ai donc pris la décision de mettre un nouveau disque dur vierge et de refaire une installation nouvelle de Windows 7 pro (avec un DVD générique) ceci à fin de tester la machine (cas de défaillance matérielle).
La machine à redémarré sans problème, mais évidemment je n'avais pas tous les drivers utiles.
J'ai entrepris leur l'installation à partir de la bibliothèque « à jour » donnée par ASUS pour cette machine.

En pratiquant pas à pas, j'ai assez rapidement obtenu de nouveau la situation antérieure (BSOD général), mais j'avais la possibilité de faire marche arrière.
J'ai découvert que le driver WLAN récemment installé était certainement la cause et il était possible de démarrer en mode sans échec sans réseau, ce qui était nouveau.

Dès lors j'avais accès au paramétrage de la configuration de démarrage en utilisant le mode sélectif de config.sys. Le repérage du driver ou service défectueux devenait possible.
Il est nécessaire de faire une remarque à ce stade : les drivers et services sont listés dans l'ordre alphabétique de la traduction française (voir note1).
Je ne rentre pas dans le détail, mais assez rapidement je suis arrivé à un boot sans BSOD ce qui m'a donné un accès à beaucoup plus de fonctions et rapidement repérer les causes de la panne.

La cause

Il y avait en fait 2 causes toutes 2 provenant de défaillance des drivers ASUS,

1- le driver WLAN ne correspond pas au composant se trouvant sur la machine (le driver fourni par ASUS est pour un Intel alors que le composant est Atheros. J'ai donc installé le dernier driver à jour et tout est rentré dans l'ordre pour le WIFI
2- le drivers Realtek_card_reader proposé dans la bibliothèque ASUS est incompatible avec Windows 7 SP1 (la machine a été achetée en octobre 2011 et SP1 date 2 janvier 2012).

pourquoi c'était si compliqué : où étaient les pièges

Trois ans avant, il est probable qu'une mise à jour Windows datant du 20-25 si octobre 2016 ait transformé un dysfonctionnement (compatibilité active) en crash. Or j'étais en train d'effectuer le changement de disque (doubler la taille tout en passant en SSD). J'ai commis plusieurs erreurs :
- oublier de désactiver totalement les mises à jour de Windows pendant les opérations. (Lorsqu'ensuite j'ai voulu restaurer le disque dans des versions sauvegardées antérieures, je ne suis jamais arrivé à retrouver un système stable même en utilisant les points de restauration - je n'ai pas suffisamment de trace pour analyser le problème).
- face à une anomalie et pour conserver avant sauvegarde et substitution des disques, j'ai dû probablement faire une mise à jour générale des drivers à partir de la bibliothèque ASUS considérée de référence avec une confiance aveugle... en écrasant probablement des mises à jour intégrées aux mises à jour Windows et provoquant un retour arrière de près de 5 années.

- La mise à jour par ASUS de la bibliothèque de cette machine s'est semble-t-il arrêtée le jour où le modèle suivant est venu le remplacer. Ceci au point de la rendre incompatible avec la mise à jour Windows 7 SP1 qui a eu lieu 3 mois après la vente de la machine.

En conclusion,

Ne jamais utiliser les bibliothèques de référence correspondant aux machines (du moins chez ASUS), ceci rend très délicate la réinstallation complète d'une machine plusieurs années après son acquisition (nécessite de trouver et d'utiliser des drivers universels à jour ou plus anciens compatibles fourni par les constructeurs de composants en transgressant les recommandations constructeur).

Cordialement,

Trebly
__________________________________________________________________________________________________________________________________

Note 1 : l'ordre alphabétique des drivers et services : (ceci est vrai aussi de la gestion des services sous win7 et win10), il faut obligatoirement se bâtir (je n'ai pas trouvé sur le net) un glossaire anglais-français sous excel des noms de drivers et services pour retrouver le mieux possible les familles (par exemple en anglais tous les services Hyper-V on un titre qui commence par Hyper-V, on les retrouve ensemble comme tous les NET*, alors que la traduction française termine par le détail et finit par la généralité : Hyper-V : ... ce sont les noms qui sont utilisés pour constituer les groupes, la classification. Les utilisateurs de la version française n'ont pas la chance que le traducteur l'ait compris... C'est alors : on vous le jette par terre, il ne vous reste qu'à utiliser une liste sur papier pour consulter ligne à ligne tout en faisant des petites croix la liste papier pour la comparer à la liste présentée dans le désordre sur l'écran pour travailler sans risque une erreur non récupérable).