|
kuehni Posts: 6
08/01/2022
|
First of all: thank you for this wonderful app, I use it for years now.
Contrary to the previous version, the version 7 cannot be launched on my device in the office anymore due to company's security settings. Unfortunately, the windows message gives no more details than "access blocked" and I have no clue, how to figure out the true reason.
Btw: As a workaround I looked for an option to download one of the previous releases. As your website offers the latest release only I was forced to search alternative download resources. It would be nice, if at least the preceeding version would still be available on your website.
edited by kuehni on 08/01/2022
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
08/01/2022
|
I think the block could be due to another reason. Which kind of AV software do you use in your company?
I'm asking because the SyMenu version 7.00 is reported as dangerous by Malwarebytes which is a widespread AV software. See the VT report for the SyMenu last version here https://www.virustotal.com/gui/file/7b580bf1730a8c8d440c0ade27ea8d770b38c9dbaf07279bfb54a4e19e0a894d
Just in case you have this AV in your office computer, you should report to the Malwarebytes guys the false positive.
I strongly doubt that a company can create a policy to block SyMenu without blocking any other software. Unless your IT department wants to hit SyMenu in person... but I don't think such an evil department could really exist...
|
|
|
link
|
|
kuehni Posts: 6
08/01/2022
|
Thank you for the prompt reply, I will check the AV software used by my company next Monday.
|
|
|
link
|
|
kuehni Posts: 6
10/01/2022
|
Short update: AV software is nothing spectacular: Windows Defender. My limited user rights on this device do not allow me to access the Window's security log. The previous Symenu version runs without any issues.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
11/01/2022
|
It's not Defender unless the version your company is using is outdated... but you can't check it because of your rights.
You can try another thing:
- update SyMenu to 7.00v;
- right click the executable and ask for the properties. Now check for the security block flag Windows set for files downloaded from the Internet. To have a clue on what I'm speaking, try to read this https://www.ugmfree.it/SyMenuManual.aspx#SyMenuPluginBlocked . It's related to SyMenu plugins but the main executable could be locked in the same way;
- if the problem was the previous one, check the other executable and unlock them all.
And please report here the outcome.
|
|
|
+1
link
|
|
kuehni Posts: 6
20/01/2022
|
Sorry for my delayed answer, it took me some time to perform this test. Surprisingly, the security block flag you mentioned is not available, neither on my private device nor on company's device. The Windows file property dialog shows only the checkboxes for the standard attributes (write protection, hidden ...), not the security section as shown in your example.
Nevertheless, I tried to update SyMenu to 7.00v on my private device instead on company's device as before. Both, the manual update by me as well as the automatic update by SyMenu, gave me a functioning version 7, even on company's device. Your hint might be correct, that files downloaded on company's device got an execution lock flag, although I wasn't able to check this.
During my tests I observed another issue with 7.00v. When quitting SyMenu, the application doesn't exit (on both devices). Instead the "green led" of the tasbar icon flashes for infinite time in an endless loop and the application doesn't response anymore. Reproducible I have to kill the SyMenu process using task manager when I exit Symenu 7.00v. This doesn't apply to the previous version. Luckily, this issue doesn't prevent the shutdown of windows, so I don't care about it as I don't exit SyMenu manually during normal usage.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
20/01/2022
|
Strange behavior above all because you've got it on both devices (private and company).
Can you send me in private your SyMenu configuration files (those ones inside the config folder)? I would like to check them.
|
|
|
link
|
|
kuehni Posts: 6
25/01/2022
|
You are right, SyMenu closes properly if the "Autoexec on close" flag is removed from the vbs script. Strange, as the script has not been changed and runs fine when manually launched. The script is nothing spectacular, it removes the context handler added by the "Autoexec on start" script (which still works with SyMenu 7):
*******
Dim WSHShell
Set WSHShell = CreateObject ("WScript.Shell")
On Error Resume Next
WshShell.RegDelete "HKEY_CURRENT_USER\Software\Classes\*\shell\Open with Notepad++\command\"
WshShell.RegDelete "HKEY_CURRENT_USER\Software\Classes\*\shell\Open with Notepad++\"
*****
Well, the style of the script is not nice, but it worked fine until SyMenu 7. Maybe I will rewrite both scripts implementing the context handler via ShellEx. SyMenu's Extension Manager does not allow to add the wildcard * as extension.
edited by kuehni on 25/01/2022
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
25/01/2022
|
Well there's a breaking change in 7.00 related to the management of working dirs (https://www.ugmfree.it/SyMenuDownload.aspx#changelog).
Before 7.00 the resolution or the working dirs, in some cases, worked the wrong way while now it's more consistent.
I suspect your problem could be tied with this change.
Regarding SyMenu's Extension Manager I'm very surprised that someone could find it useful.
As you know for sure, ExMan works by killing whatever process opens because of a managed extension file and, after the killing, it opens the file with the desired program, for example npp.
In other words, ExMan stages a sort of barbaric ritual every time it strikes, with dozens of dead processes on its path. It's like using a prehistoric club to play golf but it's the way Windows works and since I don't want to touch the registry... let's go with the club.
The wildcard for the extensions of ExMan is a nice solution and it's possible I'll implement it in the future.
I don't have a workaround for you so I fear you have to continue to add and remove registry keys to link your npp (it's another sort of prehistoric club but... it's Windows man...). 
I solved a problem very similar to yours replacing Windows Explorer with another more flexible program. This way I solved tons of Explorer issues at once and, above all, I customized function keys to open the currently selected file with the right editor or viewer.
|
|
|
link
|
|
kuehni Posts: 6
25/01/2022
|
Solution:
Any "autoexec on close" item refering to a vbs file instead to an executable file in the path element will block SyMenu's closure (regardless of the file content, it can be even blank). This can be solved by following approach:
- change path from vbs file to the script interpreter (e.g. "%SystemRoot%\System32\wscript.exe")
- move the vbs file to the program arguments (e.g. //nologo "#:\your path\your file.vbs")
|
|
|
link
|