Redémarrages RDS 2019 : corriger Kernel‑Power 41 (OpenStack/Virtuozzo, EPYC, UPD)

Vos serveurs RDS Windows Server 2019 redémarrent sans prévenir avec l’évènement Kernel‑Power 41 ? Ce guide opérationnel — pensé pour des hôtes Virtuozzo/OpenStack (SeaBIOS) sur AMD EPYC et des profils UPD — détaille une méthode fiable pour diagnostiquer, corréler et éliminer les arrêts brutaux.

Sommaire

Contexte et symptômes

Depuis une restauration de sauvegarde, trois VMs RDS (1 Broker/Gateway + 2 Session Hosts) sous Windows Server 2019 (1809, build 17763.5933) redémarrent plusieurs fois par jour. Les deux Session Hosts consignent systématiquement l’évènement critique Kernel‑Power 41, tâche 63, mots‑clés 0x8000400000000002 sans paramètres de bug‑check (tous 0). Les serveurs tournent sur un hyperviseur Virtuozzo / OpenStack avec SeaBIOS (2014), CPU AMD EPYC (IBPB), 64 Go RAM. Les applications majeures sont Microsoft 365 (CTR) et un logiciel tiers Merit. Les profils utilisateurs sont hébergés en User Profile Disks (disques dynamiques, VHDX).

Pourquoi « Kernel‑Power 41 » n’est qu’un symptôme

L’ID 41 indique que l’OS a constaté un redémarrage sans séquence d’arrêt « propre ». Il n’explique pas la cause. Sans dump mémoire ou évènement corrélé (BugCheck, WHEA‑Logger, storvsp/vioscsi, volsnap, SMB Client/Server), impossible d’attribuer une responsabilité à un pilote, un stockage, un microcode ou l’hyperviseur. Le fait qu’aucun BugcheckCode ne remonte suggère une « extinction sèche » : reset hyperviseur, perte de cœur‑bat I/O, micro‑freeze CPU, ou failover forcé.

Plan d’intervention rapide

Capturer la cause : activer un dump mémoire du noyau, désactiver le redémarrage auto, provoquer un dump volontaire si nécessaire.
Corréler : extraire une frise chronologique des évènements (41, 6008, WHEA, storvsp/vioscsi, volsnap, NetAdapter, WinRM, RDS).
Écarter l’hôte : vérifier les logs OpenStack/Virtuozzo (nova‑compute, libvirtd, qemu‑kvm, IPMI), microcodes EPYC et firmware.
Assainir l’OS : LCU/SSU récents, pilotes virtio à jour (réseau/stockage/balloon), vérif. SFC/DISM/CHKDSK.
Tester : mémoire (ECC), I/O (DiskSpd), charge CPU, stabilité réseau vers le partage UPD.
Optimiser l’énergie : plan Haute performance, réglages C‑States/CPPC si possible côté hôte.
Sécuriser les UPD : latence stable, quotas maîtrisés, pas de déduplication ou scanner AV intrusif sur VHDX montés.
Rollback ciblé : si un pilote ou composant est incriminé, revenir en arrière ou reconstruire une VM propre.

Tableau de synthèse — actions à forte valeur

