Jeg ser det samme. En tråd-dump af den problematiske tråd i MCE Buddy ved hjælp af Sysinternals’ Process Explorer viser, at den er låst i en form for netværksforbindelse eller DNS-opslag (efter noget, der ikke findes i DNS, som f.eks. en anden proces på localhost eller en anden vært på det interne LAN?). Jeg oplever denne uforklarligt høje CPU-brug samt “kan ikke oprette forbindelse til server”, og jeg har beskrevet detaljerne i en anden tråd.
Tak for at have rapporteret dette. Jeg har genskabt problemet og isoleret den grundlæggende årsag. Det sker, når GUI-klienten forsøger at afgøre, om den kører lokalt eller på en fjernmaskine (Windows foretager en DNS-opslag på sit værtsnavn, hvilket forårsager overdreven CPU-brug). Vi arbejder på en løsning.
Edit: Efter at have stået og kigget på processen i et par minutter, ser der ud til at være et mønster. Den springer op og holder i et minut eller halvandet, falder så helt ned til ingenting i cirka 10 sekunder og gentager det igen og igen. Det ligner altså, at den forsøger at gøre noget, timouter, og prøver så igen et par sekunder senere?
Jeg gætter på, at jeg indtil videre bare slukker for servicen og starter den igen, når der er en opbakning. Det undergraver lidt formålet, men ikke når den sluger forbrug på denne måde.
Jeg kan ikke genskabe problemet her, overvåger du nogen netværksmapper?
Det kan hjælpe at bruge det værktøj, som @mike808 nævnte, til at isolere, hvor det præcist bruger sin cpu-tid, hvilket kan give fingerpeg om de næste skridt.
Det er at klikke på “Stack” i “Threads” fanen i exploreren, som jeg antager du henviser til. Dette var fra at sidde idle og bruge ~16%.
Den sti den overvåger er placeret som en del af Drivepool. D:/MCEBuddy hvor D er en drivepool instans. Dog er drevene i poolen alle tilsluttet samme maskine, så nej, det er ikke overvågning på tværs af et netværk.
Mærkeligt. Det ligner, at den parser konfigurationsfilen efter noget og derefter gør noget, der måske kræver UAC eller en form for brugerinput, men som ikke kan få det.
Kan det være et tegnsæt- eller kodningsproblem? @AustinWBest – har du et internationalt tastatur, filsystemindstillinger, eller måske indeholder stierne “smarte anførselstegn” eller andre ikke-US-ASCII-tegn? Er standarderne blevet sat? Bare for at udelukke, at den ikke forsøger at få et valg fra brugeren, som den ikke kan, da Windows ikke kan hente konsolinput i visse tilfælde (hovedsageligt drivere, men dette er måske ikke den situation).
Det giver ikke problemer med min MCEBuddy, men ofte vises navne med apostroffer i dem (“Cook’s Kitchen” eller “Rory O’Connell”), som bliver parset med en enkelt lukket anførselstegn i stedet for en apostrof (eller omvendt), og ender i forskellige mapper og filnavne. Det påvirker også metadata, men det er mindre vigtigt.
Måske bruger dine mapper på drivepoolen et andet tegnsæt end konfigurationsfilen, eller der foregår noget lignende underligt.
@Goose må undersøge, om brug af DrivePool ændrer noget (API’er?) som MCEBuddy skal bruge, hvis det er kilden til problemet. Jeg bruger ikke DrivePool, så ingen feedback der.
Tjek din History-fil, manual-fil og andre MCEBuddy-konfigurationsfiler. En af dem kan være beskadiget. Start med at rydde history- og manual-filerne (slet dem bare), og hvis det ikke løser problemet, kan det være nødvendigt med en ren installation.