Compact GUI Crashing on start ; Smart Screen Protection ; Windows Environment Variables ; .Net Framework

[Mode3rn]

I have 1 desktop using Windows 10 build 14393.8066 where CompactGUI crashes on startup, and the latest version 4.0b1 is prevented by Windows Defender SmartScreen. The only way CompactGUI starts is when it is set to Windows 8 compatibility mode and Run as Admin.

I think the reason for this is that my System Environment Variable paths are not Windows default. I have not been able to find any other workaround other than Compatibility Mode setting.

I have not tested this hypothesis extensively because I am so stumped with other issues, this might be an issue with .NET rather than the program itself. This is using the FULL CompactGUI build "Mono"

Is there a specific reason why this program cannot be made compatible with a widely installed Windows default framework versions?

Version 4.0 is just so much better! Thank you.

[Iridium-IO]

What do you mean your environment variables aren't default?

Also, for the one crashing on startup, are you running it directly from the root of the drive? That was a bug I fixed in the beta without releasing a new version, so if you redownload it that might fix it (I released the updated version about 12 hours ago) - it's still called 4.0 Beta 1 so just watch out for that.

After you get the new version, can you provide the crash logs from the Event viewer?

You'll have to bypass Smartscreen, that's pretty normal for files downloaded from the Internet

[Mode3rn]

What do you mean your environment variables aren't default?

Also, for the one crashing on startup, are you running it directly from the root of the drive? That was a bug I fixed in the beta without releasing a new version, so if you redownload it that might fix it (I released the updated version about 12 hours ago) - it's still called 4.0 Beta 1 so just watch out for that.

After you get the new version, can you provide the crash logs from the Event viewer?

You'll have to bypass Smartscreen, that's pretty normal for files downloaded from the Internet

My environment variables for Appdata Local are on a different drive : like E:\AppData-Local-Temp
While IridiumIO sets env variable at C:\Users\Me\AppData\Local\IridiumIO

I had to remove CompactGUI folder from AppData local and use version 3 to start the program
Then I start version 4.0b1

Both have been crashing consistently but after removing CompactGui, version 4.0b1 started again only if Run as Admin

If I attempt to run without admin privileges the program crashes.

I think the problem is on my end. For some reason writing to the Registry is denied. I am not exactly sure why this is the case as I have not done any changes to prevent writing to the registry.

I have 2 logs from Event Viewer here

CompactGUI Error Log 1.txt

CompactGUI Error Log 2.txt

Edit : I found this I'm not sure if this is helpful

https://serverfault.com/questions/125615/how-to-set-executionpolicy-access-to-registry-key-denied

Additionally, No other applications have any issues reading/writing to the registry

Dot Net desktop runtimes are fully updated, versions 8 and 9

[Mode3rn]

Addition :

Using only "Mono" versions

Version 4.0b1 crashes if launched first, even when launched as Administrator

To start 4.0b1
Version 3.8 has to be launched first as Administrator.

This is all on default settings without making any changes to configuration files.

DotNet Framework versions are both updated to :

windowsdesktop-runtime-9.0.5-win-x64/32
windowsdesktop-runtime-8.0.16-win-x64/32

Configuration file :

