S3 1 Tio
S3 1 Tio
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Windows 11 corrige en urgence la surchauffe de certains ordinateurs Dell

Ça va comme les vagues de chaleur

Windows 11 corrige en urgence la surchauffe de certains ordinateurs Dell

Photo de Paul Bulai sur Unsplash

Microsoft a publié une nouvelle version de son Patch Tuesday à destination des ordinateurs Dell qui présentaient un sérieux problème de surchauffe. Pour ces machines, le téléchargement et l’installation automatique avaient été coupés. Il est maintenant de retour.

Le Patch Tuesday de juillet a corrigé 570 failles dans Windows 11, marquant un record absolu pour Microsoft, presque le triple du mois précédent. Dans cette mise à jour mensuelle, on trouvait également une nouvelle interface système pour le gestionnaire de connexions USB-C.

Quelques jours plus tard, rien n’allait plus : certains ordinateurs Dell présentaient des problèmes de surchauffe, de performances fortement dégradées et d’autonomie nettement réduite. La faute à une incompatibilité avec le composant Innovation Platform Framework d’Intel, chargé de l’allocation thermique, des limites d’alimentation (Power Limits PL1/PL2) et des politiques de refroidissement passif/actif au niveau du processeur.

Depuis ce 18 juillet, une nouvelle mise à jour est proposée par Windows Update pour résoudre le problème, Microsoft ayant été en contact avec Intel. Elle a été publiée hors cycle mensuel, une procédure que Microsoft n’utilise en général que pour les problèmes les plus sérieux.

Une mise à jour pour… tout le monde

Le nouveau correctif semble effectivement corriger le problème, mais il est déployé curieusement sur l’ensemble des machines si vous avez activé l’option « Recevez les dernières mises à jour dès qu’elles sont disponibles ». L’une de nos machines l’a ainsi reçue, nécessitant un triple redémarrage. Attention, ce n’est pas un comportement louche, cela peut arriver avec certaines mises à jour, ne forcez pas l’extinction de la machine.

Au sujet des modèles initialement concernés, Windows Latest en donne une liste compilée depuis ses sources :

  • Dell Pro Max 14 Premium MA14250
  • Dell Pro Max 16 Premium MA16250
  • Dell Pro Precision 7 14 PW714260
  • Dell Pro Precision 7 16 PW716260
  • Precision 5470, 5480, 5490 et 5770
  • XPS 17 9720 et 9730

Nos confrères signalent que les machines non concernées par le défaut ne devraient pas installer la mise à jour et fustigent le manque de précision de Microsoft dans la nomenclature de ces téléchargements. Si vous n’avez fait aucun changement dans Windows Update, le correctif attend dans les mises à jour optionnelles, comme l’indique Microsoft dans ses notes de version.

L’entreprise ajoute que cette mise à jour « est uniquement recommandée pour les appareils concernés par ce problème » et devrait s’installer automatiquement sur les ordinateurs dont le Patch Tuesday avait été bloqué à cause de l’incompatibilité. Dans le cas de notre machine, non concernée par le problème, aucun comportement étrange n’est à déplorer cependant malgré de multiples essais (bureautique, jeux, sur secteur ou non…).

Commentaires (27)

votre avatar
Le nombre de modèles concernés parait ridiculement faible comparé au nombre important de gens qui ont des occupations processeur à 100% pendant des plombes dès que windows fait des mises à jour.

Ce qui est incroyable en plus, c'est le débit famélique de téléchargement des mises à jour Windows.
votre avatar
C'est clair. À chaque màj Windows j'ai l'impression que ma connexion fibre rame à mort... Et finalement non c'est juste le serveur Windows Update qui est à la ramasse.
votre avatar
Ce qui est incroyable en plus, c'est le débit famélique de téléchargement des mises à jour Windows.
Quand Microsoft pousse une mise à jour à l'ensemble de son parc, cela représente quand même plusieurs centaines de millions de machine d'un coup. Et le téléchargement se faisant automatiquement en arrière plan, le faible débit n'est absolument pas gênant pour un utilisateur.

A contrario, le débit "poutrerait", on aurait des plaintes de joueurs fulminant contre Windows pour avoir perdu leur joueur en mode hardcore à cause d'un lag provoqué par le téléchargement de la dernière MaJ :mdr:
votre avatar
Parle pour toi, pour ceux qui utilisent Windows pour le travail notamment en station de travail avoir un service d'arrière plan qui consomme des ressources réseau/disque/cpu pdt une plombe est loin d'être agréable, l'idéal étant de pouvoir màj le plus vite possible afin d'en être débarrassé.

Je rejoins donc ce qui a été dit au dessus pour une entreprise aussi riche qui possède son propre service de cloud il est assez incompréhensible que leur CDN soit si lent à distribuer les màjs. Les CDN Rhel/Debian/Ubuntu sont eux bien plus rapides avec pourtant beaucoup moins de moyens.
votre avatar
En entreprise, il y a souvent un serveur local pour les mises à jour, il me semble afin entre autre de différer les mises à jours après des tests sur le parc interne.
Il suffit donc de dimensionner ce serveur afin qu'il servent correctement tout le parc.

Je ne suis pas sûr que l'on puisse comparer Windows et Rhel, Debian ou Ubuntu en terme de nombre de clients et donc de trafic.
votre avatar
Pas dans les TPE/PME
votre avatar
Oui, historiquement, c'est le serveur "WSUS" qui gère ça.
Mais Microsoft abandonne son développement (cf : https://www.it-connect.fr/microsoft-met-fin-au-developpement-de-wsus-pour-windows-server/) et transfère cela sur ses offres cloud.

Cela pose problème dans mon établissement, dans le sens où nous ne souhaitons pas payer un service plus cher pour gérer des mises à jour qui l'étaient auparavant en On-premise.
votre avatar
Avec WSUS oui. Comme il est deprecié pour être remplacé par Intune, je ne sais pas si ce dernier propose des serveurs cache pour éviter de flinguer la bande passante.
votre avatar
Oui, c’est clair que ce n’est pas comparable. Avec tous les containers sous Linux à 90% et plein de CI/CD qui retéléchargent tout à chaque fois, le trafic sur les serveurs des distribs Linux utilisées en cloud doit être démentiel.
votre avatar
service d'arrière plan qui consomme des ressources réseau/disque/cpu pdt une plombe est loin d'être agréable
Euh... on parle quand même d'un simple téléchargement. Donc la consommation de ressources pendant une plombe elle est quand même très marginale. C'est lors de l'installation que la consommation est plus importante. Mais l'installation se fait... après le téléchargement !
Les CDN Rhel/Debian/Ubuntu sont eux bien plus rapides avec pourtant beaucoup moins de moyens.
Oui. Et beaucoup moins d'utilisateur aussi. Et beaucoup plus de fragmentation. Et pas de téléchargement des mises à jour toute en même temps.
Je rejoins donc ce qui a été dit au dessus pour une entreprise aussi riche qui possède son propre service de cloud il est assez incompréhensible que leur CDN soit si lent à distribuer les màjs
Au delà du CDN, je pense que les FAI doivent aussi apprécier qu'il n'y ait pas des millions de machine qui téléchargent un contenu de parfois plusieurs Go en même temps à une vitesse folle.

Et avoir un CDN surdimensionné juste pour un usage 1x par mois pour quelque chose qui n'a pas d'impact pour 99,99% des utilisateurs, est-ce vraiment nécessaire ?


Je veux bien croire que ce soit un problème pour certains. Mais dans ce cas, svp, donner moi un réel exemple concret, car pour l'instant, honnêtement, je ne vois pas.
votre avatar
-> Non le téléchargement n'est pas que après l'installation enfin en tout cas la séparation n'est pas si absolue, il y a du téléchargement pendant l'installation et également un séquencement entre les màj qui fait alterner les cycles téléchargement/installation quand il y a besoin de reboot par exemple. Et pendant l'étape du téléchargement je confirme qu'il y a une utilisation non négligeable du CPU et de la RAM pour une raison que j'ignore (probablement une décompaction).

-> En ce qui concerne la distribution des màj pour les FAI tu confonds 2 problèmes : la vitesse à l'instant T et la distribution à un large parc d'utilisateurs. Les grands éditeurs ont un mécanisme de distribution +/- différé des màj pour ne pas abattre le CDN mais également mitiger le risque d'une màj merdeuse. Le problématique de surcharge CDN/FAI que tu mentionnes se règle à ce niveau là pas à la vitesse à l'instant T du téléchargement.

-> En ce qui concerne un exemple concret je te l'ai donné plus haut : qqn qui se sert de sa machine comme une station de travail, généralement en TPE ou PME.
votre avatar
Non l'installation n'est pas après le téléchargement, il y a du téléchargement pendant et également un séquencement entre les màj
Parce qu'on ne parle pas de la même chose. Tu parles du processus de mise à jour, qui peut appliquer plusieurs mises à jour de manière séquentielle. Une mise à jour donnée (un KBxxx) ne commencera son installation qu'une fois entièrement téléchargée, et il n'en est pas possible autrement, car il y a une vérification d'intégrité qui est faite.

Le processus de mises à jour peut télécharger & installer des mises à jour en même temps. Une mise à jour précise ne peut pas s'installer pendant son téléchargement.
Le problématique de surcharge CDN/FAI que tu mentionnes se règle à ce niveau là pas à la vitesse à l'instant T du téléchargement.
Windows est un des rares logiciels à être autant déployé. On parle de plusieurs centaines de millions de machines (voir même dépassant le milliiard). A ce niveau, ce n'est pas qu'une simple répartition de charge dans le temps.
En ce qui concerne un exemple concret je te l'ai donné plus haut : qqn qui se sert de sa machine comme une station de travail, généralement en TPE ou PME.
Donc tu te plains de l'installation des MaJ, pas de leur téléchargement.
votre avatar
"Donc tu te plains de l'installation des MaJ, pas de leur téléchargement."
Non mais les 2 sont liés, tu le dis toi même plus haut. Quand je travaille je suis prêt à allouer du temps pour cette tache, par exemple une fois par semaine pendant 10min comme avec une distrib Linux.
Or je constate qu'au moment où je décide de démarrer la mise à jour dans son ensemble (dl + install), le téléchargement est bien trop lent et qu'il pourrait être plus rapide c'est aussi simple que ça. Autrement dit, comme avec Linux (enfin surtout rhel/dnf car l'implémentation apt de debian ne permet pas le téléchargement en //), je veux voir le graph de ma carte réseau au max de ce que permet ma ligne et mes graphs de CPU/RAM/IO au max de ce que mon matériel permet, dans la limite de ce que permettent les algorithmes en œuvre notamment en terme de parallélisme.

"Windows est un des rares logiciels à être autant déployé. On parle de plusieurs centaines de millions de machines (voir même dépassant le milliiard). A ce niveau, ce n'est pas qu'une simple répartition de charge dans le temps."
Pour moi cet argument n'est pas recevable : Microsoft est une entreprise gigantesque en terme de capitalisation qui possède son propre fournisseur de cloud et même son propre CDN. En outre, en terme d'équivalence on peut citer les milliards de smartphones Apple/Android de la planète dont les màj se font à forte vitesse.
votre avatar
Pour moi cet argument n'est pas recevable : Microsoft est une entreprise gigantesque en terme de capitalisation qui possède son propre fournisseur de cloud et même son propre CDN. En outre, en terme d'équivalence on peut citer les milliards de smartphones Apple/Android de la planète dont les màj se font à forte vitesse.
D'un côté, on compare donc un acteur unique devant mettre à jour "seul" un parc de plusieurs centaines de millions de machine, et de l'autre, on a plusieurs acteurs (les constructeurs, pas les éditeurs d'OS, même si parfois les deux se confondent) qui déploient des mises à jour sur des appareils extrêmement récent, sur plusieurs modèles, pas en simultané, et encore, quand le modèle est toujours pris en charge.
je veux voir le graph de ma carte réseau au max de ce que permet ma ligne et mes graphs de CPU/RAM/IO au max de ce que mon matériel permet
La question c'est pourquoi ? Le processus de MaJ de Windows est assez transparent. On le remarque rarement. Généralement, quand le ventilo se met à tourner à plein régime sans raison apparente, c'est soit un programme qui fait une action en douce, soit un scan antivirus, soit l'indexation de Windows (une vraie plaie se truc), soit une mise à jour cours d'installation. Et on les remarque bien évidemment quand un redémarrage est nécessaire.

Mais à vous lire, on a l'impression que c'est un processus totalement bloquant qui empêche de travailler pendant des heures. A part le cas de @wanou, où je comprends très bien que le dépanneur à domicile ait autre chose à faire que d'attendre que la mise à jour se télécharge, c'est indolore pour l'utilisateur.

Alors pourquoi Microsoft (ou une quelconque entreprise d'ailleurs), se forcerait à mettre l'infrastructure réseau nécessaire pour que "le graph de la carte réseau soit au max" 1 fois par mois ?? Le processus est ce qu'il est aujourd'hui. Il n'est pas parfait. Mais prétendre que la vitesse de téléchargement est un problème, c'est juste de la mauvaise fois, tant c'est invisible pour les utilisateurs (hormis quelque cas particulier).
votre avatar
Manifestement tu ne lis pas ce que j'écris, j'ai été pourtant clair : j'ai une station de travail avec des tâches de compute/io assez lourdes, pour que j'organise mon temps ce processus doit être le plus déterministe possible c-a-d que je dois pouvoir anticiper le temps nécessaire au mieux (car réunions, rendus etc.).
Or le processus de mise à jour consomme des ressources et donc augmente de façon incertaine le temps nécessaire à chacune de ces tâches, c'est pourquoi je veux pouvoir mettre à jour (dl + install) dans une fenêtre de temps donnée quand je l'ai décidé donc pas en tâche de fond et le plus rapidement possible car ce temps est une perte sèche.
votre avatar
Manifestement tu ne lis pas ce que j'écris
Ou si tu donnais toutes les informations dès le début cela éviterait peut être effectivement ce genre de débat. Oui, tu as parlé de station de travail. Non, à aucun moment, tu n'as parlé de tâches lourdes en CPU/IO, ni du besoin de déterminisme. Juste d'un "je veux voir mes graphes au max".

Bravo, tu fais donc parti des 0.01% pour qui c'est un véritable problème. Et après, c'est toi qui me disait "Parle pour toi" alors que justement, tu projettes ton cas d'utilisation très spécifique sur l'ensemble des autres usagers...
votre avatar
T'y fait la nuit sinon ou en 12h00 et 14h00

Windows update a un mode ou il va récupérer les mises à jour sur les autres PC du parc de l'entreprise, ça soulage les serveurs de Microsoft dés qu'il y a une machine qui est à jour
votre avatar
@fdorin

Quand on doit faire des mises à jour chez un particulier dont le windows est plus qu'a la ramasse, c'est beaucoup trop lent.

Et, contrairement à ce que tu affirmes, la consommation CPU est très élevée pendant ce téléchargement là.

Je l'ai constaté sur tous les ordi physiques ou virtuel que j'ai eu à mettre à jour et pas dans un contexte d'entreprise. Il semble aussi que beaucoup de gens dans le monde s'en pleignent aussi.
votre avatar
Quand on doit faire des mises à jour chez un particulier dont le windows est plus qu'a la ramasse, c'est beaucoup trop lent.
Ca c'est un cas d'usage effectivement auquel je n'avais pas pensé. Le dépanneur qui se déplace pour un dépannage à domicile.
Et, contrairement à ce que tu affirmes, la consommation CPU est très élevée pendant ce téléchargement là.
Attention, Windows à tendance à installer plusieurs MaJ en parallèle. Et il peut commencer à faire l'installation d'une MaJ déjà téléchargée pendant qu'il en télécharge une autre.

A chaque fois que j'ai constaté une consommation de ressource, c'était parce qu'il y avait une MaJ en cours d'installation en arrière plan, pas à cause du téléchargement lui-même.
votre avatar
Tu vas sur microsoft catalog et tu télécharge la ou les mises à jour nécessaires en amont
votre avatar
Le nouveau correctif semble effectivement corriger le problème, mais il est déployé curieusement sur l’ensemble des machines si vous avez activé l’option « Recevez les dernières mises à jour dès qu’elles sont disponibles »
2 possibilités complémentaires que je vois pour expliquer cela :

  • si Dell était majoritairement touché, rien n'indique que d'autres configurations ne puissent pas l'être dans des conditions spéciales, ou que le bogue était présent mais avec des conditions moindre (un peu de surchauffe par rapport à ce qui est attendu, mais pas autant que ce qui a été observé sur les Dell). Et donc proposer la correction d'un bogue partout même si on n'est pas visiblement touché, c'est pas déconnant

  • c'est aussi pour essayer d'homogénéiser le code. Pourquoi les Dell auraient la version "bidule" alors que les autres auraient la version "machin" ?

votre avatar
Pour répondre à ta dernière question, la brève sur le sujet desDelle disait :
Il semble que seul Dell soit affecté, le constructeur ayant spécifiquement modifié le pilote pour l’interfacer avec ses propres firmwares (BIOS/UEFI). Pour l’instant, aucun autre cas n’a été signalé chez la concurrence.
Ça affaiblit aussi ton premier point si effectivement, c'était bien des spécificités liées au firmware des Dell du pilote qui donc entrait
en conflit avec une nouvelle interface système pour le gestionnaire de connexions USB-C, intégrée dans la mise à jour KB5101650.
J'ai d'ailleurs du mal à comprendre quel type de conflit peut arriver entre une communication avec le firmware et un gestionnaire de connexion USB-C ! Ça semble être des périmètres séparés.
votre avatar
Comme je le disais, le fait que le problème ait été révélé par les Dell ne signifient pas qu'il n'y a pas un bogue derrière qu'il faille corriger et qui pourrait survenir dans d'autres circonstances.

Et j'ai du mal à voir en quoi cela affaibli l'argumentation. Dell a modifié un pilote, ce qui a mis en avant un problème. Pourquoi Windows aurait donc 2 versions différentes de la partie noyau (pas le pilote donc) en fonction du matériel sur lequel il tourne ? Surtout si le problème résulte bien d'un bogue !
votre avatar
Intel IPF gère l'énergie et l'enveloppe thremique. De son côté, l'interface "power" d'USB type C interagit avec la gestion d'énergie. J'imagine que ça pourrait être sur cet aspect qu'il y aurai eut des frictions entre la version d'IPF modifiée par Dell et le nouveau gestionnaire USB-C intégré par Microsoft.
votre avatar
Bien vu. J'oubliais que l'USB-C permet gérer l'énergie de façon plus complexe qu'avant. Entre autre, il faut pouvoir basculer entre alimentation du PC par l'USB-C ou fourniture d'alimentation à un périphérique.
votre avatar
Actuellement mon latitude 7400 souffle comme pas possible et est très chaud pour du word et Outlook.


Donc non..
votre avatar
en même temps Dell et les problèmes de surchauffe c'est synonyme non ?
En tout cas tous les Dell que j'ai eu entre les mains c'est presque toujours le même soucis qui remonte le ventilo souffle tout le temps ou ça fait trop de bruit ou pc est super lent.
Le design interne est bien trop cheap par rapport au vrai tdp des cpu intel. Y a un micro radiateur avec un unique ventilo comment veux tu dissiper les 35 - 65W de PL1-PL2 donc le cpu monte instant à 99°C puis throttle à normalement 15W mais souvent moins car même ventilo à fond le micro radiateur ne peut pas dissiper 15W h24. Donc cpu throttle encore plus pas rare de voir des fréquences sous le GHz, cpu à fond à 90°C donc pc ultra lent.

Heureusement on est passé chez Lenovo depuis quelques années et les derniers Dell sont parti.
Des portables avec un bon gros châssis, de bon gros radiateurs et 2 ventilos là on cause. Certes ils sont plus épais et lourd mais au moins les users ne se plaignent plus. Et dans la même taille et poids que les Dell on a des Lenovo en amd, c'est réactif et super silencieux et froid avec un seul ventilo. Franchement c'est le jour et la nuit vive les cpu amd pour ça.

Faudrait comparer avec les dell récent en amd mais tellement eu marre de ces Dell intel que on n'est pas prêt d'en reprendre