Jeg opgraderede for nylig til 2.4.8 og kører Windows 10. Siden installationen af denne nye version får jeg en “Microsoft .NET Framework”-fejl, når jeg forsøger at starte brugergrænsefladen. “Unhandled exception has occurred” osv. “Access to the path ‘Global\MCEBuddy.GUI.exe’ is denied”. Hvis jeg fortsætter, indlæses grænsefladen, men den virker ikke; den viser blot XXX i stedet for den aktuelle version. Kan ikke køre jobs eller noget som helst. Jeg ser gentagne henvisninger til “canonical form” og, at jeg skal geninstallere eller foretage en ren installation. Jeg har ikke den fejl i Event Viewer, men jeg har prøvet både geninstallation og ren installation og har stadig samme problem.
Services.msc viser, at tjenesten kører, ligesom “net start” i kommandoprompt.
Hvis jeg manuelt stopper og genstarter tjenesten, starter den dog uden problemer. Derfor er jeg nødt til at gøre dette efter hver genstart. Nogen ideer?
UPDATE: Hvis jeg højreklikker på programgenvejen og vælger “Kør som administrator…”, får jeg en anden fejl, der siger “Cannot start duplicate instance” “MCEBuddy Status application is already running”.
Either your .NET configuration is corrupted w.r.t. to MCEBuddy
Your MCEBuddy installation is corrupted
2nd one is easy to fix, do a clean install (see the Common Issues topics for how to do a clean install)
For the first one you would need to run a .NET repair / reinstall utility
I’ve tried the clean install, and the manual uninstall to no avail.
I just tried Microsoft’s .net repair tool, and it didn’t seem to do anything either.
Because .NET is incorporated into Windows 10, it pretty much makes it impossible to uninstall and download a new version. Parts of .NET appear to be available for deactivation through Windows Features. Disabling and re-enabling all .NET windows 10 features did nothing.
It could be your antivirus or some software blocking access to the EXE file, try to disable your AV/Malware/Security/Defender etc.
Essentially when windows tries to start it automatically something is preventing it (a corruption may be unlikely given that you can start it manually by clicking on it and you’ve performed a clean install).
Unfortunately, I think this is a case of self-inflicted stupidity. Somewhere along the line, I had a scheduled task to open the MCEBuddy interface upon system start. I think it all got a little confused and was running the GUI process without it being opened. I didn’t even remember that scheduled task was there until I was looking to create a new one to automatically restart the service upon system start.
Godmorgen, jeg følger i dine fodspor og opgraderede lige fra 2.3.13 til 2.5.7. Jeg har også en Windows-startopgave til automatisk at indlæse programmet og oplever nu det samme (.NET-fejl ved indlæsning af GUI).
Jeg har justeret startkommandoen nedenfor, og det ser ud til at virke. Jeg kan dog ikke tilgå GUI’en efter den er startet og får .NET-fejlen. Så hvordan beholder du den automatiske opstart (fantastisk funktionalitet) og tilgår derefter GUI’en for at konfigurere ting?
Tak for dit hurtige svar. Det sætter jeg stor pris på.
Jeg havde brugt SRVSTART til at oprette en Windows-starttjeneste med nedenstående kommando. Dette virkede tidligere (2.3.13 – virkelig gammel), men gør det ikke længere (2.5.7 – nyt premium-medlem ). Jeg har prøvet to variationer – med lidt forskellige resultater (nedenfor).
startup=“C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe” -startmin -startengine
… Dette starter GUI’en (minimeret), men starter ikke længere tjenesten. Jeg får .NET-fejlen, når jeg forsøger at åbne GUI’en manuelt for at foretage konfigurationsændringer.
startup=“C:\Program Files\MCEBuddy2x\MCEBuddy.ServiceCMD.exe” -startmin -startengine
… Dette starter både GUI’en og tjenesten. Men jeg får stadig .NET-fejlen, når jeg forsøger at åbne GUI’en manuelt for at foretage konfigurationsændringer.
Windows-TJENESTEN bruger Local System-kontoen. Jeg har også prøvet at bruge admin-kontoen til dette med de samme resultater som beskrevet ovenfor.
Brug Windows Opgaveplanlægger til at starte GUI’en; du kan ikke starte GUI’en som en tjeneste, fordi det er en interaktiv app. Derfor er MCEBuddy opdelt i 2 dele: motoren kører som tjeneste, fordi den ikke interagerer med brugeren, og GUI’en kører som en brugerinteraktiv app for at kommunikere med motoren.
Tak igen. Jeg har sat GUI’en op som en planlagt opgave i Windows, der kører minimeret. Tjenesten starter et øjeblik senere fra Windows Services (MCEBuddy2x (auto, forsinket) – jeg tror, den blev oprettet af MCEBuddy under installationen; jeg oprettede den ikke selv). Så begge kører i Task Managers detaljer efter en genstart (Fantastisk!). Jeg kan dog stadig ikke tilgå GUI’en for at foretage konfigurationsændringer og får .Net Framework-fejlen fra den oprindelige tråd (screenshot vedhæftet).
Jeg kan omgå fejlen ved at afslutte GUI’en i Task Manager og derefter starte den manuelt (ikke ideelt, men det fungerer). Mit mål er dog, at alting (overvågning/konvertering) automatisk starter, når pc’en genstartes (uden login nødvendigt), men at jeg derefter kan logge ind og foretage konfigurationsændringer uden hver gang at skulle dræbe GUI’en i Task Manager. Tanker?
Endnu engang tak for al din hjælp. Jeg forstår det endelig nu (efter 1-5 dages fejlfinding)…
GUI’en behøver ikke at køre for, at MCEBuddy kan fungere fuldt ud i baggrunden, korrekt? Kun tjenesten er nødvendig. Med tjenesten alene vil MCEBuddy overvåge/konvertere som tidligere konfigureret, korrekt? (BEKRÆFT VENLIGST)
Da MCEBuddy automatisk oprettede sin egen tjenestestarter (Windows Services) under installationen, behøver jeg ikke tilføje noget. Jeg kan nu manuelt starte GUI’en uden fejl. Fejlene opstod kun, når jeg havde startet GUI’en via. Windows Services eller Task Scheduler først.
Korrekt, GUI’en bruges kun til at vise/opdatere status/indstillinger. Motoren kører uafhængigt i baggrunden.
Korrekt
Windows-tjenesten bør aldrig bruges til at starte et GUI-program af den grund jeg nævnte nedenfor. Fejlen du oplever skyldes, at du har angivet de forkerte/ukorrekte Windows-bruger-oplysninger til at starte GUI’en fra Task Scheduler. Den bruger (f.eks. System eller Control osv.) har ikke de nødvendige tilladelser til at starte en brugerinteraktiv GUI. Alle GUI-programmer skal startes ved hjælp af den loggede brugers legitimationsoplysninger, når de planlægges via Windows Task Scheduler (det er standardindstillingen, når en opgave planlægges).
). Jeg har prøvet to variationer – med lidt forskellige resultater (nedenfor).