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