Windows 7 BSOD - rendez-moi ERD Commander !

[shugninx]

Bonjour à tous,

Premier post ici, en tant que pro de maintenance je n'en avais jamais eu besoin... C'est vous dire si mon ego est entamé par cet appel à l'aide.

Donc, sans trop rentrer dans les détails (je les donnerai au besoin plutôt que de poster un premier post imbitable), j'étais en train de sauvegarder les données d'un client depuis son disque dur branché sur mon PC via un dock eSata. Avira Antivir s'est alarmé de découvrir quelques pourritures dans le dossier Downloads du client, (rien d'anormal, sauf qu'il a déclenché un scan système puis m'a demandé de relancer la machine pour un scan au boot, comportement un peu "massue" de la part d'antivir, qui a pris cette tendance un peu lourdingue depuis quelques versions déjà). Je précise que je n'ai fait que sélectionner et copier des fichiers. Je n'en ai ouvert ni exécuté aucun.

Bref, là-dessus le disque client disparaît en pleine copie (de l'explorateur, du gestionnaire de disque...). Pas la première fois que mon Windows 7 me fait des misères avec les disques branchés en eSata, surtout après une sortie de veille prolongée. Pas de soucis, je sauvegarde la liste restante des fichiers à copier grâce à SuperCopier, je déconnecte le disque client et éteint le dock esata, je ferme tout et je reboote.

Et là c'est le drame : BSOD avec erreur BAD_SYSTEM_CONFIG_INFO.

Reboot (je me dis qu'il a du mal comprendre) : Idem, bien sûr.

Sans échec + réseau : pareil

Sans échec tout court : itou

Hem... OK, on va utiliser le dernier point de resto, et roule ma poule (me dis-je).

Démarrage sur le DVD d'install Win7, option repair, il voit mon install windows mais me dit :

"this version of system recovery options is not compatible with the version of windows you are trying to repair"

Bon bon bon... Récapitulons :

- je n'ai pas installé de matos (sauf le disque client en eSata, mais ça "normalement" c'est trivial),

- pas fait de màj quelconque (aucune màj proposée ni appliquée, rien vu lors de la fermeture de windows)

Alors quoi ?

Si quelqu'un a une astuce pour contourner le message d'erreur ci-dessus et restaurer un point de resto, je suis preneur.

Merci d'avance et bonne journée à tous,

ShugNinx

[mozzie]

Bonjour,

le BAD_SYSTEM_CONFIG_INFO signale la plus pars du temps un problème de registre. (dans ton cas, possiblement survenue soit d'une infection s'il y a un autorun sur le disque dur client, soit, beaucoup plus probablement d'une corruption mémoire lors du crash avec le disque eSata, dans une proportion très minime, on pourrait même mettre ça sur le dos d'antivir).

Il n'y a malheureusement pas beaucoup de solution:

- Soit un démarrage en "dernière bonne configuration connue" (reprennant les ruches sauvegardée du dernier boot correcte de ton PC)

- Soit une réparation windows (qui semble lamenablement échouer dans ton cas).

- Soit un la remise en ligne d'un backup fait par un outil tiers.

- Soit une réinstallation du système. (au pire, tu sais comment faire pour récupérer tes propres data )

Au delà de ton problème, lors d'une copie cliente (ou de tout support inconnu), la première chose à faire est toujours de désactiver les autoruns de son système et de faire un montage en lecture seule (ou utiliser un dock proposant un bloqueur d'écriture), mais j'ignore si les OS windows dispose de ce genre d'outil.

[dudul88]

