Pourquoi un Master Sysprep affiche un Stop 0x7B sur Windows Xp/2003


Je suis presque sûr que tout ceux qui ont eu a générer un master sysprep ont rencontré un Stop 0x7B (Inaccessible Boot Device)
Bien que plusieurs articles KB tournent autour de cette erreur, aucun d'entre eux n'explique vraiment pourquoi elle apparait...


Comment que ça se fait que ça marche pas?


Pour répondre à cette question, revenons en arrière, bien avant que cet écran bleu n'apparaisse...



Stop 0x7B


 ...Plus tôt : le même jour!


Nous sommes en face d'une machine de référence contenant le Master que vous souhaitez "syspreper".
Cette machine contient donc:



  • une installation complète de Windows avec quelques personnalisations

  • quelques applications

  • un répertoire contenant les drivers des differents modèles de machines compatibles avec cette machine de référence

  • un répertoire Sysprep à la racine de c:\


image


Satisfait de l'état actuel de la machine de référence et ayant vérifié que cette machine n'entrait pas dans les scénarios non-supportés 828287 | Unsupported Sysprep scenarios, l'OS doit étre préparé à être déployé et donc redémarré sur un matériel différent. C'est là que Sysprep intervient :



  • Sysprep.exe : System Preparation Tool

  • Setupcl.exe : Permet de regenérer les identifiants uniques de la machine

  • Sysprep.inf : Fichier de réponse de Sysprep.exe

Note: Ces outils sont disponibles dans le deploy.cab. Il faut toujours utiliser le deploy.cab du dernier service pack sorti entre Xp et 2003 ; à l'heure d'aujourd'hui (à 5 minutes près), ce sont les outils du service pack 3 de Windows Xp qu'il faut utiliser
Windows XP Service Pack 3 Deployment Tools


...Vers Midi : Lancement de Sysprep, capture et descente du master



La commande Sysprep -mini -reseal a été lancée et la machine redémarre sur un WinPe 2.0 et Imagex (par exemple) est en train de capturer la partition contenant le Sysprep de Windows.



Mode de testing #1 :


la machine de référence est redémarrée sous WinPe, le disque formaté et l'imagex l'image wim du Master appliquée sur C:\ avec Imagex
Au redémarrage sur le disque local, la séquence de boot se passe normalement et Windows ecexute le mini-setup en utilisant les réponses dans le fichier Sysprep.inf



mini-setup


Mode de Testing #2 :


Pour s'assurer que le master est bien opérationnel, celui-ci est descendu sur la machine compatible la plus récente...
...et là c'est le drame du reboot en boucle (et le moment d'aller prendre un café) malgré le test des differents choix proposés par le mode sans echec.


...Plus tard : Pourquoi tu fais ça?


1.  Un peu plus loin dans le processus de démarrage
   WindowsBootProcess


C'est lors de la bascule en mode driver que les bactéries attaquent, si Windows ne trouve pas de pilote compatible il affiche un Stop 0x7B.
Windows passe en mode driver afin d'améliorer les performances (I/O)


2.  Confirmer les soupçons

Si vous êtes bloqué dans une boucle de démarrage, vous n'avez pas le temps de voir le message d'erreur qui apparait.
En éditant le Wim avant la descente ou bien en redémarrant avec WinPe après avoir rencontré l'erreur, on peut forcé la machine à ne pas redémarrer suite à un écran bleu.



  • Démarrer sous WinPe

  • Lancer regedit :

    • Se placer sur HKLM

    • Cliquer sur Fichier\Charger la ruche

    • Aller sous %SystemRoot%\System32\Config

    • Sélectionner le fichier SYSTEM

    • Valider et donner n’importe quel nom (par exemple : TempSys)

      • Aller sous HKLM\TempSys\ControlSet001\Control\CrashControl

      • Passer la valeur de la variable AutoReboot de 1 à 0 
        LoadHive

    • Se placer à la racine de TempSys, cliquer sur Fichier\Décharger la ruche

  • Au prochain redémarrage, la machine devrait rester figée sur l'écran bleu


3.  Résoudre le problème (éviter serait plus juste) :