Axe	Actions recommandées	But / Résultat attendu
Capturer la cause exacte	Activer vidage mémoire automatique : `sysdm.cpl` > Avancé > Démarrage et récupération > Écriture : « Mémoire du noyau ». Désactiver « Redémarrer automatiquement ». Installer WinDbg/WhoCrashed pour analyser les dumps.	Obtenir la pile d’appel et isoler un pilote/composant précis.
Vérifier l’hyperviseur	Contrôler logs hôte : IPMI, libvirtd/qemu‑kvm, nova‑compute, Virtuozzo ; rechercher guest reset, pause due to I/O error. Mettre à jour SeaBIOS et les microcodes EPYC.	Écarter un power‑loss, un watchdog, un freeze CPU ou une panne I/O côté hôte.
Mettre à jour OS/pilotes	Installer le dernier LCU pour 2019 (vérifier qu’il dépasse la build actuelle). Mettre à jour virtio (réseau/stockage/balloon) et services d’intégration. Valider les versions Merit/Microsoft 365.	Corriger des bugs connus ; Kernel‑Power 41 peut suivre un crash driver.
Réparer l’image	`sfc /scannow`, puis `DISM /Online /Cleanup-Image /RestoreHealth`. Exécuter `chkdsk /f /r` sur tous les volumes (y.c. VHDX de profils).	Traquer la corruption post‑restauration (fichiers système/VHDX).
Tester mémoire/stockage	Diagnostics mémoire (Windows/MemTest86) et compteurs ECC hôte. Stress I/O dans la VM (DiskSpd).	Écarter une RAM instable ou un backend stockage déficient.
Gestion d’alimentation	`powercfg /setactive SCHEME_MIN` (Haute performance). Désactiver C‑States/CPPC côté hôte si possible. Vérifier l’absence d’états S3/S4 imposés.	Éviter des transitions d’énergie hasardeuses.
Surveiller et corréler	Reliability Monitor et PowerShell (`Get-WinEvent`) pour une chronologie fine. PerfMon : files d’attente disque, CPU, latence réseau.	Repérer un motif récurrent avant chaque coupure.
Sécuriser les UPD	Partage UPD sur réseau stable/faible latence ; limiter la taille VHDX (< 10 Go) ; éviter la déduplication. Cache écriture paramétré côté hôte.	Éviter les verrous ou time‑outs VHDX entraînant un crash.
Rollback	Supprimer/Restaurer le pilote incriminé si les dumps convergent. À défaut : recréer une VM propre et rattacher profils/applicatifs.	Sortir d’un état corrompu hérité de la restauration.

Procédure détaillée et commandes utiles

Activer un dump noyau et bloquer le redémarrage automatique

Ouvrez sysdm.cpl > Paramètres système avancés > Démarrage et récupération :
- Écriture des informations de débogage : « Mémoire du noyau ».
- Dossier : %SystemRoot%\MEMORY.DMP. Cochez « Conserver un ancien fichier de vidage » si présent.
- Décochez « Redémarrer automatiquement ».
Vérifiez le fichier d’échange : taille recommandée ≥ RAM physique.
PowerShell :

# Activer le dump noyau et désactiver le redémarrage auto
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Value 2
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name AlwaysKeepMemoryDump -Value 1 -Type DWord
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name LogEvent -Value 1 -Type DWord
wmic RECOVEROS set DebugInfoType = 2
wmic RECOVEROS set AutoReboot = False

# Vérifier la taille du pagefile

Get-CimInstance Win32\_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage

Astuce : pour forcer un dump en cas de freeze sans BSOD, vous pouvez autoriser CrashOnCtrlScroll (console directe, pas en RDP) :

# Clavier USB (kbdhid)
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters' -Name CrashOnCtrlScroll -PropertyType DWord -Value 1 -Force
# Clavier PS/2 (i8042prt)
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters' -Name CrashOnCtrlScroll -PropertyType DWord -Value 1 -Force

Construire une frise d’évènements avant/pendant chaque redémarrage

Exécutez ces requêtes pour 48 h glissantes (ajustez selon la fréquence des incidents) :

# Timeline autour de Kernel-Power 41, 6008 (arrêt inattendu), 1074 (arrêt initié)
$since = (Get-Date).AddDays(-2)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$since; Id=@(41,6008,1074)} |
  Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message |
  Sort-Object TimeCreated

# WHEA (erreurs matérielles CPU/RAM/PCIe) et stockage virtuel (storvsp/vioscsi)

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=\$since; ProviderName=@('WHEA-Logger','storvsp','vioscsi','Disk','Ntfs','volsnap','LanmanWorkstation','srv2')} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Sort-Object TimeCreated

# Réseau virtio-net (NetAdapter) : pertes de lien, réinitialisations

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=\$since; ProviderName='Microsoft-Windows-NDIS'} |
Select TimeCreated, Id, LevelDisplayName, Message

