https://bugs.winehq.org/show_bug.cgi?id=45506
Bug ID: 45506 Summary: Waves Central Plugin Install Product: Wine-staging Version: 3.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: chopinbig2@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Somewhere between Wine Staging 3.10 and Wine Staging 3.13 some change seems to have occurred that breaks Waves Central and the current version of Waves Central can't install plugins anymore.
The current version of Waves Central does still work by reverting back to Wine Staging 2.21 so the problem seems to be in recent Wine Staging changes
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #1 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Does this working with normal wine?
A log with +msi may provide some incite.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #2 from Stan chopinbig2@gmail.com --- No it won't work with normal Wine because Waves Central needs some of the additions that Wine Staging has.
What happens is that Waves Central gets stuck in a loop continually calling tasklist.exe
This didn't happen with Wine staging before 3.10 and it doesn't happen with Wine Staging 2.21, so there seems to be some sort of change around 3.10 or maybe 3.11 that is causing this tasklist.exe loop.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #3 from Stan chopinbig2@gmail.com --- Wine Staging 2.21 (which works)
Waves Central calls WlanEnumInterfaces and continues with no tasklist.exe calls.
Wine Staging 3.13 (which gets stuck in a tasklist loop)
Waves Central calls WlanEnumInterfaces and then enters a tasklist loop with occasional WlanEnumInterfaces calls interspersed between multiple tasklist.exe calls.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #4 from Stan chopinbig2@gmail.com --- Tested with Debian Stretch and Ubuntu 18.04 with Wine Staging 3.13 and 3.12
Same results on both resulting in a tasklist.exe with occasional WlanEnumInterfaces loop.
I did a trace but didn't find much.
Something seems to have been altered in the Wine code that affects WlanEnumInterfaces I would guess.
The readout from the Terminal is
009c:fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot 009c:fixme:toolhelp:Heap32ListFirst : stub 0036:fixme:wlanapi:WlanEnumInterfaces (0x1, (nil), 0x5ead708) semi-stub 009c:fixme:msvcrt:__clean_type_info_names_internal (0x1e87c7e8) stub 009c:fixme:vcruntime:__telemetry_main_return_trigger (0xa360000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0xa2e0000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0xa190000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0xa140000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0xa0b0000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x9f30000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x9d90000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x1d110000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x9920000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x9720000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x9580000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x95a0000) 009c:fixme:msvcrt:__clean_type_info_names_internal (0x95161e0) stub 009c:fixme:msvcrt:__clean_type_info_names_internal (0x1e8de168) stub 009c:fixme:msvcrt:__clean_type_info_names_internal (0x1e7bef30) stub 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x90b0000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x180000000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x1d170000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x1d1a0000) 009c:fixme:vcruntime:__telemetry_main_return_trigger (0x1e000000) 009f:fixme:vcruntime:__telemetry_main_invoke_trigger (0x67000000) 009f:fixme:vcruntime:__telemetry_main_invoke_trigger (0x64000000) 0036:fixme:wlanapi:WlanEnumInterfaces (0x1, (nil), 0x5ead708) semi-stub 00a6:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00a8:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00aa:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00ac:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00ae:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00b0:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00b2:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00b4:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe" 00b6:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe"
etc etc
https://bugs.winehq.org/show_bug.cgi?id=45506
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Wine Component|-unknown |-unknown
--- Comment #5 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to Stan from comment #4)
Tested with Debian Stretch and Ubuntu 18.04 with Wine Staging 3.13 and 3.12
Same results on both resulting in a tasklist.exe with occasional WlanEnumInterfaces loop.
Nothing has changed in this function for over a year.
00a8:fixme:tasklist:wmain stub: L"C:\windows\system32\tasklist.exe"
This is just a stub program and returns nothing which might be the cause of the issue.
Again a +msi log should provide more details on what is going on.
I don't believe this to be a staging only bug at this stage even though you have to use staging to run it.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #6 from Stan chopinbig2@gmail.com --- Waves Central uses robocopy.exe.
When the plugin installation files are just about to be installed, is when Waves Central goes into the tasklist.exe loop and I think that robocopy.exe is used for the plugin installation, so maybe some change has been added to the last few versions of wine-devel/wine-staging that stops robocopy.exe from functioning as per usual.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #7 from Stan chopinbig2@gmail.com --- robocopy is in the Windows Server 2003 Resource Kit Tools and it needs some reg entries
environment string variables under HKEY_CURRENT_USER\Environment (New String Value)
COMMONPROGRAMFILES(X86) C:\Program Files (x86)\Common Files
PROGRAMFILES(X86) C:\Program Files (x86)
PUBLIC C:\users\Public
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- Is it known which Staging patches are necessary for the application to function?
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #9 from Stan chopinbig2@gmail.com --- Yes Waves Central uses the SetFileCompletionNotificationModes Wine Staging patches but they work ok.
The current Waves Central version worked fine with Wine Staging up until version 3.10 (or maybe 3.11 I'm not totally sure).
Waves Central now gets to the plugin install and enters an infinite loop calling tasklist.exe which is very strange because Waves Central didn't call tasklist.exe (as far as I can tell) with earlier than Wine Staging 3.10 versions including Wine Staging 2.21.
Waves Central also seems to go into the tasklist.exe infinite loop where it would likely be calling robocopy.exe to transfer the plugin files etc from the Waves server to the local wine prefix directories.
If some recent change to Wine or Wine Staging stops robocopy.exe from functioning normally then that might explain it, maybe.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #10 from Stan chopinbig2@gmail.com --- If anyone wants to test it
sign up at Waves for a demo and pick a demo
Download and install robocopy.exe (Windows Server 2003 Resource Kit Tools and robocopy also needs a mfc42u.dll 32 bit override).
Download and install Waves Central.
Run Waves Central and sign in and choose to install the plugins and that's when the tasklist.exe problem comes into it for Wine Staging 3.13.
Then try it with an earlier than 3.10 Wine Staging version or Wine Staging 2.21 and it's ok.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #11 from Stan chopinbig2@gmail.com --- Forgot to mention that Waves Central also needs the following reg entries added
environment string variables under HKEY_CURRENT_USER\Environment (New String Value)
COMMONPROGRAMFILES(X86) C:\Program Files (x86)\Common Files
PROGRAMFILES(X86) C:\Program Files (x86)
PUBLIC C:\users\Public
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #12 from Stan chopinbig2@gmail.com --- I tested previous Wine Staging versions for the bug from version 3.9 to 3.12 and the bug first appears in Wine Staging 3.12.
So something changed for Wine Staging (or devel) for version 3.12 that breaks Waves Central.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #13 from Stan chopinbig2@gmail.com --- Seems like the bug is in the changes for the Wine 3.12 version of cmd.exe (cmd.exe.so)
Replacing cmd.exe.so from Wine Staging 3.12 with the cmd.exe.so from Wine Staging 3.11 fixes the bug.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #14 from Stan chopinbig2@gmail.com --- One or more of the cmd.exe changes here https://source.winehq.org/git/wine.git/shortlog/refs/tags/wine-3.13?pg=3
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #15 from Gijs Vermeulen gijsvrm@gmail.com --- Just to verify, you tried wine-3.13? There was a cmd regression fix in that release.
Also, can you run a regression test to find out which specific commit broke it? See: https://wiki.winehq.org/Regression_Testing
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #16 from Gijs Vermeulen gijsvrm@gmail.com --- *** Bug 45541 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45506
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|Waves Central Plugin |Waves Central: Plugins |Install |don't install anymore
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #17 from Stan chopinbig2@gmail.com --- It's still in Wine 3.13.
I'll try to work out which cmd commit is causing the problems.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #18 from Stan chopinbig2@gmail.com --- The problem is this one
cmd: Add support for wildcards in if exist.
https://source.winehq.org/git/wine.git/commit/f53d57c8549dc439eb73354bfd37ac...
https://source.winehq.org/git/wine.git/patch/f53d57c8549dc439eb73354bfd37acd...
https://bugs.winehq.org/show_bug.cgi?id=45506
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |f53d57c8549dc439eb73354bfd3 | |7acd1e4e86cfd Component|-unknown |cmd
https://bugs.winehq.org/show_bug.cgi?id=45506
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |us@edmeades.me.uk
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #19 from Jason Edmeades us@edmeades.me.uk --- How can I recreate this? Can you attach a +cmd log please... There was a fix I put in for a regression introduced by the "if exists" - can you confirm this doesnt fix the problem please (f634fe15db1d6f09615505eb445b9e748720dbeb)
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #20 from Jason Edmeades us@edmeades.me.uk --- (In reply to Jason Edmeades from comment #19) Sorry, I wrote that when away from a computer and I've read the details in more depth. So I guess the key question is whether previously a batch program used the 'if' and only worked because it was actually not behaving, and hence the cmd fix is correct but has exposed an underlying problem (eg stub tasklist etc), or whether the fix to cmd is bad. From all the testing I have done on windows cmd.exe, I believe the fix to be good but as always there are so many combinations its impossible to know so we need to look at this specific one. I dont use wine-staging, only git based wine, so its hard for me to recreate.
As I said, the best move is to grab a +cmd log (ideally in good and bad case) and lets see the syntax of the command which looks bad, and if there is an underlying batch pgm we can look at its behaviour.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #21 from Gijs Vermeulen gijsvrm@gmail.com --- Created attachment 61973 --> https://bugs.winehq.org/attachment.cgi?id=61973 requested logs
(In reply to Jason Edmeades from comment #20)
In the attached archive you can find a good and a bad log (+cmd).
The good log was made with wine-3.11. I let the program install the plugin until the installation was complete.
The bad log was made with wine-3.13 (git). I let the program try to install the plugin for a while and then I cancelled the installation.
https://bugs.winehq.org/show_bug.cgi?id=45506
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL| |http://cf-installers.waves. | |com/WavesCentral/Install_Wa | |ves_Central.exe
--- Comment #22 from Gijs Vermeulen gijsvrm@gmail.com --- Also, confirming and adding download link.
I can also provide a test account (was made with a disposable email).
https://bugs.winehq.org/show_bug.cgi?id=45506
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |us@edmeades.me.uk
--- Comment #23 from Jason Edmeades us@edmeades.me.uk --- Ok, this is definitely caused by the if exists change, sorry...
if not exist fred mkdir fred if not exist fred\ echo oops
The first may (or may not) create the dir ok, but the second is firing to say it doesnt exist even though it does. FindFirstFileW doesnt like parms ending in a slash...
if not exist fred echo oops or if not exist fred. echo oops both work
I'll work on this and get a fix but it wont be until the weekend
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #24 from Jason Edmeades us@edmeades.me.uk --- Created attachment 61993 --> https://bugs.winehq.org/attachment.cgi?id=61993 patch
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #25 from Jason Edmeades us@edmeades.me.uk --- Does this patch get things working?
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #26 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Jason Edmeades from comment #25)
It fixes the problem for me, thanks.
https://bugs.winehq.org/show_bug.cgi?id=45506
--- Comment #27 from Jason Edmeades us@edmeades.me.uk --- https://www.winehq.org/pipermail/wine-devel/2018-August/130219.html
https://bugs.winehq.org/show_bug.cgi?id=45506
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |bc9d68bcbee5c9d4f4582f766a4 | |f552870385361 Resolution|--- |FIXED
--- Comment #28 from Gijs Vermeulen gijsvrm@gmail.com --- Fixed by: bc9d68bcbee5c9d4f4582f766a4f552870385361
Thanks for the fix Jason.
https://bugs.winehq.org/show_bug.cgi?id=45506
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paleozogt@gmail.com
--- Comment #29 from Jason Edmeades us@edmeades.me.uk --- *** Bug 45725 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45506
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.15.
-
wine-bugs＠winehq.org