{
"SettingsVersion": 1.2,
"ResultsDBLastUpdated": "2025-05-31T18:14:09.6995007-04:00",
"SelectedCompressionMode": 0,
"SkipNonCompressable": false,
"SkipUserNonCompressable": false,
"WatchFolderForChanges": false,

"SkipUserFileTypesLevel": 0,
"ShowNotifications": false,
"StartInSystemTray": false,
"MaxCompressionThreads": 0,
"LockHDDsToOneThread": true,
"EnableBackgroundWatcher": false,
"EnableBackgroundAutoCompression": false,
"AllowMultiInstance": false,
"EnablePreReleaseUpdates": false,
"IsContextIntegrated": false,
"IsStartMenuEnabled": false

[Iridium-IO]

If you enable the start menu and Context Menu integration from within the settings, does it also crash? If you do enable it, can you then see it in the context menu in windows explorer (the expanded context menu if you're on windows 11)

[Mode3rn]

If you enable the start menu and Context Menu integration from within the settings, does it also crash? If you do enable it, can you then see it in the context menu in windows explorer (the expanded context menu if you're on windows 11)

So I will outline the steps I have taken from start to finish :

Fresh Start by removing IridiumIO folder from AppData Local

1. Launch version 4 = Crash

2. Launch version 3.8 (Administrator, otherwise Crash). Did not touch any settings, close program.

3. Launch version 4b1 (Administrator, otherwise Crash). Program starts up. After using program, Close program.

4. Start Version 4b1 again, and Crash.

5. Start version 3.8. Close it. Then Start Version 4b1 (No crash)

6. Once 4b1 is started, Change various settings, and repeat process. Same results. Crash.

*Repeat Process = Fresh starting 4b1, without having to start 3.8 first.

7. Both procedures repeated with and without Start Menu and Context Menu integration settings, does not seem to matter.

Important Note * : Version 3.8 MUST be started first, and Only then version 4b1 starts, without crashing.

In ALL cases, Administrator condition is Required, for all of the steps above.

More : Program also crashes when a New folder is added, while a compression task is already in progress.

More 2 : No issues with any other program that requires DotNet frameworks. No issues with any other programs. User account is Admin, and can elevate to Admin privileges if necessary. The Operating system is running on most default settings. DISM checks are 100%, Image is clean, and mostly default.

Edit : Sorry about so many edits.

[Iridium-IO]

What I mean is, ignore whatever other reasons there are for crashing, just get to the point where it does start.

Once it's started, go into the Settings tab, and toggle the start menu and context menu options. Do those options actually work and do what they're supposed to do?

[Mode3rn]

What I mean is, ignore whatever other reasons there are for crashing, just get to the point where it does start.

Once it's started, go into the Settings tab, and toggle the start menu and context menu options. Do those options actually work and do what they're supposed to do?

1. Clicking the program exe, The program Window opens, and then the Program window closes immediately after. The windows program compatibility/troubleshooting dialog opens, and from there I click Close.

a) I have already toggled both Start menu and Context menu options as unchecked as I do not need that function. Instead, I use a shortcut to open the program, or by directly double clicking it.

b) Yes those 2 options work. They create a Start Menu entry, as well as a Right Click Context Menu entry. Yes, they do what they are supposed to do. Only the Program crashes. ---- Read/Write does work to Appdata/Local

As of right now, Since I already started the Program, used the program, and then closed it. Subsequently, after about an hour or so I am able to open version 4b1 again without having to open version 3 first. However, the program has to be started with Administrator condition, or it will crash regardless of any of its settings. Version 3 also exhibits the same behavior and will crash/close if its not run as Administrator.

Update :

I moved the Version 4b1 to another folder on the Root of drive C: (OS), and opening the program without admin permissions results in a dialog box "CompactGUI has stopped working. A problem caused the program to stop working correctly. Please close the program" --> Close the program.

Then, I set the executable to Run as Administrator, and the Program starts fine with its pre-existing Settings unchecked (No Start menu, No Context menu)

It needs admin permission to start.

I will continue to test further and report on this issue. But honestly, I am not able to understand why it needs Admin permission in order to start at all. If I remove that permission, Both version 3.8 and 41b will simply not start. (Crash/close)

[Iridium-IO]

Can you try this version to see if it works without crashing? I couldn't figure out why I was using that registry entry (probably from an older version) so I just deleted it. The fact that the other two options (for start menu and right click context menu) still works means CompactGUI can write to the necessary parts of the registry anyway 🤷

CompactGUI.zip

[Mode3rn]

Update 1 for today :

I am not sure what is going on here, very strange findings.

So when the last post was made, Version 4b1 was able to start, close, and start without issues. Repeatedly.

After the PC was put into sleep mode for ~6 hours. Re-awakened, and attempted to start Version 4b1, the program window opens, and program crashes with "CompactGUI has stopped working"

So after some time passes, and CompactGui is started, it crashes. Very strange.

Will try the above version and will report again after some time passes.

Update 2 : SUCCESS : The new version 4.0.0+273 Starts without requiring Admin permissions. Started program a total of 10 times.

4.0.0+273 Start condition : No changes to AppData/Local were made. Nothing was deleted. The program starts up without administrator permission.

Then attempted to start 4b1 (with and without Admin permissions) and it crashed.

Will continue to test 4.0.0+273 and report back if any strange findings come up.

Thank you once again. If you have the time, could you kindly explain what you think might have been causing this and what changes you made in 4.0.0+273? Appreciate it.

Edit : I notice the file size for the version you uploaded is significantly smaller than 4b1_mono.

Deleted Registry Keys for testing :

HKEY_CURRENT_USER\Environment > C:\Users\UserName\AppData\Local\IridiumIO

HKEY_CURRENT_USER\SOFTWARE\IridiumIO

HKEY_USERS[User]\SOFTWARE\IridiumIO

HKEY_USERS[User]\Environment\IridiumIO

Restarted 4.0.0+273 and it did not Crash. Will report if it does.

[Iridium-IO]

Great :) well assume it's working for now, but let me know if that changes.

The new file is smaller because it's not the "mono" version. The mono version is too large to share in a github comment, but it's a sign you don't need the mono version anyway.