Complétez par Reliability Monitor (perfmon /rel) pour une vue corrélée des plantages d’applications (Merit/Office), pilotes, et mises à jour.

Auditer l’hôte Virtuozzo/OpenStack et le firmware

IPMI / BMC : coupures secteur, surchauffes, erreurs ECC, défauts ventilateurs/alimentations.
nova‑compute / libvirtd / qemu‑kvm : recherchez les motifs guest-reset, Watchdog, blocked for more than 120 seconds, pause due to I/O error, ou NMI injected.
Microcodes AMD EPYC : appliquez les révisions récentes (stabilité sous forte virtualisation I/O, correctifs spectre/meltdown/IBPB).
SeaBIOS 2014 : très ancien. Préférez SeaBIOS 1.16+ ou migrez vers OVMF/UEFI ; des améliorations ACPI/SMBIOS/RTC évitent des faux signaux de mise en veille ou des timers erratiques.
Overcommit : contrôlez la pression CPU/RAM, le ballooning agressif et les contensions I/O (QoS stockage, file d’attente).

Mettre à jour Windows Server et les pilotes virtio

LCU/SSU : appliquez la dernière CU disponible pour Windows Server 2019. Vérifiez que la nouvelle build dépasse votre build courante (17763.5933).
virtio : mettez à jour vioscsi/viostor, virtio-net, balloon et les services d’intégration Virtuozzo.
Merit / Microsoft 365 : contrôlez les pilotes/filtres installés (DLP, antivirus, modules PDF, imprimantes virtuelles) susceptibles d’intercepter le noyau.

# Inventaire rapide des pilotes signés
Get-CimInstance Win32_PnPSignedDriver | Select-Object DeviceName, DriverVersion, DriverProviderName | Sort-Object DriverProviderName

# Liste des correctifs

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description

Réparer l’image système et vérifier les disques

# Intégrité des fichiers système
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

# Vérification des volumes (exige un redémarrage si en cours d’utilisation)

chkdsk C: /f /r

# Pour chaque VHDX de profil monté :

chkdsk X: /f /r

Conseil : si les UPD résident sur un partage SMB, évitez la déduplication et désactivez les scans AV en temps réel sur les fichiers VHDX ouverts. La dédup ou un filtre mal optimisé peut provoquer des time‑outs, des verrous ou des corruptions.

Tester la mémoire et le stockage

Mémoire : lancez le Diagnostic de mémoire Windows (redémarrage requis) et consultez les compteurs ECC hôte. Une hausse d’erreurs corrigées peut précéder un crash.
I/O : exécutez DiskSpd avec des profils de lecture/écriture aléatoires et séquentiels pour caractériser latence et throughputs.

# Exemple DiskSpd : 4 files, 4K aléatoire, lecture/écriture 50/50 sur 2 minutes
.\diskspd.exe -c2G -d120 -Sh -w50 -r4k -t4 -o16 C:\_test.dat

Optimiser la gestion d’alimentation

Sur des VMs serveur, privilégiez une alimentation constante.

# Activer le plan Haute performance
powercfg /setactive SCHEME_MIN
# Vérifier
powercfg /l

Côté hôte, si possible, limitez les C‑States profonds et validez le CPPC (Collaborative Processor Performance Control) pour stabiliser les fréquences sous charge RDS. Les états S3/S4 ne sont pas utilisés par Windows Server 2019 ; assurez‑vous qu’aucun plan d’énergie personnalisé n’introduit d’hibernation.

Sécuriser les User Profile Disks (UPD)

Transport : lien 10 Gb/s recommandé, latence stable (< 2–3 ms) entre Session Host et serveur de fichiers.
Taille VHDX : ciblez < 10 Go par utilisateur. Purgez caches (Teams/OneDrive) et redirigez ce qui peut l’être.
Montage : un VHDX « perdu » ou verrouillé après un reset peut empêcher l’ouverture de session et déclencher des comportements instables.
SMB : activez les handles durables et surveillez les Event 30805 (Client SMB) et srv2 côté serveur.