Une autre option qui peut marche : Editer le registre (à l'aide par exemple d'un winpe) et supprimer dans HKLM/SYSTEM/MountedDevices la clef qui correspond au disque dur qui à été débrancher. (on peut aussi tenter de tout supprimer mais c'est risqué)

C'est une idée qui me vient comme ça, c'est pas sûr que ça marche.

[shugninx]

Merci pour vos réponses.

@Mozzie :

J'ai bien évidemment désactivé l'exécution automatique pour tous les lecteurs sur tous mes PC, car comme tu le soulignes c'est un nid à m...

Je soupçonne avira d'avoir merdé quelque chose lors de la demande de scan au boot.

La "dernière bonne configuration connue" ne m'a jamais été d'aucune utilité dans ce métier, mais j'aurai peut-être du commencer par là. Il me semble que ça marche si on le fait dès le premier crash, mais au-delà de quelques boots plantés ça n'apporte plus rien (merci de me corriger si je dis une bêtise).

Je n'ai évidemment pas d'image ni backup quelconque, s'agissant d'une machine secondaire.

C'est quand même très frustrant de se retrouver coincé par Microsoft qui ne reconnaît pas ses petits (cf. erreur pour accéder aux options de réparation du CD d'install d'origine), car je suis convaincu qu'un point de restauration résoudrait le problème et ça me rends ouf !!!

@dudul88 :

Merci, au point où j'en suis ça ne mange pas de pain d'essayer. Je crains par contre d'avoir du mal à identifier le périphérique en question...

[shugninx]

Une autre option qui peut marche : Editer le registre (à l'aide par exemple d'un winpe) et supprimer dans HKLM/SYSTEM/MountedDevices la clef qui correspond au disque dur qui à été débrancher. (on peut aussi tenter de tout supprimer mais c'est risqué)

C'est une idée qui me vient comme ça, c'est pas sûr que ça marche.

Bon, je viens de vider tout ce qui correspondait pas à mes disques internes, et ça ne change malheureusement rien...

Ah bon sang, dois bien y avoir moyen de contourner la médiocrité de CrimoSoft et récupérer un point de restauration non ?

[shugninx]

J'ai fini par trouver un élément de réponse, avec les mots clés google suivants :

"windows 7" RAID "this version of system recovery options is not compatible with the version of windows you are trying to repair"

http://www.arenddeboer.com/windows7-system-recovery (3e résultat)

Il est question du même symptôme, dans une config très similaire à la mienne (partition système C: sur volume RAID semi hard - càd à base de chipset Intel iCHxR). L'auteur a résolu son problème en repassant dans le BIOS le chipset du mode RAID à AHCI, ce qui effectivement est possible, mais uniquement en RAID1. Moi qui suit en RAID0, je l'ai dans l'os si je m'en tiens à la discussion commençant au 4e commentaire.

J'ai également trouvé un grand nombre de post sur l'erreur de compatibilité crachée par l'utilitaire de réparation du CD d'install, concernant la même tentative (utiliser un point de restauration pour un système qui ne boote plus même en mode sans échec), mais concernant Windows Serveur sur des bécanes avec des volumes RAID également (contrôleurs 100% hard cette fois, et ce malgré les pilotes)... Pas eu le courage de me farcir les kilomètres de posts.

Microsoft, tu pues...

[Invité]

Perso j'y vois une corruption de ntldr qui bugue avec la hive.

Genre antivir qui a rien trouvé de plus marrant que de mettre un boot temporaire sur le esata ^^

Tu as un Windows installé en uefi ou en rom legacy ? => parce que dans le cas de l'uefi on peut forcer le reboot sur un autre loader de Windows très facilement.

Quand tu parle de l'option repair => tu parle de celui juste après la selection de la langue ou tu rentre déjà dans l'installation de Windows détectée en vue d'une réparation ?

Parce qu'en principe l'idée c'est d'aller dans repair et de ne pas selectionner Windows ^^ (quand tu arrive au choix tu choisi l'option correspondant à une install non détectée).

Si ton contrôleur raid supporte le hot swap (mais comme intel c du tout logiciel...) => démarre sans les disques branchés (sata débranchés uniquement) ce qui permettra d'aller sur l'écran avant de faire quoique ce soitr mais je sais pas si ça supporte le montage à chaud.

On dit souvent que cette erreur est irréversible mais Windows est capable de se réparer même après une corruption importante du registre (faut pas oublier qu'il y'a moulte backup du registre (sauf présence de ccleaner qui voit ces fichiers comme du temp inutile).

Déjà faut essayer par tous les moyens d'accéder à la commande.

Au pire tu branche un disque hors raid et tu installe un Windows vierge dessus (ou tu boot un disque qui a déjà Windows (et OSEF l'activation elle reviendra quand tu remettra dans l'ordi d'origine))