Pour éviter de tomber dans cette situation, il faut repartir du master avant de lancer Sysprep.exe;



  • Créer un fichier Sysprep.inf ne contenant que la section [SysprepMassStorage]

  • Lancer la commande : c:\Sysprep\Sysprep.exe –bmsd

    • Celui-ci peuple le fichier réponse avec les drivers MassStorage connus de Windows

      sysprep 

  • Ensuite ajouter les drivers MassStorage non-connus de votre parc manuellement

    • Ajouter des lignes sous la forme : HardwareID = c:\Drivers\Mass\Sata1\Driver.inf

    • Il faut donc identifier sur vos différentes machines si le périphérique MassStorage est connus ou non

      • Si oui  : rien à faire (c'est pas souvent)

      • Si non : récupérer le driver dans un répertoire (1 fichier *.inf, 1 fichier *.sys, 1 fichier *.cat et des 1 fichier *.dll)


Note : le fichier Ref.chm du deploy.cab est une aide assez complète pour le Setup
La section [SysprepMassStorage] y est aussi détaillée



4.  Vérifier avant de déployer :

Petite procédure pour vérifier la présence d’un contrôleur de stockage dans une image wim afin de s'assurer que le Master en rencontrera pas de Stop 0x7B :



  • Monter le wim via : imagex /mountrw CheminDuWim Index RépertoireNTFSVide

  • Lancer regedit :

    • Se placer sur HKLM

    • Cliquer sur Fichier\Charger la ruche

    • Aller sous %SystemRoot%\System32\Config

    • Sélectionner le fichier SYSTEM

    • Valider et donner n’importe quel nom (par exemple : TempSys)

      • Aller sous HKLM\TempSys\ControlSet001\Control\CriticalDeviceDatabase

      • Vérifier l’existence du HardwareID (HWID = PCI#Ven… ou SCSI#… )

      • Vérifier également l’existence du Service associé sous HKLM\TempSys\ControlSet001\Service

    • Une fois les contrôles effectués, se placer à la racine de TempSys, cliquer sur Fichier\Décharger la ruche

  • Puis démonter le wim : imagex /unmount RépertoireNTFSVide (+ /commit si vous voulez enregister les modifications)

...Après "plus tard" : Journée super productive!!!


Mon master fonctionne sur tous les MassStorage de mon parc : ATA, Sata, SCSI...
Au revoir le stop 0x7B!


...Pour finir : d'autres petites infos



Plug&Play vs MassStorage:



  • Les pilotes MassStorage ne sont pas Plug&Play, ils doivent être chargés très tot c'est pourquoi ils ne doivent pas apparaitre dans le OemPnpDriversPath du fichier de réponse.

  • Cette réponse correspond à la variable HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion!DevicePath
    La detection plug&play est lancée bien plus tard.


Petit Rappel concernant La machine de référence :



  • Elle doit être la plus simple possible

  • Ne pas intégrer de périphérique "exotiques"

  • Il faut installer un minimum de drivers afin d’éviter les entrées dupliquées dans la base de registre et périphérique fantôme

  • Une machine virtuelle (sans additions) convient comme machine de référence

 


Ajouter des Contrôleur à un Sysprep existant:



  • Ajouter manuellement les entrées de registre dans CriticalDeviceDatabase et Services pour un nouveau contrôleur n'est pas supporté

  • MDT sait faire ce genre d'action
    Setting variables through a Task Sequence


Malgré la longeur de l'article j'espère que celui-ci reste clair et compréhensible...


Tête de Vincar
Windows Core Support Engineer

Comments (2)

  1. thomas says:

    Super article, bien détaillé et très clair !

    En passant vos schémas du début sont superbes ! 🙂

    Une autre possibilité - peut-être non supportée par Microsoft - est d'installer un DriverPacks de pilotes MassStorage ( http://driverpacks.net/DriverPacks/DriverPack.php?pag=m ) dans Windows.

    Cela permet de supporter rapidement un grand nombre de matériels !

    Egalement, les pilotes massstorage ou les driverpacks peuvent être intégrés directement à un CD Windows XP avec nLite.

  2. Mathieu Po says:

    Vraiment content de lire cet article. J'en arrivais à la même conclusion en faisant des comparaisons de registres en bootant sur différents controleur. J'ajoutais ensuite les fichiers .sys dans le dossier system32/drivers et ajoutais les clés de registres nécessaires au controleur. Cet article permet de confirmer le tout. Je veux éviter de "re-syspreper" mon image alors j'inclus les clés manuellement dams la ruche System.

    Merci

Skip to main content