I recently upgraded to 2.4.8, and am running Windows 10. Since installing this new version, I get a “Microsoft .NET Framework” error when trying to launch the user interface. “Unhandled exception has occurred” etc. “Access to the path 'Global\MCEBuddy.GUI.exe” is denied. If I continue, the interface loads, but is not working, it just displays XXX instead of the current version. Can’t run jobs or anything. I keep seeing references to “canonical form” and that I need to reinstall or do a clean install. I don’t have that error in Event Viewer, but I’ve tried both a reinstall and a clean install and still have the same issue.
Services.msc shows that the service is running as does running “net start” in command prompt.
If I manually stop and restart the service, however, it comes up just fine. Consequently, I have to do this after every restart. Any ideas?
UPDATE: If I right click the application shortcut and “Run as administrator…” I get a different error, and it says “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.
Good Morning, I am following in your foot steps and just upgraded from 2.3.13 to 2.5.7. I also have a windows start task to automatically load the program and am now experiencing the same thing (.NET errors when loading GUI).
I’ve adjusted the startup command below and it seems to be working. However, I cannot access the GUI after its started and get the .NET error. So how do you keep the automatic startup (great functionality), and then access the GUI to configure stuff?
Thank you for your quick response. Always appreciated.
I had used SRVSTART to create windows startup service with the command, below. This was working previously (2.3.13 - really old) but now does not (2.5.7 - new premium member ). I’ve tried 2 variations - with slightly different results (below).
startup=“C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe” -startmin -startengine
… This starts the GUI (minimized) but no longer starts service. I receive the .NET error when trying to manually open the GUI to make config changes.
startup=“C:\Program Files\MCEBuddy2x\MCEBuddy.ServiceCMD.exe” -startmin -startengine
… This starts both the GUI and and service. But I still receive the .NET error when trying to manually open the GUI to make config changes.
The windows SERVICE is using the Local System account. I have tried using the admin account for this too with the same results described above.
Use the windows task scheduler to start the gui, you cannot start the gui as a service because it’s an interactive app. That’s why MCEBuddy is split into 2 parts, the engine runs as service because it’s not user interactive and the GUI runs as a user interactive app to communicate with the engine.
Thank you again. I set-up the GUI as a windows scheduled task. That is running minimized. The service starts up a few moments later from the Windows Services (MCEBuddy2x (auto, delayed) - I think this was created by MCEBuddy during installation, I didn’t make this one). So both seem to be running in the task manager details after a restart (Great!). However, I still cant access the GUI to make configuration changes and receive the .Net Framework error from this original thread (screenshot attached).
I can overcome the error by ending the GUI from the task manager and then launching it manually (not ideal, but workable). However, my goal is to have everything (monitoring/converting) auto-start as the PC is restarted (no login necessary). But then also be able to login and make configuration changes without having to kill the GUI from the task manager everytime. Thoughts?
Once again, thank you for all your help. I finally understand now (after 1-5 days of troubleshooting)…
The GUI does not need to be running for MCEBuddy to be fully functional in the background, correct? Only the service is needed. With the service alone, MCEBuddy will monitor/convert as previously configured, correct? (PLEASE CONFIRM)
Since MCEBuddy automatically created its own service starter (Windows Services) during installation, I do not need to add anything. I can manually start the GUI without any errors now. The errors were only an issue when I had started the GUI via. Windows Services or Task Scheduler first.
Correct, the GUI is only used to view/update the status/settings. The engine runs in the background indepedently.
Correct
Windows service should never be use to start any GUI application for the reason I mentioned below. The error you’re facing is because you’ve set the wrong/incorrect windows user credentials to start the GUI from the task scheduler. That user (e.g… System or Control etc) doesn’t have the necessary permissions needed to start a user interactive GUI. All GUI programs must be started using the logged in user credentials while scheduling it through a windows task scheduler (it’s the default option when scheduling a task).
). I’ve tried 2 variations - with slightly different results (below).