CPU à fond svchost.exe

Thank you for sharing the solution. It is fascinating that switching the hypervisor hardware resolved the issue.

Regarding your hypothesis about drivers or memory instructions: while possible, it is unlikely to be a "memory instruction" error (which typically causes a BSOD or immediate crash/reboot) or a standard driver fault.

Based on the symptoms you shared (RtlInitializeResource consumption) and the resolution (changing CPU frequency/architecture), this is almost certainly a Timing-Dependent Race Condition, often referred to as a "Livelock" or "Spinlock" issue.

Here is the technical breakdown of why this likely happened on the 4.2GHz AMD system but not the 2.8GHz Intel one:

1. The Spinlock Effect: The function RtlInitializeResource implies the UserManager service was trying to acquire a lock on a shared resource (like a registry key or user token). When a thread cannot get a lock, it "spins" (loops actively) checking if the lock is free. On a very high-frequency processor (4.2GHz), the thread spins incredibly fast. If there is a flaw in the software's logic, the thread can spin so aggressively that it starves the very process that is supposed to release the lock. This creates a self-sustaining loop of 100% CPU usage.
2. Timing Sensitivity: Race conditions are strictly timing-based. The specific instruction pipeline speed and architecture of the AMD EPYC (Infinity Fabric latency vs. core speed) likely aligned perfectly to trigger this software bug in Windows Server 2022. By moving to a slower clock speed (2.8GHz) and a different architecture (Intel), you effectively altered the thread scheduling timing just enough to bypass the race condition.
3. Windows Scheduler & AMD Topology: Windows Server 2022 has had occasional scheduling quirks with high-core-count AMD EPYC processors regarding how threads are moved across CCX (Core Complexes). It is highly probable that Microsoft needs to patch usermgr.dll to better handle the specific throughput capabilities of your AMD hardware.

In short, the hardware is likely healthy, but the Windows software code was not optimized to handle the speed and topology of that specific AMD configuration, causing it to trip over its own feet.

If you find this answer useful, please vote for it so that others would benefit too. Thank you.

VP

Bonjour,

le souci a été résolu en basculant ma VM sur un autre hyperviseur avec des processeurs INTEL avec fréquence moins élévée (2.8Ghz)

(nous étions en AMD actuellement à 4.2GHZ)

Actuellement plus de souci svchost les consommations sont raisonnables.

C'est possible qu'un driver soit en cause ou des problèmes d'instruction mémoire entre le CPU et la RAM, qu'en pensez-vous ?

Encore merci pour votre expertise.

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

Bonjour,

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

Merci pour votre aide.

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.