https://bugs.winehq.org/show_bug.cgi?id=55859
Bug ID: 55859 Summary: LabView 2023.3.1 fails to install Product: Wine Version: 8.19 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: alexhenrie24@gmail.com Distribution: ---
Created attachment 75381 --> https://bugs.winehq.org/attachment.cgi?id=75381 Terminal output
Steps to reproduce:
1. Extract ni-labview-2023-community-x86_23.3.1_offline.iso to a directory called ni-labview-2023-community-x86_23.3.1_offline
2. Run `chmod +r -R ni-labview-2023-community-x86_23.3.1_offline`
3. Run `winetricks dotnet48`
4. Run `winecfg` and change the Windows version back to 10
5. Run `winetricks d3dcompiler_47`
6. Run `wine Install.exe`
$ sha256sum ni-labview-2023-community-x86_23.3.1_offline.iso 654dec2f01a3ae2e13ac69dd22bb717fac25e625da1099f974676ea79516e7c5
https://bugs.winehq.org/show_bug.cgi?id=55859
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://download.ni.com/sup | |port/softlib/labview/labvie | |w_development_system/2023_Q | |3/ni-labview-2023-community | |-x86_23.3.1_offline.iso Keywords| |download, Installer
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #1 from Alex Henrie alexhenrie24@gmail.com --- The installer displays this error message:
An error occurred while installing a package: ni-systemlink-message-broker (23.5.1.49156-0+f4)
Additional error information: An error occurred while installing the MSI at 'nisystemlink_message_brokeri.msi'.
https://bugs.winehq.org/show_bug.cgi?id=55859
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Also needed to install "winetricks corefonts"
You can easily reproduce the issue by extracting "ni-systemlink-message-broker_23.5.1.49156-0+f4_windows_x64" and trying to install the msi from that.
Problematic is the call to net.exe with the arguments stop "NI SystemLink Message Bus" /y
First issue is that net needs to accept the /y switch, I created a MR for this at https://gitlab.winehq.org/wine/wine/-/merge_requests/4300
Then it fails with "Could not get handle to service". Not yet sure why.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- My setup is a bit weird right now, but it seems also be related to the exit codes of net.exe / sc.exe. Need to retest though.
Another issue that is definitely a difference from windows behavior is the following bat snippet:
------ @echo off setlocal enabledelayedexpansion set RABBITMQ_SERVICENAME="test kest" if "!RABBITMQ_SERVICENAME!"=="" ( echo Hi ) ------ This gives a "Syntax error" on Wine, in Windows not. Not sure why "winetricks cmd" doesn't work though... It works when running "wine cmd" but not when installing. Weird.
I'm afraid there is a bunch of issues at play here...
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- I implemented some changes in my test branch: https://gitlab.winehq.org/DarkShadow44/wine/-/commits/labview2
Most are probably irrelevant, but I'm still trying to get it to work at all.
With that branch and "winetricks cmd" (and copying cmd.exe from syswow64 into system32) I now get an error with "ni-visa-shared-components"
Although sometimes I still get "ni-systemlink-message-broker" issues like
07c0:err:eventlog:ReportEventW L"System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.\r\n" 07c0:err:eventlog:ReportEventW L"Parameter name: chunkLength\r\n" 07c0:err:eventlog:ReportEventW L" at System.Text.StringBuilder.ToString()\r\n" 07c0:err:eventlog:ReportEventW L" at NationalInstruments.RabbitMQConfig.Helpers.CommandLineUtility.CallExe(String args, Int32& exitCode, String& standardOutput, String& standardError, TimeSpan timeout, IReadOnlyDictionary`2 environment)"
Seems to be a race condition... Although it seems to be better now, I'll try to get the sc/net changes upstreamed, then maybe I'll work on the CMD issue.
Should I split off all those different bugs?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #5 from Alex Henrie alexhenrie24@gmail.com --- Interesting, it appears that Windows expands variables _after_ parsing the if parameters, but Wine expands them before: https://gitlab.winehq.org/wine/wine/-/blob/b1bd72343e49f68e42b4493055b1f5de9...
I can work on that problem while you deal with the sc/net problems. If I were you, I wouldn't bother making separate bug reports yet because we might be able to get most or all of these problems fixed quickly. Thank you for your help!
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Sure, if you know your way around cmd code that would be nice!
Last issue I found (so far) is probably bug 45455. This could be a huge pain to fix, since the function is completely undocumented. It's called from difxapi -> setupapi, but both are MS dlls that cleanroom guidelines forbid reverse engineering of. So, no idea how to deal with that.
https://bugs.winehq.org/show_bug.cgi?id=55859
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #7 from Zeb Figura z.figura12@gmail.com --- (In reply to Fabian Maurer from comment #6)
Sure, if you know your way around cmd code that would be nice!
Last issue I found (so far) is probably bug 45455. This could be a huge pain to fix, since the function is completely undocumented. It's called from difxapi -> setupapi, but both are MS dlls that cleanroom guidelines forbid reverse engineering of. So, no idea how to deal with that.
Wait, is difxapi.dll actually involved in bug 45455? As far as I can tell it's calling setupapi directly, but maybe I missed something.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Oh, you're right - it seems to be DIFxAppA. Not sure if that is off limits though.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #9 from Alex Henrie alexhenrie24@gmail.com --- difxappa.dll is closed-source and copyright Microsoft. Definitely off limits.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #10 from Fabian Maurer dark.shadow4@web.de --- Thought so. But then how do we get the proper function prototype? Never really had to deal with such an issue before.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #11 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #9)
difxappa.dll is closed-source and copyright Microsoft. Definitely off limits.
Well, it's off limits if we intend to reimplement it, as I understand. But I don't think reimplementing difxapp is an option. It's shipped by installers, and due to the way MSI works, it's not going to have the same name at runtime.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #12 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Fabian Maurer from comment #10)
Thought so. But then how do we get the proper function prototype? Never really had to deal with such an issue before.
Assuming the DLL is 32-bit, you can write a test program to determine the total number of bytes in the program's arguments: https://wiki.winehq.org/Wine_Developer%27s_Guide/Other_Debugging_Techniques#...
Once you have a stub that takes the correct number of bytes, you can look at what is in those bytes when the LabView installer calls the function, figure out the correct data types, and give the parameters appropriate names.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #13 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Zeb Figura from comment #11)
(In reply to Alex Henrie from comment #9)
difxappa.dll is closed-source and copyright Microsoft. Definitely off limits.
Well, it's off limits if we intend to reimplement it, as I understand. But I don't think reimplementing difxapp is an option. It's shipped by installers, and due to the way MSI works, it's not going to have the same name at runtime.
Isn't there a possibility that Microsoft might start distributing difxappa.dll with Windows, or that it shares code with some other DLL that we definitely do want to reimplement?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #14 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Alex Henrie from comment #12)
Assuming the DLL is 32-bit, you can write a test program to determine the total number of bytes in the program's arguments:
Typo: I meant in the function's arguments
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #13)
(In reply to Zeb Figura from comment #11)
(In reply to Alex Henrie from comment #9)
difxappa.dll is closed-source and copyright Microsoft. Definitely off limits.
Well, it's off limits if we intend to reimplement it, as I understand. But I don't think reimplementing difxapp is an option. It's shipped by installers, and due to the way MSI works, it's not going to have the same name at runtime.
Isn't there a possibility that Microsoft might start distributing difxappa.dll with Windows, or that it shares code with some other DLL that we definitely do want to reimplement?
Well, Microsoft deprecated DIFx back in 2016, so I don't think it's very likely at this point.
It's also worth noting that decompilation isn't the only thing that's off-limits in terms of determining what a native DLL does; checking what calls it makes into Wine is also off-limits. When it comes to native DLLs, either they work or they don't.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #16 from Fabian Maurer dark.shadow4@web.de --- Having a fix for bug 45455, there is another issue:
msi:msi_install_assembly failed to install assembly L"C:\users\fabian\Temp\msi72.tmp\Policy.1.0.Ivi.Visa.Interop.dll" (0x80070002)
I have a hack at https://gitlab.winehq.org/DarkShadow44/wine/-/commits/labview2 (msi hack). Then this part (visa-shared-components) finishes properly.
For testing I advise to - (Work around bug 45455 first) - extract the iso - Extract ni-visa-shared-components_7.2.0.49152-0+f0_windows_x64 - Extract data.tar.gz - Use 64bit WINEPREFIX - Run wine VisaSharedComponentsInstaller.exe VisaSharedComponents64.msi
After this all is fixes we have the next issue with "ni-error-report". Although I'd advise to focus on the existing issues first, otherwise it gets too much.
Say, would you mind tackling the msi topic? Not sure why it does wrong, but the source file simply doesn't exist, so CopyFileW fails.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #17 from Alex Henrie alexhenrie24@gmail.com --- cmd patch sent, feedback welcome: https://gitlab.winehq.org/wine/wine/-/merge_requests/4418
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #18 from Fabian Maurer dark.shadow4@web.de --- Still waiting on https://gitlab.winehq.org/wine/wine/-/merge_requests/4343, any idea what I should do?
https://bugs.winehq.org/show_bug.cgi?id=55859
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://gitlab.winehq.org/w | |ine/wine-staging/-/tree/mas | |ter/patches/setupapi-Driver | |StoreFindDriverPackageW
--- Comment #19 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Fabian Maurer from comment #18)
Still waiting on https://gitlab.winehq.org/wine/wine/-/merge_requests/4343, any idea what I should do?
Rebase the merge request every month until it gets more attention. The patch looks totally reasonable to me, and it's in Staging, which should help. Unfortunately, I don't know of anything else you can do to speed up the review process.
https://bugs.winehq.org/show_bug.cgi?id=55859
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://gitlab.winehq.org/w | |ine/wine-staging/-/tree/mas | |ter/patches/setupapi-Driver | |StoreFindDriverPackageW | See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45455 Status|STAGED |NEW
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #20 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #19)
Rebase the merge request every month until it gets more attention.
No, please don't do that. That wastes CI resources and doesn't help anything.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #21 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Zeb Figura from comment #20)
(In reply to Alex Henrie from comment #19)
Rebase the merge request every month until it gets more attention.
No, please don't do that. That wastes CI resources and doesn't help anything.
If the MR is not updated, people will think that it has been abandoned and that no one cares about it anymore. And if it is updated in a way that does not rerun the tests, people will be concerned that tests that were written after the patch was written might start to fail when the patch is merged. In my humble opinion, both of those considerations are worth more than than the cost to the CI server, which is probably not much if the submitter waits a full month between each rebase. However, if the Wine project leadership wants Fabian and me to stop rebasing when it's not strictly necessary, then we'll just have to defer to your preferences.
More to the point, what can we take off of your plate to give you (or whoever the appropriate reviewer might be) time to review the patch and identify specific action items to move it forward?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #22 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #21)
(In reply to Zeb Figura from comment #20)
(In reply to Alex Henrie from comment #19)
Rebase the merge request every month until it gets more attention.
No, please don't do that. That wastes CI resources and doesn't help anything.
If the MR is not updated, people will think that it has been abandoned and that no one cares about it anymore. And if it is updated in a way that does not rerun the tests, people will be concerned that tests that were written after the patch was written might start to fail when the patch is merged. In my humble opinion, both of those considerations are worth more than than the cost to the CI server, which is probably not much if the submitter waits a full month between each rebase. However, if the Wine project leadership wants Fabian and me to stop rebasing when it's not strictly necessary, then we'll just have to defer to your preferences.
Commenting on the merge request is probably a better way to achieve that goal.
More to the point, what can we take off of your plate to give you (or whoever the appropriate reviewer might be) time to review the patch and identify specific action items to move it forward?
I should apologize for my silence, I've mostly had the feeling that it should be possible to create a better stub.
Somewhat relatedly, what this family of functions is probably supposed to do is actually functionality that I've implemented locally, but in a different place, and should probably be moved here. That would avoid the need to even stub it at all.
I've mostly wanted to find the time to look into the function and see if I could figure it out in more detail, or actualize my implementation. I haven't actually said anything, partly because of this, and partly because "I think it should be possible to do better" isn't really helpful either, inasmuch as you are looking for specific action items.
I actually am actively looking into it right now; I've identified the purpose of the "flags" parameter (it's actually the processor architecture) and I have some tests for find/add/delete that are passing on Windows 7, but I'm still trying to figure out how to make them pass on 8 and 10, and they need some cleaning up, and then I'll need to adjust my implementation to fit inside setupapi.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #23 from Zeb Figura z.figura12@gmail.com --- I'm trying to test my changes with this application, but I see:
0124:trace:msgbox:MSGBOX_OnInit L"Failed to update all feeds.\r\n\r\nVisit ni.com/info and enter the Info Code NIPMCommError for more information.\r\n\r\nAdditional error information:\r\nCannot open feed file: Z:\bridge\windows\bugs\55859\bin\./ni-package-manager-packages/Packages.gz"
and the main window complains of being unable to locate several packages. Did I miss a step somewhere?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #24 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Zeb Figura from comment #23)
I'm trying to test my changes with this application, but I see:
0124:trace:msgbox:MSGBOX_OnInit L"Failed to update all feeds.\r\n\r\nVisit ni.com/info and enter the Info Code NIPMCommError for more information.\r\n\r\nAdditional error information:\r\nCannot open feed file: Z:\bridge\windows\bugs\55859\bin\./ni-package-manager-packages/ Packages.gz"
and the main window complains of being unable to locate several packages. Did I miss a step somewhere?
You're just working on DriverStoreFindDriverPackageW, correct? Instead of LabView (which has lots of problems), maybe try one of the other programs mentioned at Bug 45455.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #25 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #24)
(In reply to Zeb Figura from comment #23)
I'm trying to test my changes with this application, but I see:
0124:trace:msgbox:MSGBOX_OnInit L"Failed to update all feeds.\r\n\r\nVisit ni.com/info and enter the Info Code NIPMCommError for more information.\r\n\r\nAdditional error information:\r\nCannot open feed file: Z:\bridge\windows\bugs\55859\bin\./ni-package-manager-packages/ Packages.gz"
and the main window complains of being unable to locate several packages. Did I miss a step somewhere?
You're just working on DriverStoreFindDriverPackageW, correct? Instead of LabView (which has lots of problems), maybe try one of the other programs mentioned at Bug 45455.
I did, but I'd like to get as much coverage as I can, especially for an undocumented function.
Does the error I mentioned look familiar at all?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #26 from Alex Henrie alexhenrie24@gmail.com --- Looks like step 2 should have been `chmod +rx -R ni-labview-2023-community-x86_23.3.1_offline` to make the directories readable/executable.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #27 from Fabian Maurer dark.shadow4@web.de --- Still a thing in wine-9.19, net.exe and sc.exe still have issues for "ni-systemlink-message-broker"
Then I get one of those errors:
0790:err:eventlog:ReportEventW L""C:\Program Files\National Instruments\Shared\Skyline\RabbitMQ\rabbitmq_server-3.11.17\sbin\rabbitmqctl.bat" await_startup\n" ... 0790:err:eventlog:ReportEventW L"Error: unable to perform an operation on node 'nisystemlink@localhost'. Please see diagnostics information and suggestions below.\r\n"
0284:err:eventlog:ReportEventW L"System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {884E2000-217D-11DA-B2A4-000E7BBB2B09} failed due to the following error: 80040154 Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG).\r\n"
0278:err:eventlog:ReportEventW L"System.AggregateException: One or more errors occurred. (Error generating certificate. Ensure the entered names are valid DNS names or IP addresses.) ---> System.Security.Cryptography.CryptographicException: Error generating certificate. Ensure the entered names are valid DNS names or IP "...
Depending on if I use install.exe, try to install "ni-systemlink-message-broker" directly before/after I tried install.exe
Currently can't get past that.
https://bugs.winehq.org/show_bug.cgi?id=55859
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |57365
--- Comment #28 from Fabian Maurer dark.shadow4@web.de --- I found another cmd issue preventing this from working, see bug 57365. Not sure why those Labview issues are so incredibly random sometimes, but this one should be easy to reproduce now.
https://bugs.winehq.org/show_bug.cgi?id=55859 Bug 55859 depends on bug 57365, which changed state.
Bug 57365 Summary: RabbitMQ crashes Erlang machine due to faulty cmd delayed expansion subsitution https://bugs.winehq.org/show_bug.cgi?id=57365
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #29 from Fabian Maurer dark.shadow4@web.de --- Created attachment 77406 --> https://bugs.winehq.org/attachment.cgi?id=77406 Log for ni-error-report issue
Now that bug 57290 is fixed, I got past "ni-systemlink-message-broker" using https://gitlab.winehq.org/DarkShadow44/wine/-/commit/afc3ef298e5a30013aebbc4...
Next issue is "ni-error-report":
044c:err:eventlog:ReportEventW L" NationalInstruments.PackageManagement.Core.NIPkgClientException: An error occurred while creating a process to run command '"C:\NIDummy\NI Error Reporting\nierserver.exe"'."
The program exists at "drive_c/Program Files/National Instruments/Shared/NI Error Reporting/nierserver.exe"
The correct data seems to be in the registry:
[Software\National Instruments\Common\Installer] 1731506542 "NISHAREDDIR64"="C:\Program Files\National Instruments\Shared\"
It seems to skip filling that variable, and leaves the path as C:\NIDummy.
The issue appears with both old bi-arch build and new wow64. It works when installing manually by unpacking the ni-error-report cab and installing the msi though
A +relay,+msi log shows some more info: (truncated to start at the first appearance of ni-error-report and having a bunch of function calls excluded)
467959: 06ec:Call msi.MsiRecordSetStringW(00000006,00000000,00480bf0 L"NIPaths II: Defining a 64-bit NIPathsDir "NIDIR64" on a 32-bit OS to a dummy value "TARGETDIR\NIDummy", just to satisfy the Directory table for costing.") ret=78035abe 468252: 06ec:Call msi.MsiRecordSetStringW(00000006,00000000,0047d3e0 L"NIPaths II: Processing NISHAREDDIR (Dir type): All NI Shared components") ret=78035abe 469222: 06ec:Call msi.MsiRecordSetStringW(0000000a,00000000,00481328 L"NIPaths II: Registry key HKLM\Software\National Instruments\Common\Installer\NISHAREDDIR has value "C:\Program Files (x86)\National Instruments\Shared\"") ret=78035abe 471983: 06ec:Call msi.MsiRecordSetStringW(00000006,00000000,0047d3e0 L"NIPaths II: Defining a 64-bit NIPathsDir "NISHAREDDIR64" on a 32-bit OS to a dummy value "TARGETDIR\NIDummy", just to satisfy the Directory table for costing.") ret=78035abe
It gets a row from "NIPathsDefinition":
06ec:Call msi.MsiRecordGetInteger(00000008,00000001) ret=78037563 06ec:Ret msi.MsiRecordGetInteger() retval=00000003 ret=78037563
Looking into the msi table, this 00000003 seems to be related to 64bit, all 64bit variables a saw hat this value. Checking this attribute seems to be the last thing the program does before giving up filling the variable.
It seems to think it is running in a 32bit OS, not sure why. I noticed it has some "remote" msi handling, maybe that is related?
An idea how to continue here?
Just a note: rabbitmq is really finicky, and it doesn't help that it takes so long to get to this point. If you still get that ni-systemlink-message-broker with my branch, just try again and maybe restart first to clean up open resources.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #30 from Fabian Maurer dark.shadow4@web.de --- The program does the following: - Calls custom DLL function "NIPaths" - Calls MsiGetActiveDatabase - It's "remote", so it calls MsiGetActiveDatabase remotely - Passes that handle to MsiGetSummaryInformationW - Calls MsiSummaryInfoGetPropertyW with PID_TEMPLATE (7). - If the returned string doesn't contain the string "x64" it considers itself running on a 32bit OS.
Adding the following hack (on top of the previous) lets the installer finish: https://gitlab.winehq.org/DarkShadow44/wine/-/commit/2c0c3d1f98cca8d211d8cba...
I'm pretty sure this hack is wrong though, I don't see how this would work on windows. It gets the summary information from the msi, and the msi that calls "NIPaths" simply has "Intel;0" and not "x64;9" as string there.
Problem is that there is so many msis involved, and it's hard to pin down with all the remote calls. I don't think I will continue here.
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #31 from Fabian Maurer dark.shadow4@web.de --- Okay, I just couldn't let this one go... Here is the two MRs that should fix the remaining issues:
net: https://gitlab.winehq.org/wine/wine/-/merge_requests/6826 msi: https://gitlab.winehq.org/wine/wine/-/merge_requests/6827
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #32 from Fabian Maurer dark.shadow4@web.de --- I'm happy to announce that I consider this bug finally fixed with https://gitlab.winehq.org/wine/wine/-/commit/30c7900c40c0365cf61db3573bb8556...
Could you retest to make sure it works for you as well?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #33 from Alex Henrie alexhenrie24@gmail.com --- That's amazing work Fabian! Thank you!
I tried it again today with the latest upstream changes and unfortunately the installer still doesn't quite work for me. It gets stuck at "Installing MGI Solution Explorer" "Executing Finalize Install.exe" and spams the following to the console:
0b88:err:sync:RtlpWaitForCriticalSection section 7BD5C2E0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0b88, blocked by 0ba0, retrying (60 sec)
Have you seen that error before in your testing?
https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #34 from Fabian Maurer dark.shadow4@web.de --- Ugh, yeah I had that once while experimenting, I hoped this was just a fluke due to a broken build since I couldn't reproduce it later... Thanks for reporting back, I'll take a look when I have time - could be a while though, since I'm gotten busy with work again.
-
WineHQ Bugzilla