CPU à fond svchost.exe

Bonjour Anthony CASSES,

Le coupable le plus probable dans ce scénario, surtout sur Windows Server 2022, est un conflit avec le Touch Keyboard and Handwriting Panel Service TabletInputService(). Même si vous n'utilisez pas les capacités tactiles, ce service tente d'initialiser pour chaque session RDP. Lorsque le UserManager service essaie de coordonner ces sessions, il se retrouve souvent coincé dans une boucle en attente de ressources (d'où la RtlInitializeResource trace de pile), ce qui conduit à la saturation du processeur que vous observez.

Pour résoudre cela, vous devez désactiver le service Clavier tactile, car il est généralement inutile pour un environnement RDS et constitue le déclencheur principal de ce blocage. Ouvrez votre console de services (services.msc), localisez le Clavier tactile et le service de panneau d'écriture manuscrite, arrêtez-le, et réglez son type de démarrage sur ____Désactivé. Sinon, vous pouvez exécuter cette commande PowerShell dans une invite surélevée pour le faire instantanément : Get-Service TabletInputService | Set-Service -StartupType Disabled -PassThru | Stop-Service -Force.

Une fois le service désactivé, l'utilisation du CPU devrait diminuer. Si le svchost.exe processus reste bloqué à 100 % immédiatement après l'arrêt du service, vous devrez probablement redémarrer le serveur une dernière fois pour effacer les threads bloqués. Ce changement de configuration devrait empêcher que le problème ne se reproduise.

J'espère que vous avez trouvé quelque chose d'utile ici. Si cela peut vous aider à mieux comprendre le problème, il est apprécié d' accepter la réponse. Si vous avez d'autres questions, n'hésitez pas à laisser un message. Bonne journée!

Vice-président

Bonsoir,

merci pour votre réponse mais j'avais déjà désactivé ce service depuis un moment.

Anthony

Anthony CASSES

nous sommes probablement en train de parler du problème de « fuite de règles de pare-feu » – la deuxième cause la plus fréquente de UserManager (svchost.exe) qui bloque Windows Server 2022 RDS. Voici quelques solutions :

Vérifiez le gonflement : Ouvrez regedit et naviguez jusqu'à la clé suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules Si vous voyez des milliers d'entrées ici, c'est clairement la cause.

1. Nettoyez le registre : Vous ne pouvez pas simplement les supprimer via l'interface graphique s'il y en a trop (cela peut se bloquer). Vous devriez utiliser un script PowerShell ou une commande élevée pour supprimer les valeurs de cette clé. Note : Faites d'abord une sauvegarde de la clé. Si la liste est énorme, il se peut que vous deviez renommer la FirewallRules clé en FirewallRules_OLD, créer une nouvelle clé vide FirewallRules , puis supprimer l'ancienne après un redémarrage. Prévenir la récurrence (La correction) : Vous devez ajouter une valeur de registre pour forcer le service Firewall à nettoyer ces règles. Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy

     Type: __DWORD (32-bit) Value__
   
        Name: `DeleteUserAppContainersOnLogoff`
   
           Value: `1`
   
           __Restart:__ Reboot the server. The `UserManager` service should no longer hang on `RtlInitializeResource` as the contention on the firewall policy is removed.
   

Bonjour,

j'ai essayé cette solution malheurereusement le souci est toujours d'actualité.

Merci pour votre aide.

Anthony

Bonjour Anthony CASSES,

La cause profonde n'a pas encore été identifiée, nous devrions donc essayer telle ou telle solution jusqu'à ce que nous la trouvions. J'espère que tu es encore assez patient.

Étant donné qu'il s'agit de Windows Server 2022 (qui partage une base de code centrale avec Windows 11) et que le problème concerne les UserManager ressources d'initialisation (RtlInitializeResource), le problème est presque certainement causé par __ des composants Shell modernes__ (en particulier « Chat » et « Actualités et Intérêts ») qui essaient de se provisionner pour chaque session RDS. Même si ces fonctionnalités ne sont généralement pas utilisées sur un serveur, les processus en arrière-plan tentent tout de même de s'initialiser, ce qui entraîne une condition de course et une saturation du processeur dans usermgr.dll.

Veuillez appliquer les deux correctifs suivants pour désactiver strictement ces fonctionnalités grand public.

Désactivez l'initialisation des « Chat » et « Flux »

Ces fonctionnalités sont connues pour provoquer UserManager des boucles sur les serveurs RDS à haute densité.

1. Ouvrez un PowerShell__ ou __ une invite__ de commande surélevée__.
2. Exécutez les commandes suivantes pour ajouter les clés du registre (vous pouvez aussi les ajouter manuellement via regedit) :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Chat" /v ChatIcon /t REG_DWORD /d 0 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Feeds" /v EnableFeeds /t REG_DWORD /d 0 /f

Ensuite, redémarrez le serveur.

Si le problème persiste après ce qui précède, il se peut qu'il UserManager soit bloqué en essayant de « précharger » les sessions utilisateur après un redémarrage ou une mise à jour. Cette fonctionnalité (ARSO) est souvent à l'origine du verrouillage « RtlInitializeResource » lorsqu'il tente de déchiffrer les identifiants des utilisateurs pour la connexion automatique.

Parcours de politique de groupe : Computer Configuration > Administrative Templates > Windows Components > Windows Logon Options

Paramètres : Connexion et verrouillage automatique du dernier utilisateur interactif après un redémarrage

Action : Réglé sur désactivé.

Puisque vous avez mentionné que cela a commencé après une mise à jour récente, si les changements de configuration ci-dessus ne font pas immédiatement baisser l'utilisation du CPU, je vous recommande de vérifier le __ journal opérationnel__ AppReadiness (Applications and Services Logs> Microsoft > Windows > AppReadiness Operational>). Si vous constatez des échecs répétés, la mise à jour a peut-être corrompu la base de données AppX, et il se peut que nous devions réinitialiser le dépôt AppX.

Vice-président