View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014612 | MMW v4 | Other | public | 2018-01-10 01:35 | 2018-05-31 20:30 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 4.1.21 | Fixed in Version | 4.1.20 | ||
| Summary | 0014612: UAC and VirtualStore makes changes to MMW install folder unusable | ||||
| Description | Problem is that if C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files (x86)\MediaMonkey then any changes to C:\Program Files (x86)\MediaMonkey\ are not used eg like if user edits C:\Program Files (x86)\MediaMonkey\Scripts\Scripts.ini Which means that any new Scripts manually added by User are not loaded and listed. Current two workarounds are: 1. Delete C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files (x86)\MediaMonkey and if used new Scripts.ini will be created in Virtual Store 2. Disable VirtualStore https://devsector.wordpress.com/2017/03/05/switching-off-windows-virtual-store/ generally disabling of Virtual Store fixes such issues of using non updated version of file | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=89096 MVE-369-71297 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1864 | ||||
|
|
I wonder do we tweak correct Manifest we can prevent such issues? More info on teh matter at: https://docs.microsoft.com/en-us/visualstudio/deployment/trustinfo-element-clickonce-application https://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware ? |
|
|
a) Re Manifest: Petr indicated that we have embedded manifest with the default security settings. This means - MM is running with current user rights. I guess that changing it to administrator might be risky at this stage and would always force users to accept UAC prompt then (to be able to write to PF folder)? b) Disabling VirtualStore probably results in needless UAC prompt also and is preventing users without admin privileges to write to the scripts.ini? c) I guess that most users use the default choice to '[x] Install for the current user' when installing addon so they are not facing issues like this at all, right? d) In MVE-369-71297 you indicated that you have been able to reproduce the problem. Could you please provide the steps to reproduce? If I understand correctly if I install a script in the non-default config ('[] Install for the current user' is unchecked) then Virtual Store is creating another scripts.ini in the VirtualStore location (C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files (x86)\MediaMonkey) and not in C:\Program Files (x86)\MediaMonkey\ ?? I tried to install Scrobble DJ this way, but I cannot, because MMW doesn't even allow me to install to Program Files ("Scrobble DJ was not installed error") because it hasn't enough rights to write there. I can see the virtual store location, but scripts.ini is still presented only in C:\Program Files (x86)\ and edits/changes to the file are accepted by MM on run. |
|
|
a) I also think the same thing regarding your assumption and as pointed in thread I wondered if something can be added into manifest without compromising current behavior. b) Disabling Virtual Store is an workaround not a solution and as you pointed can make more problems than fix the issues. d) Further tests found that there is no problem in plugin installation issue simply can be replicated if you copy Scripts.ini from "C:\Program Files (x86)\MediaMonkey\Scripts" to "C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files (x86)\MediaMonkey\Scripts" and manually edit "C:\Program Files (x86)\MediaMonkey\Scripts\scripts.ini" to add or change it where after next start MMW will not use updated "C:\Program Files (x86)\MediaMonkey\Scripts\scripts.ini" but "C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files (x86)\MediaMonkey\Scripts\Scripts.ini" |
|
|
c) No matter if user select install per user or program files install looks like problem lies in in_mpc.dll which always creates "musepack.ini" in c:\Program files (x86)\MediaMonkey\Plugins\" and that triggers Virtual store to be created. |
|
|
c) yes, also in my case the musepack.ini is the only file in the virtual store location. Looks like a config file of in_mpc.dll plugin, but I doubt that it is somehow influencing the original issue as users usually don't need to edit the musepack.ini ? d) Peke, this is not how you _replicated_, but how you _simulated_ the issue. I doubt that the affected users manually copied scripts.ini to virtual store location, there must be something else that triggers the situation. Until we don't know exactly what is triggering the issue and the exact cause then it is rather for KB article only. |
|
|
c) That should not happen and should be fixed due the potential risk of any MMW crash trigger MMW fail under Fault Tolerant Heap and activate VirtualStore to preserve windows stability and it should be eliminated? d) I was replicated it by simulating the cause as exact trigger can't be determined after it happened. MMW have read access to c:\Program Files (x86)\MediaMonkey\Scripts\Scripts.ini and can determine if the file is newer than one in VirtualStore? This is not an new issue it happened in the past see http://tinyurl.com/ybf8huwm problem is rare and even rarer to be surfaced but very possible and should be addressed with a simple check in and deletion of old/outdated scripts.ini from VirtualStore as it shouldn't be there in a first place. e) When simulated any Script install to main scripts folder (MMW Run As Admin) like discogs is not shown as installed and users can't regain access to web tagging. Happened to me once while testing and I forgot to delete scripts.ini from virtual store, I can't determine how windows triage app and trigger it. |
|
|
c) ok, I will try to figure out why it is happening. e/d) ok, deleting scripts.ini from virtual store makes sense as a fix for 4.1.20 |
|
|
c) I haven't found sources for in_mpc.dll plugin in our SVN at all. The plugin isn't compiled by us and is supplied as is to the /Plugins/ folder during install. Looks like a very old winamp plugin? We could try to download a newer version of in_mpc.dll from the internet (if it exists) and test it. But doesn't seem to be a big deal. Assigned to Peke to check a new version and test. @Peke: Can you elaborate what do you mean by "should be fixed due the potential risk of any MMW crash trigger MMW fail under Fault Tolerant Heap and activate VirtualStore to preserve windows stability and it should be eliminated" ? How mousepack.ini is related to a MMW crash under "Fault Tolerant Heap" ? d/e) Fixed in 1864: scripts.ini is deleted from the VirtualStore location (if exists) |
|
|
Verified d/e in 1864 |
|
|
Verified 1868 and no other users reported such issue. |
