CPU à fond svchost.exe

Anthony CASSES 0 Points de réputation
2026-01-20T19:04:11.95+00:00

Bonjour,

depuis un peu moins d'une semaine (et peut-être à cause de la dernière KB déployée) mon serveur RDS sous Windows server 2022 a un comportement étrange.

Le matin vers 9h environ j'assiste à une saturation complète de mes 48 VCPU à 100 %, le processus mis en cause est Svchost.exe.

Le serveur est en production depuis 3 mois et fonctionnait parfaitement jusque là.

2026-01-20_15h58_18

2026-01-20_15h58_43

2026-01-20_15h46_41

2026-01-20_15h59_56

merci d'avance aux personnes qui pourraient m'aider.

Anthony

Windows pour les entreprises | Windows Server | Expérience utilisateur | Clients de bureau à distance
0 commentaires Aucun commentaire

7 réponses

  1. VPHAN 44,940 Points de réputation Conseiller indépendant
    2026-01-21T11:15:41.1566667+00:00

    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

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

  2. Anthony CASSES 0 Points de réputation
    2026-01-21T09:43:25.3366667+00:00

    Bonjour,

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

    Merci pour votre aide.

    Anthony

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

  3. VPHAN 44,940 Points de réputation Conseiller indépendant
    2026-01-20T22:41:03.6333333+00:00

    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.
      

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

  4. Anthony CASSES 0 Points de réputation
    2026-01-20T19:47:22.0733333+00:00

    Bonsoir,

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

    Anthony

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

  5. VPHAN 44,940 Points de réputation Conseiller indépendant
    2026-01-20T19:38:49.3466667+00:00

    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

    Cette réponse a-t-elle été utile ?

    0 commentaires Aucun commentaire

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur.