Travis, "archiver" ne vous a pas aidé. En fait, même effacer le journal des événements lorsqu'il était au 2/3 n'a pas aidé. Mais "archive" a aidé KraigM.
kce: effacé un fichier "écraser" de 131 Mo et vu les performances chuter de disons 55% o 5% mais QUESTION: peut-être avez-vous finalement vu une nouvelle utilisation élevée car cela ne peut (a) être déclenché que lorsque la condition d'écrasement est atteinte ou (b) il peut s'aggraver linéairement à mesure que le fichier effacé passe de 0 Mo à 131 Mo.
Certains le voient pour le security.evtx et on l'a vu pour le journal opérationnel du Planificateur de tâches. Je suggère de désinstaller complètement votre AV (lequel utilisez-vous) et d'essayer. Les intrus doivent masquer leurs traces et leurs traces sont effectuées dans les tâches planifiées qu'ils configurent ou les connexions qu'ils effectuent. Ils cacheront donc leurs traces en cassant les poignées de ces journaux d'événements et en les réécrivant pour ignorer leurs traces. Les AV peuvent être en train de détecter cela dans un buggy, car s'il s'agissait de Microsoft, une plus grande partie de cette utilisation élevée aurait été signalée, mais je ne vois que peu de messages lors de la recherche sur Google. Je vois également cela sur le serveur 2008 R2 pour le journal security.evtx. Aucun abonné au journal des événements, aucun moniteur externe. J'ai observé quelques services AV (McAfee) en cours d'exécution et leur utilisation totale pour un serveur était très faible pendant tant de jours, donc je soupçonne qu'il a été désinstallé et seulement partiellement (il a probablement besoin du programme de désinstallation spécial de McAfee) et je me demande s'il y a des crochets dans le vestige (ou même normalement installé) du service McAfee ou des pilotes de filtre McAfee en cours d'exécution qui prennent en quelque sorte une écriture normale dans le journal des événements et décident dans leur filtrage qu'ils doivent en faire une lecture complète de tout le journal des événements. Croyez-moi, les pilotes de filtre tiers de certaines sociétés audiovisuelles sont bogués et certainement 10000x plus bogues que la mise en œuvre par Microsoft de la journalisation des événements, ce qui est très probablement parfait. En résumé, désinstaller à 100% TOUS VOS AV ET VOIR SI le problème se résout. Si tel est le cas, collaborez avec votre entreprise audiovisuelle pour réparer leur AV. Il est déconseillé de faire des exceptions de fichiers pour.
De plus, lorsque vous utilisez procmon, faites attention aux appels WriteFile car c'est le fichier Writefile qui déclenchera le gestionnaire de filtres pour lire l'intégralité du fichier. Dans mon cas, la lecture a été lancée environ 30 secondes après la fin de l'écriture, ce qui pourrait être voulu par la conception même du produit. Mais il était cohérent et dans mon cas, le fichier était de 4 Go et le fichier lu impliquait 64 000 fichiers de lecture de 64 Ko chacun et il utilisait 35% du processeur pour y parvenir. Très triste.
Mise à jour 23/03/2016 J'ai regardé les pilotes de filtre sur cette machine après avoir conclu que cela devait être causé par l'un d'eux (le mécanisme du journal des événements ne pourrait jamais être bogué seul ou le nombre de rapports de ce type serait stupéfiant et ce n'est pas). J'ai vu des pilotes de filtre d'un AV et d'une société tierce bien connue qui améliore les performances du disque de la machine virtuelle avec des lectures à venir et j'ai demandé à leur architecte en chef (qui était très gentil et courtois) si son produit pouvait lire de manière trop agressive l'ensemble journal des événements de sécurité (ce qui se passait clairement par procmon). Cela serait utile pour les journaux de sécurité plus petits, mais pas ceux des tailles indiquées ici. Pas du tout ce qu'il a dit. Il a convenu que ce pourrait être l'AV.
Comme je l'ai dit au boursier Azure ci-dessous, nous n'avons pas de suivi de l'affiche originale si le problème est réapparu après avoir effacé le journal des événements, car il s'agit d'une solution courante et erronée car les performances se dégradent à nouveau avec le temps. C'est ce qu'on appelle le "suivi" et je vois de visu que la solution de l'affiche originale peut tromper ceux qui ne font pas de suivi en leur faisant croire qu'ils ont résolu le problème. J'ai aussi failli être dupe. J'ai effacé le journal des événements et les performances ont été améliorées - mais j'ai utilisé procmon et j'ai vu le problème se développer et se développer lentement au fil du temps jusqu'à ce qu'il devienne problématique. Pour une raison quelconque, le boursier Azure me critique sévèrement lorsque l'affiche originale n'a pas suivi (peut-être est-elle décédée, a-t-elle été licenciée, a-t-elle quitté ou s'est-elle occupée)? Le boursier Azure ci-dessous pense que si l'affiche originale n'a pas suivi, cela doit être un problème fixe. C'est vexant et déroutant parce que je ne peux penser à personne qui est si hautement considéré techniquement qui prendrait cette position. Je m'excuse si j'ai piqué un nerf. Peut-être que dans mon activisme ailleurs sur Internet où j'appelle des gens, je suis devenu nerveux - ici (erreur de serveur), je suis simplement gentil et partage des connaissances techniques approfondies et le résultat de M. Azure est de savoir si ma contribution technique est égale nécessaire ou est pour un de mes blogs (je n'ai pas un tel blog). Je n'ai pas encore l'intention d'envoyer ce lien à une demi-douzaine de copains clés de Microsoft et de leur demander ce qu'il se passe avec ce type d'intimidation de la part d'un employé clé de MSFT parce que je suis particulièrement concentré sur le meilleur intérêt de la communauté à l'esprit et les réponses ci-dessous de M. Azure sont, en quelques mots, incroyables, vitrioliques, énervant et intimidant - ce que je suis sûr que certaines personnes aiment faire aux autres. J'ai d'abord été offensé, mais je m'en remets et je sais que les lecteurs passifs ou actifs apprécieront ce que je dis et apprécieront mes commentaires - je suis à 100% derrière sans égard pour les raisons juridiques qui font qu'il est subtilement inapproprié ici ou non. M. Azure, s'il vous plaît, faites preuve de gentillesse et évitez de jeter mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas encore commenter. s'il vous plaît, faites preuve de gentillesse et évitez de formuler mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas commenter encore une fois. s'il vous plaît, faites preuve de gentillesse et évitez de formuler mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas commenter encore une fois.
Harry