[Bug 55859] New: LabView 2023.3.1 fails to install
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(a)winehq.org Reporter: alexhenrie24(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Alex Henrie <alexhenrie24(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #1 from Alex Henrie <alexhenrie24(a)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'. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #2 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #3 from Fabian Maurer <dark.shadow4(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #4 from Fabian Maurer <dark.shadow4(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #5 from Alex Henrie <alexhenrie24(a)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! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #6 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #7 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #8 from Fabian Maurer <dark.shadow4(a)web.de> --- Oh, you're right - it seems to be DIFxAppA. Not sure if that is off limits though. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #9 from Alex Henrie <alexhenrie24(a)gmail.com> --- difxappa.dll is closed-source and copyright Microsoft. Definitely off limits. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #10 from Fabian Maurer <dark.shadow4(a)web.de> --- Thought so. But then how do we get the proper function prototype? Never really had to deal with such an issue before. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #11 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #12 from Alex Henrie <alexhenrie24(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #13 from Alex Henrie <alexhenrie24(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #14 from Alex Henrie <alexhenrie24(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #15 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #16 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #17 from Alex Henrie <alexhenrie24(a)gmail.com> --- cmd patch sent, feedback welcome: https://gitlab.winehq.org/wine/wine/-/merge_requests/4418 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #18 from Fabian Maurer <dark.shadow4(a)web.de> --- Still waiting on https://gitlab.winehq.org/wine/wine/-/merge_requests/4343, any idea what I should do? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Alex Henrie <alexhenrie24(a)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(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Alex Henrie <alexhenrie24(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #20 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #21 from Alex Henrie <alexhenrie24(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #22 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #23 from Zeb Figura <z.figura12(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #24 from Alex Henrie <alexhenrie24(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #25 from Zeb Figura <z.figura12(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #26 from Alex Henrie <alexhenrie24(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #27 from Fabian Maurer <dark.shadow4(a)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(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |57365 --- Comment #28 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #29 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #30 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #31 from Fabian Maurer <dark.shadow4(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #32 from Fabian Maurer <dark.shadow4(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #33 from Alex Henrie <alexhenrie24(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55859 --- Comment #34 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla