5 % d’utilisation du CPU au repos sans que le service ne soit même en cours d’exécution
15 à 20 % au repos avec le service actif
C’est un i7 de 9e génération à 8 cœurs et il consomme 20 % au repos ?
Version 2.5 Beta 5 (oui, je peux mettre à jour, mais si rien n’a été changé à ce sujet, je ne vois pas l’intérêt pour le moment)
Je vois la même chose. Un thread dump du thread fautif dans MCE Buddy en utilisant Process Explorer de Sysinternals semble montrer qu’il est bloqué dans une sorte de connexion réseau ou de recherche DNS (pour quelque chose qui n’existe pas dans le DNS, comme un autre processus sur localhost ou un autre hôte sur le réseau local interne ?). J’obtiens cette utilisation inexplicablement élevée du CPU en plus de “impossible de se connecter au serveur”, et j’ai noté les détails dans un autre thread.
Si seulement quelqu’un ayant une compréhension de la situation pouvait en partager un peu.
Merci d’avoir signalé ce problème. J’ai reproduit le problème et isolé la cause racine. Cela se produit lorsque le client GUI tente de déterminer s’il s’exécute localement ou sur une machine distante (Windows effectue une recherche DNS pour son nom d’hôte, ce qui provoque une utilisation excessive du processeur). Nous travaillons sur un correctif.
Le problème de CPU a été corrigé dans la version BETA 2.5.6 d’aujourd’hui
Merci mon pote, je vais essayer.
Peut confirmer corrigé dans la version BETA 2.5.6 du 27-04-2021.
Je ne suis pas d’accord :\
Je suppose qu’il y a une certaine amélioration… Je ne suis plus à ~20 en moyenne, mais maintenant ça oscille entre 10 et 16.
Édition : Après avoir observé le processus pendant quelques minutes, il semble y avoir un schéma. Il monte en pic et reste pendant une minute ou une minute et demie, puis tombe à rien pendant environ 10 secondes. Et ça recommence encore et encore. Donc on dirait qu’il essaie de faire quelque chose, ça expire, puis il réessaie quelques secondes plus tard ?
Essayez d’exécuter SysInternals Process Explorer (téléchargez-le directement depuis Microsoft.com) et copiez/collez la pile de threads du thread qui consomme le CPU.
Oui, je peux si nécessaire. J’espère que les symptômes leur feront comprendre le problème.
Je suppose que pour l’instant je vais simplement tuer le service et le redémarrer quand il y aura un retard. Cela contredit un peu le but, mais pas quand il consomme autant d’utilisation.
Je ne vois pas le service utiliser de CPU au repos. Avez-vous essayé de désactiver les paramètres UPnP et pare-feu ?
Ils n’ont jamais été activés mon pote. J’ai vérifié quand tu as envoyé la capture d’écran et ils étaient déjà décochés.
Je ne parviens pas à reproduire le problème ici, surveillez-vous des dossiers réseau ?
Il peut être utile d’utiliser l’outil mentionné par @mike808 pour isoler l’endroit exact où il consacre son temps CPU, ce qui peut donner des indications sur les prochaines étapes.
clr.dll!LogHelp_NoGuiOnAssert+0x5e8c9
clr.dll!LogHelp_NoGuiOnAssert+0x5e206
clr.dll!LogHelp_NoGuiOnAssert+0x5e3e8
clr.dll!LogHelp_NoGuiOnAssert+0x431a8
clr.dll!LogHelp_NoGuiOnAssert+0x43e06
clr.dll!LogHelp_NoGuiOnAssert+0x5b71c
clr.dll!LogHelp_NoGuiOnAssert+0x5c25f
clr.dll!LogHelp_NoGuiOnAssert+0x5c173
clr.dll!LogHelp_NoGuiOnAssert+0x5dfb7
clr.dll!LogHelp_NoGuiOnAssert+0x60207
clr.dll!LogHelp_NoGuiOnAssert+0x40108
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.String.InternalSubString+0x24
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ParseSetting+0x102
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.Parse+0x1b6
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ReadFromString+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Util.dll!MCEBuddy.Util.Ini..ctor+0x57
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.CheckAndAddFile+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.ScanForFiles+0xdf8
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.RunInternal+0x172
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x15
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x55
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ThreadHelper.ThreadStart+0x55
[Unmanaged to Managed Transition]
clr.dll!LogHelp_TerminateOnAssert+0x1b93
clr.dll!LogHelp_TerminateOnAssert+0x1aa4
clr.dll!LogHelp_TerminateOnAssert+0x2358
clr.dll!MetaDataGetDispenser+0x12a2f
clr.dll!LogHelp_TerminateOnAssert+0x2f50
clr.dll!LogHelp_TerminateOnAssert+0x2ec3
clr.dll!LogHelp_TerminateOnAssert+0x2e02
clr.dll!LogHelp_TerminateOnAssert+0x2fe7
clr.dll!MetaDataGetDispenser+0x12919
clr.dll!LogHelp_TerminateOnAssert+0x6835
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Donc c’est en cliquant sur « Stack » dans l’onglet « Threads » de l’explorateur, ce que je suppose être ce à quoi vous faites référence. Cela provenait d’un état inactif avec ~16 %.
Le chemin qu’il surveille se trouve dans Drivepool. D:/MCEBuddy où D est une instance Drivepool. Cependant, les disques du pool sont tous connectés à la même machine, donc non, ce n’est pas une surveillance à travers un réseau.
Bizarre. On dirait qu’il analyse le fichier de configuration pour quelque chose, puis effectue une opération qui nécessite peut-être une élévation UAC ou une entrée utilisateur, mais ne peut pas l’obtenir.
Pourrait-il s’agir d’un problème de jeu de caractères ou d’encodage ? @AustinWBest utilises-tu un clavier international, des options de système de fichiers, ou bien les chemins contiennent-ils des « guillemets intelligents » ou d’autres caractères non-US ? Les valeurs par défaut ont-elles été définies ? Juste pour écarter l’hypothèse qu’il essaie d’obtenir une sélection utilisateur impossible, car Windows ne peut pas récupérer d’entrée console dans certains cas (surtout les pilotes, mais ce n’est peut-être pas le cas ici).
Cela ne pose pas de problème avec mon MCEBuddy, mais souvent les noms contenant des apostrophes (« Cook’s Kitchen » ou « Rory O’Connell ») sont analysés avec une apostrophe courbe fermante plutôt qu’une apostrophe droite (ou l’inverse), et atterrissent dans des répertoires et noms de fichiers différents. Cela affecte aussi les métadonnées, mais c’est mineur.
Peut-être que tes dossiers sur le DrivePool utilisent un encodage de caractères différent de celui du fichier de configuration, ou quelque chose d’aussi étrange se passe.
@Goose devrait creuser pour savoir si l’utilisation de DrivePool modifie des choses (les API ?) dont MCEBuddy a besoin, si c’est la source du problème. Je n’utilise pas DrivePool, donc pas de retour de mon côté.
Vérifiez votre fichier History, votre fichier manual et les autres fichiers de configuration de MCEBuddy. L’un d’eux est peut-être corrompu. Commencez par effacer les fichiers history et manual (supprimez-les simplement) et si cela ne résout pas le problème, vous devrez peut-être procéder à une réinstallation complète.