Spécificités RDS Windows Server 2019

Journaux RDS : consultez Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational et RemoteDesktopServices‑RdpCoreTS/Operational pour corréler les déconnexions juste avant l’ID 41.
Broker : vérifiez que le Connection Broker et RD Gateway n’initient pas des réinitialisations de sessions suite à un time‑out backend.
Office CTR : en environnement multi‑utilisateur, vérifiez les modules COM/prints et l’isolation des compléments (Outlook/Excel) qui peuvent charger des pilotes d’impression obsolètes.

Quand l’ID 41 masque une erreur matérielle (WHEA)

Sur AMD EPYC, une défaillance matérielle peut se manifester par WHEA‑Logger (ID 17/18/19) juste avant l’ID 41 : erreurs de cache/banque CPU, lien PCIe, mémoire. Ces évènements sont cruciaux ; si présents, la piste matériel/microcode/hôte prime.

Exclure un problème réseau/stockage virtuel

Un reset hôte ou une pause VM due à I/O peut déclencher un « hard reset ». Sur Windows, recherchez :

storvsp/vioscsi 129/153 : time‑outs SCSI.
Disk 51/57 : erreurs d’écriture différée.
volsnap 25 : snapshot interrompu.
LanmanWorkstation/srv2 : perte de handle SMB sur VHDX d’UPD.

Scripts « boîte noire » pour capturer avant l’incident

Planifiez un export périodique des métriques. Exemple : journaliser CPU/I/O toutes les 5 s pendant 24 h :

$path = 'C:\Logs\baseline.csv'
New-Item -ItemType Directory -Force -Path (Split-Path $path)
"Timestamp,CPU,DiskQ,NetRecv,NetSend" | Out-File -FilePath $path -Encoding ascii

while (\$true) {
\$ts = Get-Date -Format o
\$cpu = (Get-Counter '\Processor(\_Total)% Processor Time').CounterSamples.CookedValue
\$dq  = (Get-Counter '\PhysicalDisk(\_Total)\Current Disk Queue Length').CounterSamples.CookedValue
\$nr  = (Get-Counter '\Network Interface(*)\Bytes Received/sec').CounterSamples.CookedValue | Measure -Sum | Select -Expand Sum
\$ns  = (Get-Counter '\Network Interface(*)\Bytes Sent/sec').CounterSamples.CookedValue     | Measure -Sum | Select -Expand Sum
"\$ts,{0\:N2},{1\:N2},{2\:N0},{3\:N0}" -f \$cpu,\$dq,\$nr,\$ns | Add-Content \$path
Start-Sleep -Seconds 5
}

Mesures temporaires pour stabiliser en production

Limiter la charge : réduire le nombre de sessions par hôte, désactiver l’impression redirigée si suspecte, déporter les traitements batch lourds.
Diversifier : si possible, répartir les UPD sur deux partages distincts pour limiter l’impact d’un point unique instable.
Surveillance active : alerter sur l’apparition d’un évènement 129/153 (storvsp/vioscsi) ou 18 (WHEA).

Matrice de décision — lier les indices à une cause probable

Empreinte avant ID 41	Interprétation probable	Action prioritaire
WHEA‑Logger 18 (cache/PCIe), erreurs ECC	Panne matérielle hôte / microcode	Mettre à jour microcodes/firmware ; basculer la VM sur un autre nœud et retester
storvsp/vioscsi 129/153, Disk 51/57	Timeouts I/O, contention stockage, pilote virtio	Mettre à jour virtio ; diagnostiquer backend (latence, saturation)
LanmanWorkstation/srv2 erreurs de handle VHDX	Partage UPD instable, AV ou dédup	Désactiver scans/dédup sur VHDX, valider réseau SMB et CA
Aucun bugcheck, aucun WHEA, guest reset côté hôte	Watchdog/Reset hyperviseur	Analyser nova‑compute/libvirtd ; corriger BIOS/ACPI, C‑States
BugCheck + minidump	Crash pilote noyau	Analyser pile d’appel WinDbg ; rollback/MAJ du pilote fautif

Annexe — check‑list hôte OpenStack/Virtuozzo

Alimentation : redondance PSU, logs IPMI propres, pas de transitoires secteur récents.
Thermique : pas de throttling CPU/VRM.
BIOS/UEFI : version SeaBIOS à jour ou migration OVMF/UEFI.
CPU : microcodes AMD EPYC récents ; vérifier paramètres SMT/NUMA exposés aux VMs.
RAM : erreurs ECC corrigées sous seuil, pas de page retirement massif.
Stockage : latence P99, file d’attente, QoS ; pas d’erreurs de disque dans dmesg.
Réseau : drops/CRC, MTU cohérent (éviter un mix 1500/9000 entre hôte et filer SMB).
Overcommit : ratio vCPU:CPU et mémoire, paramétrage ballooning et swap hôte.

Analyse WinDbg — que chercher dans les dumps

Une fois un dump obtenu (C:\Windows\MEMORY.DMP ou Minidump\*.dmp), ciblez :

!analyze -v : code de bugcheck, faulting module, stack.
pilotes de stockage/réseau : vioscsi.sys, viostor.sys, netkvm.sys, filtres AV/DLP.
IRQL_NOT_LESS_OR_EQUAL / DPC_WATCHDOG_VIOLATION : classiques après I/O bloquée.
THREAD_STUCK_IN_DEVICE_DRIVER : moins fréquent en VM, mais révélateur d’un pilote I/O.

Pièges fréquents et bonnes pratiques

Antivirus/EDR : excluez les répertoires %ProgramData%\Microsoft\Windows\Hyper-V\Virtual Machines équivalents si vous utilisez des VHDX/UPD, et les processus de VSS. Sur le serveur de fichiers, excluez les VHDX montés.
UPD sur ReFS avec dédup : déconseillé. Préférez NTFS classique pour les VHDX d’UPD.
Drivers d’impression hérités : en RDS, des pilotes non packagés 32‑bit peuvent provoquer des fuites ou DPC longs.
Planificateur : évitez d’aligner scans antivirus complets, sauvegardes VSS et pics de logon matinaux.
Cache d’écriture : si activé côté hôte sur les volumes VM, validez la stratégie de flush et la protection batterie.

Scénario de rollback ou reconstruction

Si les dumps incriminent un pilote récent (virtio, AV, filtre stockage, imprimante) :

Revenir en arrière (désinstallation, version précédente). Testez la stabilité 48–72 h.
Réinstallez propre : créez une VM Windows Server 2019 « golden », joignez au domaine, réinstallez RDS/agents, et rattachez les UPD après validation.
Évolution de plateforme : profitez de la fenêtre pour basculer SeaBIOS→OVMF/UEFI si possible.

Critères de succès et validation

0 évènement 41/6008 au bout d’un cycle hebdomadaire complet.
Absence d’ID 129/153 (storvsp/vioscsi) et d’ID WHEA 18 sur la période.
Taux de logon RDS stable, pas de VHDX « fantôme » ni de profils temporaires.
Courbes PerfMon lissées : file d’attente disque < 1 au 95e percentile, latence réseau stable.

FAQ

Pourquoi n’ai‑je aucun BSOD si le système plante vraiment ?

Un reset hyperviseur, une perte brutale d’alimentation ou un hard‑lock CPU peut empêcher l’OS d’écrire un bugcheck. C’est typique quand l’ID 41 affiche des paramètres « 0 ». C’est pourquoi le dump noyau et la corrélation hôte sont essentiels.

Les UPD peuvent‑ils provoquer des redémarrages ?

Indirectement. Des time‑outs SMB/VHDX ou une corruption peuvent déclencher des blocages noyau (filtres système, storvsp/vioscsi) et, in fine, un reset par watchdog. D’où l’importance d’une latence stable et d’exclusions AV correctes.

Un plan d’énergie « Équilibré » suffit‑il en VM ?

