Bonjour,
 
 
Je rencontre un souci suite à l'évolution d'un master pour Windows 7.
 
La première version du master fonctionnait parfaitement.
 
La nouvelle version, qui n'est censée contenir de plus que des nouvelles versions des softs du master, ou des updates windows, m'envoie un ecran bleu au boot de Windows. Je ne vais donc même pas jusqu'à la fenêtre de login.
Comme le boot n'aboutit pas, je ne peux ouvrir de session. (j'ai essayé tous les modes de démarrage : sans échec, sans échec avec prise en charge réseau, journalisation du boot, basse résolution.....)
Je n'ai pas non plus de fichiers dans C:\Windows\Minidump. (pas de dossier minidump tout simplement)
 
J'ai tenté l'export depuis un live CD des fichiers .evt (journaux Windows), l'export du fichier ntbtlog.txt mais je n'y comprends pas grand-chose..........
 
Ma question : comment puis-je avoir des infos sur la cause du problème ? Etant donné que je peux quand même accéder au DD via une clé USB / Live CD, y'a t-il des fichiers de logs qui pourraient me donner des précisions sur ce qui plante ?
 
D'avance merci pour vos réponses ou pistes

si tu n'as pas de minidump, il faut s'assurer que la création de minidump est activée.
http://blog.nirsoft.net/2010/07/27 [...] s-on-bsod/
 
passe par un live CD avec outil d'édition de registre du style  
http://www.hirensbootcd.org/

par curiosité, l'écran bleu renvoi quoi comme information ?

Bonjour,
 
Le souci est que je n'ai pas accès à Windows. L'ecran bleu intervient avant que je puisse ouvrir une session.
Donc pas de possibilité de le configurer dans Windows.
Pour HBCD, je l'ai mais je ne vois pas trop où je vais pouvoir faire en sorte de configurer la création minidump sans avoir accès à une session Windows.
Je cherche......

 
Pas de message particulier, d'où le fait que j'ai du mal à cibler le souci.
Les codes d'erreur sont 0x0000007E, oxc000005...
 

Si tu installes l'ancien master sur ta machine qui plante, ça fonctionne ou ça plante aussi ?

 
comme je te l'ai écris, par le registre
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"CrashDumpEnabled"=dword:00000003

L'ancien master fonctionne nickel !!

 
 
Alors,, j'ai tenté depuis le miniXP de HBCD, il fonctionne pas.
Du coup, j'ai tenté depuis un liveCD SystemrecueCD (linux), j'accède bien au registre mais je me heurte à des pb de droits (je pense), je n'arrive pas à lister toutes les clés  :-(

as-tu mise à jour des drivers?

 
Bonjour,
 
Je ne suis pas à l'origine du master, mais les masters sont relativement à jour, au pire 2/3 MàJ manquantes.
Donc je ne pense pas que le problème vienne d'un manque de mises à jour, c'est peut-être même plus ça le problème, un conflit entre pilotes "fabricant" et pilotes hérité d'un update Windows.
 
Il faut en priorité que j'arrive à produire un dump, qui me donnera des infos sur la cause du BSOD.

tu l'as fait comment surtout ton master ? (étape par étape)

Problème de AHCI ?

 
C'est à dire il fonctionne pas ? Sans boule de cristal, c'est chaud  

 
 
Re....
 
Non, mon Windows XP de HBCD ne fonctionne plus :-(
Je vais tester avec un autre Live CD

 
Alors, j'ai booté sur un autre WinPE opérationnel, édité le registre de la machine, charger la ruche HKLM, et configuré les minidump.
Je reboote et pas fichier dmp !!!!
Pourtant quand je me reconnecte sur la base de registre PC en remote, mes modifications registre sont bien présentes.
 
 
 

As tu désactivé le reboot automatique ?
je te dirais de faire une vérif complète des clés de registre et de configurer comme il faut :
https://support.microsoft.com/en-us [...] or-windows
 
par hasard, tu as regardé c:\windows\memory.dmp ?

Rebonjour, ....et merci de suivre ma galère :-)
 
Alors, concernant le memory.dmp, je n'en ai pas ?!?!
 
Ensuite, étant donné que je n'arrive pas jusqu'à la fenêtre de login de Windows, j'ai effectivement suivi les manip comme indiqué dans ton lien, en ouvrant la ruche HKLM du PC via un WinPE.
Par contre, ton lien est un peu plus détaillé que celui que j'ai suivi :-) notamment sur les valeurs possibles pour la clé CrashDumpEnabled.
Je testerai avec différentes valeurs demain.
Sinon, j'ai testé avec et sans reboot auto, en faisant attention au pagefile.sys.
Je vais redescendre mon master demain, parce que là j'ai tellement touché à tout que si ça se trouve, en repartant du master "propre" , enfin je veux dire foireux mais de base, j'aurais peut-être plus de résultat.
Merci en tout cas de ton aide :-)
 

 
Bonsoir,
 
Désolé de pas avoir répondu plus tôt, je sais que la question et surtout la réponse est importante, mais je n'ai malheureusement pas beaucoup d'infos, voire quasi pas, sur le process de création du master.
Il est créé à l'origine via MDT, et comprend les updates Windows et updates pilotes. J'ai vraiment pas beaucoup d'infos, je viens d'arriver dans la boite et on m'a refilé le bébé (l'histoire du BSOD au boot) comme premier job.  
Donc ne connaissant pas le process dans sa globalité, je cherche avec les notions que je possède.
Mais dans les grandes lignes, install de l'OS, install drivers, updates Windows, install softs, masterisation, création clé bootable WinPE avec scripts qui vont bien. Le reste se fait via Zenworks, mais là, il ne rentre pas en ligne de compte, vu que mon BSOD arrive au reboot d'après descente du master.

 
J'ai donc redescendu le master, paramétrer le registre de la machine en remote regedit, rien n'y fait, toujours pas de fichiers dump.........

normalement il y a pas de drivers dans un master, ils sont injecté lors de la descente du poste pour le modèle en question

 
oui, oui :-)

 
+1 ça y ressemble en effet.
 
le master a p-ê été fait avec un autre mode ?

je crois que sur du BSOD, tu as un message qui te dit que le dump a été créé. nan ?

 
 
Même mode, j'ai eu comme info qu'il n'y a eu aucun changement niveau driver, simplement ajout de corrctif Windows.
je suis en train de repartir de l'ancien master qui fonctionne et passer les updates crosoft 1 à 1 , voir si ça plante et si oui à quel moment

 
 
Oui, il me signale que le dump est créé mais aucun dump dans tout le C:

la, ça devient bizarre

Bonjour,
 
 
Je reviens sur le sujet ayant un peu avancé.
J'ai changé de méthode.
 
Je suis parti de mon image wim sans le process de descente du process du master. J'ai donc appliqué mon image "nue".
L'OS s'installe, et il démarre. alors, sans certains pilotes mais c'est normal.
 
Ensuite, j'ai commencé à installé les pilotes des périphériques non installés, en prenant comme répertoire de drivers, le répertoire de drivers sur lequel pointe normalement le master.
Et là, j'arrive à reproduire mon BSOD. Comme je peux me logguer, je peux obtenir mon fichier dump.
Via bluescreenview, l'analyse révéle que le pilote en cause est iusb3hub.sys. Ce pilote n'a pas à être chargé étant donné que je n'ai pas d'USB3 sur la machine concernée.
 
Dump File         : 032017-28298-01.dmp
Crash Time        : 20/03/2017 14:32:29
Bug Check String  : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Bug Check Code    : 0x1000007e
Parameter 1       : 0xc0000005
Parameter 2       : 0x00000000
Parameter 3       : 0x8a747b98
Parameter 4       : 0x8a747770
Caused By Driver  : iusb3hub.sys
Caused By Address : iusb3hub.sys+3f88e
File Description  :  
Product Name      :  
Company           :  
File Version      :  
Processor         : 32-bit
Crash Address     :  
Stack Address 1   : iusb3hub.sys+40bac
Stack Address 2   : iusb3hub.sys+263ce
Stack Address 3   : ntkrnlpa.exe+2190cb
Computer Name     :  
 
Par contre, je ne sais pas si je dois tenir compte de Stack Address 3   : ntkrnlpa.exe+2190cb .....
 
 
Je suis donc en train de redescendre mon master en ayant au préalable viré tous les pilotes usb3 du répertoire out-of-box-drivers.
A suivre......

Ton matos ne serait pas trop récent pour le master que tu as à disposition ? On ne t'a pas fourni une liste de compatibilité matérielle avec ?

 
Historiquement, ce master pose problème depuis Juin 2016, le dernier valide datant de Mars 2016.
Depuis, plusieurs ajouts de pilotes ont été effectué dans le répertoire de drivers, car le master sert pour plusieurs types de machines.
Et pour info, je reprends le train en marche, avec un certain manque d'infos sur ce qui a été fait. J'avance un peu à l'aveugle malheureusement :-(
 
J'attends de voir si le fait de retirer les pilotes usb3 du répertoire est suffisant ou si je vais avoir d'autres surprises .....

 
 
 
Résultat : Mon OS démarre correctement !!!!!! :-)
 
Je vais réitérer l'opération en réintégrant au fur et à mesure les pilotes que j'avais enlevé, sauf la version qui pose apparemment souci selon mon fichier dump.
A suivre..........

il faut pas injecter tous les drivers pour tous les types de matériel mais pour chaque modèle de poste injecter les drivers dont il a besoin et uniquement les drivers dont il a besoin. Ne rien laisser au hasard.

Oui, je sais, seulement, le répertoire de drivers contient les drivers pour plusieurs types de machines, et classés par type de matériel (USB, Réseau, Graphik), et non par type de machine.
Du coup, lorsque le master descend, il doit y avoir un conflit ou une erreur dans la recherche de pilotes, et c'est un pilote inapproprié qui est chargé.
 
Je suis en train de refaire des tests pour identifier le pilote en cause

c'est sous quel soft ? MDT ?
Suffit de faire des dossiers par marque/modèle et injecter selon l'arbo par rapport au modèle du poste (requête wmi)

Un BSOD lors de la phase de boot, c'est très souvent une incompatibilité matérielle, généralement du matériel récent non supporté ou un OS un peu vieillot.
 
C'est ton cas ici -il faudrait inclure dans le master l'ensemble des pilotes nécessaire, ainsi que les dernières mises à jour de compatibilité disponibles pour l'OS.

 
oui, c'est sous MDT.
C'est ce que j'ai cru comprendre, mais là on a un socle commun x86, et ensuite un dossier out-of-box drivers, où les pilotes sont classés par type mais pas par machine. (ex: un dossier USB contenant les pilotes pour plusieurs types de machines.)
J'ai pas conçu le truc et n'ai pas la main dessus......

 
 
Les mises à jour Windows sont intégrées, et ne posent pas souci.
Comme je disais, c'est au niveau pilote, (iusb3hub.sys), qu'il y a un souci. Il y a justement trop de pilotes (correspondant à plusieurs modèles de machines), c'est la foire à tout, donc environnement propice aux conflits.........

Et ceux qui ont fait le master, ils l'ont bien validé pour ton modèle de machine ? Ils ne te doivent pas du support, si ça ne fonctionne pas ?

 
 
Arfffff, le pb persiste depuis près d'un an, et je ne suis pas le premier qui a été mis sur le sujet.
de ce que j'en ai compris, tous ceux qui se sont essayé à résoudre le pb, n'ont pas été très loin.
 
Et en gros, "nous on a fait, si ça fonctionne pas, c'est à toi de trouver !!!!"   des fois.................

Dans ce cas il faut quelqu'un reprenne la gestion de MDT, remette à plat les la configuration et les pilotes, puis il faut construire des process pour le mettre à jour régulièrement. Bref il vous manque une organisation pour gérer ce service