TL;DR
On voulait installer Rakazo, une plateforme d'agents IA auto-hébergée, sur le PC fixe. Il a fallu ouvrir trois cadenas :
la place sur C:, la virtualisation (SVM) et une mise à jour de Windows 10 de 1909 vers 22H2. Les deux premiers sont
ouverts. Le troisième résiste : quatre essais, quatre fois 0xC1900101 - 0x20017, sans écran bleu. Après avoir
innocenté deux pilotes de stockage, l'audit désigne un suspect principal : un BIOS de janvier 2018.
Les trois cadenas
Rakazo tourne dans Docker Desktop, et Docker Desktop a besoin de WSL2. WSL2 demande au moins Windows 10 build 19041 et la virtualisation du processeur. Le PC fixe était en 1909 (build 18363), avec SVM coupé et un disque C: presque plein.
| Cadenas | État | Ce qui l'a ouvert |
|---|---|---|
| 1. Place sur C: | ✅ | 7,1 → 25,5 Go libres : caches vidés, vieille copie des Documents comparée (151 963 fichiers, 0 perdu) puis supprimée, LM Studio copié sur D: |
| 2. Windows 22H2 | ❌ | 4 essais, même erreur |
| 3. SVM | ✅ | un interrupteur dans le BIOS |
La même erreur, quatre fois
0xC1900101 - 0x20017 veut dire : la machine tombe pendant le premier démarrage de l'installation, dans le
mini-Windows (SafeOS) qui prépare le nouveau système. Elle tombe donc avant même d'arriver au nouveau Windows. Puis Windows revient en arrière tout seul.
Le dernier essai, minute par minute : préparation de 00:30 à 00:41, redémarrage à 00:42, retour arrière à 00:44. Le journal de retour arrière dit :
There is no crash dump file!
Current bugcheck string : NULL
BootLogLastErrorEventCode:80
LastBootSucceeded:0
Pas d'écran bleu enregistré, pas de pilote nommé : le PC se fige ou redémarre avant d'avoir pu écrire quoi que ce soit.
Deux pilotes innocentés
Ce code pointe très souvent un pilote de stockage. On les a remplacés un par un, entre deux essais :
- le pilote AMD StoreMI des contrôleurs SATA → pilote AHCI de Windows ;
- le pilote Samsung NVMe du disque système → pilote NVMe de Windows.
Résultat : aucun pilote de stockage tiers ni filtre de disque exotique ne reste. La partition de démarrage est saine (UEFI, GPT, sur le même disque que C:). L'erreur, elle, n'a pas bougé d'un octet.
Les suspects
Quand le logiciel est propre, il reste le matériel et son micrologiciel.
| Suspect | Confiance | Pourquoi |
|---|---|---|
| BIOS de la carte mère, version de janvier 2018 | ~70 % | huit ans d'écart avec la carte graphique et avec le démarrage du nouveau Windows |
| RAM réglée à 2933 MHz | ~55 % | au-dessus des 2666 MHz officiels du Ryzen 5 1600X ; un mini-Windows est moins tolérant |
| Carte graphique RTX 5060 Ti (2025) | ~40 % | le mini-Windows doit l'afficher sans pilote NVIDIA |
| Trois disques SATA en plus | ~30 % | le mini-Windows les scanne tous, dont un vieux disque en MBR |
| Vieux pilotes (casque VR, cartes vidéo pro, dongle de licence) | ~15 % | ils ne se chargent pas dans le mini-Windows |
Le plan pour l'essai n°5
Un seul essai, en retirant le plus de suspects possible d'un coup :
- Flasher le dernier BIOS de la carte, puis réactiver SVM.
- Couper l'XMP et tout overclocking.
- Débrancher les trois disques SATA, garder seulement le disque système.
- Installer depuis une ISO 22H2, en refusant le téléchargement des mises à jour pendant l'installation.
- Une fois en 22H2 : rebrancher, remettre l'XMP, puis installer Docker Desktop (données sur D:) et Rakazo.
En parallèle, SetupDiag, l'outil de diagnostic de Microsoft, est prêt. Il attend juste d'être lancé en administrateur.
Ce qu'on en retient
- Un code d'erreur qui ne change pas après qu'on a changé sa cause supposée, c'est une information : la cause est ailleurs.
- « Pas de crash dump » oriente vers le matériel plus que vers un pilote.
- Une page « pour enfant » avec une frise et des cartes de suspects a rendu ces quatre redémarrages lisibles d'un coup d'œil sur un téléphone.