En RDS, « Haute performance » est plus prévisible sous charge concurrente. Côté hôte, des C‑States profonds peuvent allonger les sorties d’inactivité et perturber les timers ; évitez‑les si vous suspectez des micro‑freezes.

Faut‑il migrer immédiatement vers OVMF/UEFI ?

Non, mais c’est souvent bénéfique. OVMF corrige des subtilités ACPI/SMBIOS et fiabilise la gestion des interruptions/timers. À planifier lors d’une fenêtre de maintenance.

Modèle de journalisation à transmettre au support

• Période des incidents (UTC/local) :
* Fréquence :
* Horodatages précis des ID 41/6008 :
* Évènements corrélés (WHEA, storvsp/vioscsi, volsnap, Disk, SMB) :
* Build Windows et LCU :
* Versions virtio (netkvm/vioscsi/viostor/balloon) :
* Microcode BIOS/UEFI/SeaBIOS :
* Hôte OpenStack/Virtuozzo (nova/libvirtd/qemu) – extraits :
* Réseau vers partage UPD (latence moyenne/P95, MTU) :
* Tests menés (SFC/DISM/CHKDSK, MemTest, DiskSpd) et résultats :
* Dump(s) analysé(s), module fautif s’il y a :

Conclusion

Le triptyque hôte → système → pilotes est la seule voie robuste pour résoudre des redémarrages « sans cause ». En activant des dumps noyau, en corrélant finement les journaux (WHEA, storvsp/vioscsi, SMB, RDS) et en modernisant firmware/microcodes/virtio, vous identifierez l’élément fautif. Dans un environnement RDS, ajoutez la sécurisation des User Profile Disks et des compléments applicatifs (Merit/Microsoft 365). Si la cause demeure ambiguë, reconstruire une VM propre et basculer l’ancienne en observation reste souvent le chemin le plus court vers une plateforme stable.

Annexe — procédures pas‑à‑pas (copier/coller)

Basculer l’alimentation en « Haute performance »

powercfg /setactive SCHEME_MIN
powercfg /l

Exporter les 300 derniers évènements Système pertinents

Get-WinEvent -LogName System -MaxEvents 300 |
  Where-Object { $_.Id -in 41,6008,129,153,51,57,104,1074 } |
  Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
  Format-List

Lister les pilotes virtio installés

Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DriverProviderName -match 'Red Hat|Virtuozzo|KVM|Virtio' } |
  Select-Object DeviceName, DriverVersion, DriverDate, DriverProviderName

Vérifier l’état des VHDX d’UPD montés

Get-Disk | Get-Partition | Get-Volume | Select-Object DriveLetter, FileSystem, HealthStatus, SizeRemaining
Get-SmbConnection | Select-Object ServerName, ShareName, NumOpens, Dialect

Lancer SFC/DISM et planifier CHKDSK au prochain redémarrage

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
chkdsk C: /f

Forcer la création de dump (si console disponible)

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters' -Name CrashOnCtrlScroll -PropertyType DWord -Value 1 -Force
# Puis sur la console : maintenir Ctrl droit et appuyer deux fois sur Scroll Lock

Points de vigilance spécifiques à votre contexte

SeaBIOS 2014 : accumulation de correctifs ACPI/SMBIOS depuis. Une mise à jour/migration OVMF lève de nombreux cas limites de timers/veille.
AMD EPYC (IBPB) : certains microcodes anciens ont montré des comportements erratiques sous charge I/O. Mettez à jour au dernier microcode stable.
Build Windows 17763.5933 : même si récente, assurez‑vous que la LCU appliquée est postérieure, surtout si des correctifs storage/ACPI y figurent.
UPD sur disques dynamiques : supportés mais sensibles aux filtres/AV. Documentez précisément les exclusions et la maintenance des VHDX.

En appliquant ces vérifications de l’hyperviseur vers la VM, puis du système vers les pilotes, vous isolerez l’élément à l’origine des arrêts brusques et rétablirez la stabilité des deux serveurs de sessions.