https://bugs.winehq.org/show_bug.cgi?id=45208
Bug ID: 45208 Summary: Microsoft Office 2010 installer crashes at around 50 % mark Product: Wine Version: 3.8 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msi Assignee: wine-bugs@winehq.org Reporter: bunglehead@gmail.com Distribution: ---
The crash happens in custom action process I think, installer does not recover from that. I'm using 32bit prefix, default Win7 version, and Home & Business product edition.
This looks like a regression, I'm going to try to find what broke it.
https://bugs.winehq.org/show_bug.cgi?id=45208
alasky@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasky@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=45208
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Bisecting gave me this:
commit c6bd4d8c35de1ae452a5b5bec69d4779c813b37f (refs/bisect/bad) Author: Zebediah Figura z.figura12@gmail.com Date: Wed Apr 18 18:40:04 2018 -0500
msi: Make MsiDatabaseOpenView() RPC-compatible.
Signed-off-by: Zebediah Figura z.figura12@gmail.com Signed-off-by: Hans Leidekker hans@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
I don't know how accurate it is. Will attach logs soon.
https://bugs.winehq.org/show_bug.cgi?id=45208
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- I'm not sure, but I suspect that this is the problem:
https://bugs.winehq.org/show_bug.cgi?id=10365#c23
It only crashes intermittently for me, and I haven't yet managed to reproduce the crash with debug traces—but if I just trace the custom actions executed, I get this:
003e:fixme:msi:ACTION_CustomAction Handling custom action L"ArpWrite" (1 L"OCFXCA" L"OcaArpWrite") 01ca:fixme:msi:MsiGetLastErrorRecord 01ca:fixme:msi:MsiGetLastErrorRecord wine: Unhandled exception 0xe06d7363 in thread 1ca at address 0x560023:0x7b43ce2c (thread 01ca), starting debugger...
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #2)
I'm not sure, but I suspect that this is the problem:
I'm not convinced about this anymore. I tried running a custom action in series which just called GetTickCount(), and on Wine got something like 140 ms between invocations, but on my Windows 7 VM it was much faster (sometimes less than the timer's actual granularity, so returning the exact same value). Either something else is slow on Windows, or the race condition is elsewhere.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- Things I have tried:
* Testing whether two consecutive actions from the same DLL don't pin it. * Testing whether temporary record fields are held over from a previous custom action. * Implementing MsiGetLastErrorRecord(). * Testing whether the actions in question are supposed to be run at all—judging from the SetupExe(...).log found in the temp directory, they are, since the relevant parameters are passed to MsiInstallProduct().
Further notes:
* The previous action, which Anastasius didn't mention, is ProcessBranding. It writes something like 5000 entries into the Registry table., with a primary key something like "arp12839018359" where the number is the tick count. I have no idea where it's getting the registry entries. Then ArpWrite tries to grab the current time to seed another primary key, and if less than 5 seconds have passed, MsiViewModify() will fail and the installer will throw a C++ exception. * As this is a race condition, trying to grab a +msi or +relay trace makes the problem go away. I was able to grab a +msi trace of the failures case by hacking GetTickCount() to return 1/256 of the proper value, so this approach might work if anyone wants to get traces.
Giving up for now, this is too hard.
https://bugs.winehq.org/show_bug.cgi?id=45208
張修銘 cges30901@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cges30901@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #5 from Hans Leidekker hans@meelstraat.net --- (In reply to Zebediah Figura from comment #4)
- The previous action, which Anastasius didn't mention, is ProcessBranding.
It writes something like 5000 entries into the Registry table., with a primary key something like "arp12839018359" where the number is the tick count. I have no idea where it's getting the registry entries. Then ArpWrite tries to grab the current time to seed another primary key, and if less than 5 seconds have passed, MsiViewModify() will fail and the installer will throw a C++ exception.
The 5000 entries contain many duplicates. It's adding the same ProductCode value many times under each brand key. Both under HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\Registration and HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\User Settings.
There are 53 different brands and it adds 43 identical ProductCode entries for each brand, under both keys: 53 * 43 * 2 = 4558.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- Looking at x86/Office.en-us/branding.xml (which appears to be the source of these registry entries) I noticed that product names are localized. There are 39 different LCIDs in this file, which is close to 43.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to Hans Leidekker from comment #5)
The 5000 entries contain many duplicates. It's adding the same ProductCode value many times under each brand key. Both under HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\Registration and HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\User Settings.
There are 53 different brands and it adds 43 identical ProductCode entries for each brand, under both keys: 53 * 43 * 2 = 4558.
Yep, that part did strike me as suspicious. I think I forgot to mention it specifically. I couldn't figure out where they were coming from, though.
It's fairly likely that we should only be picking out one language from these somehow (although I won't count on it). I'll take another look at it, unless you think you're close to the problem.
https://bugs.winehq.org/show_bug.cgi?id=45208
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luizluca@gmail.com
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- *** Bug 45256 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- I cannot for the life of me figure out what is going wrong here.
I can't find any simple explanation for why there are duplicate ProductCode entries for so many values. But even if I did I'm still kind of suspicious that this is even the problem. Without duplicates we get at least 390 unique entries, and, as I've stated in comment 3, Windows definitely can take less than 390 ms to execute a custom action.
More dead ends: * Both the ProcessBranding and ArpWrite actions are simply of type 1, with no extra flags or deferral. * The custom DLL is inserted in the Binary table (so there can't be any difference between that and using the File table at play here). * Tests already in Wine show that consecutive actions from the same source DLL don't preserve static state, and disassembly shows that the previous tick count is simply saved in a local variable. * Native msxml3 and msxml6 don't help. * Judging from their side effects, both actions are executed on Windows. (Namely, the keys mentioned in comment 5 by ProcessBranding, and the key HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.SingleImage by ArpWrite).
https://bugs.winehq.org/show_bug.cgi?id=45208
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isiraseneviratne@yahoo.com
--- Comment #10 from Hans Leidekker hans@meelstraat.net --- *** Bug 45619 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45208
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45753
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru --- Because of an indirect influence to the bug 45753 I decided to have a look at this regression. After a bit of an investigation I have to say that the whole approach of introducing RPC to custom action handling seems to be broken from the start. For instance let's look at the commit c6bd4d8c35de1ae452a5b5bec69d4779c813b37f which is mentioned as the culprit of the regression. This commit changes MsiDatabaseOpenView() to return a remote MSI handle in some situations. This out of sudden implies that every MSI API that takes a handle of type MSIHANDLETYPE_VIEW will start silently failing when a remote handle is passed to it. These APIs include MsiViewFetch(), MsiViewClose(), MsiViewExecute(), MsiViewGetColumnInfo(), MsiViewModify(), MsiViewGetError(). But this particular commit doesn't even bother to add FIXMEs to these APIs! Not mentioning the tests.
In my opinion first thing to do would be to adapt dependent APIs first to accept remote handles, and only then switch main API to return remote handles.
Now what we have is what we have: multiple regressions in previously perfectly working installers, and hard to identify APIs (missing FIXMEs) that need to be fixed to start accepting remote handles.
The situation becomes even worse taking into account the time it takes to review and accept trivial patches that add missing support for remote handles.
https://bugs.winehq.org/show_bug.cgi?id=45208
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- Thank you for your comments, Dmitry. Yes, you are correct in that I should have arranged my patches better, and I should have been more rigorous in testing what APIs do and don't work from a custom action. I thought I had found that MsiSummaryInfoGetProperty() didn't actually work, and thus neglected to do anything with it, but clearly I did so incorrectly; in any case I will try to add some more explicit tests for APIs that shouldn't work.
Nevertheless I'd ask you to please try not to take such an accusatory tone; we are all working on the same project after all :-)
Anyway, with regards to this bug, Hans Leidekker has found that on Windows the ProcessBranding action in fact takes over 5 seconds to execute. This is apparently because it triggers native MSI to rebuild the string pool. Obviously this is not a behaviour we would want to try to match, so I'm sort of inclined to resolve this WONTFIX, unless anyone has any other opinions.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #13 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Zebediah Figura from comment #12)
Obviously this is not a behaviour we would want to try to match, so I'm sort of inclined to resolve this WONTFIX, unless anyone has any other opinions.
So I guess no one is ever going to be able to install Office 2010 in versions of Wine higher than 3.8. I better put a prominent warning in the AppDB about that.
The crash doesn't happen on Windows and didn't happen before in Wine so I fail to see how this could possibly be a WONTFIX.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- (In reply to Rosanne DiMesio from comment #13)
So I guess no one is ever going to be able to install Office 2010 in versions of Wine higher than 3.8. I better put a prominent warning in the AppDB about that.
I know; I'm sorry, it's not a great situation at all. The problem is just that I don't think there's any correct way to solve this.
The crash doesn't happen on Windows and didn't happen before in Wine so I fail to see how this could possibly be a WONTFIX.
Previously we did something incorrect by keeping custom action DLLs loaded. That broke multiple other installers (bug 10365), so I really don't think it's a behaviour we want to restore.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #15 from Zebediah Figura z.figura12@gmail.com --- For what it's worth, running with heavy tracing (e.g. +relay) should probably slow down the installer enough that it won't fail.
https://bugs.winehq.org/show_bug.cgi?id=45208
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |---
--- Comment #16 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Zebediah Figura from comment #15)
For what it's worth, running with heavy tracing (e.g. +relay) should probably slow down the installer enough that it won't fail.
I tried that when I was dealing with bug 45753, and it didn't work.
(In reply to Zebediah Figura from comment #14)
Previously we did something incorrect by keeping custom action DLLs loaded. That broke multiple other installers (bug 10365), so I really don't think it's a behaviour we want to restore.
I understand that, and don't expect you to. What I object to is closing this bug as WONTFIX. It's a valid bug: the crash doesn't happen on Windows. You, or someone else, may eventually figure out a fix. Or not; the bug may sit open for years. It wouldn't be the first. But IMO, calling it WONTFIX simply because you can't think of a way to fix it at the moment is inappropriate.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #17 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #12)
Thank you for your comments, Dmitry. Yes, you are correct in that I should have arranged my patches better, and I should have been more rigorous in testing what APIs do and don't work from a custom action. I thought I had found that MsiSummaryInfoGetProperty() didn't actually work, and thus neglected to do anything with it, but clearly I did so incorrectly; in any case I will try to add some more explicit tests for APIs that shouldn't work.
Nevertheless I'd ask you to please try not to take such an accusatory tone; we are all working on the same project after all :-)
I'm sorry that it sounded so harsh, basically I was very upset that it's no longer possible to perform any meaningful regression test during the time of the custom actions handling rewrite. That's just a matter of the fact, nothing about accusing :)
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #18 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #12)
I thought I had found that MsiSummaryInfoGetProperty() didn't actually work, and thus neglected to do anything with it, but clearly I did so incorrectly; in any case I will try to add some more explicit tests for APIs that shouldn't work.
It's probably worth to at least add FIXMEs for the remaining cases when msihandle2msiinfo() fails, there are still a few cases in MSI code that don't handle remote handles. Even if not supporting remote handles in those cases is probably correct behavior, until there's a definitive test case it would be helpful.
https://bugs.winehq.org/show_bug.cgi?id=45208
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=45208
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |45845
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #19 from Hans Leidekker hans@meelstraat.net --- (In reply to Rosanne DiMesio from comment #16)
(In reply to Zebediah Figura from comment #15)
For what it's worth, running with heavy tracing (e.g. +relay) should probably slow down the installer enough that it won't fail.
I tried that when I was dealing with bug 45753, and it didn't work.
You could also run the installer like this:
$ MsiBreak=OcaArpWrite wine setup.exe
Let it run until a message box is shown. Start winedbg and enter 'attach <pid>' where <pid> is the process number mentioned in the message. Enter 'c' in the debugger. Press OK on the message box and count to five (just to be sure ;-), then enter 'c' once more in the debugger.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #20 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Hans Leidekker from comment #19)
You could also run the installer like this:
$ MsiBreak=OcaArpWrite wine setup.exe
Let it run until a message box is shown. Start winedbg and enter 'attach <pid>' where <pid> is the process number mentioned in the message. Enter 'c' in the debugger. Press OK on the message box and count to five (just to be sure ;-), then enter 'c' once more in the debugger.
Trying that in 3.16 doesn't get past bug 45845. Trying it in 3.14 doesn't work; no message box appears.
https://bugs.winehq.org/show_bug.cgi?id=45208 Bug 45208 depends on bug 45845, which changed state.
Bug 45845 Summary: Microsoft Office 2010: installer crashes at the beginning of the installation process https://bugs.winehq.org/show_bug.cgi?id=45845
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #12)
Anyway, with regards to this bug, Hans Leidekker has found that on Windows the ProcessBranding action in fact takes over 5 seconds to execute. This is apparently because it triggers native MSI to rebuild the string pool. Obviously this is not a behaviour we would want to try to match, so I'm sort of inclined to resolve this WONTFIX, unless anyone has any other opinions.
Do you know why this problem didn't happen before your custom action handling rewrite? Is there a way to go backwards in behaviour with current code base?
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #22 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #21)
Do you know why this problem didn't happen before your custom action handling rewrite? Is there a way to go backwards in behaviour with current code base?
Previously we did something incorrect by keeping custom action DLLs loaded. That broke multiple other installers (bug 10365), so I really don't think it's a behaviour we want to restore.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #23 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #22)
Do you know why this problem didn't happen before your custom action handling rewrite? Is there a way to go backwards in behaviour with current code base?
Previously we did something incorrect by keeping custom action DLLs loaded. That broke multiple other installers (bug 10365), so I really don't think it's a behaviour we want to restore.
I was asking about the delay during the OcaArpWrite action execution.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #24 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #23)
I was asking about the delay during the OcaArpWrite action execution.
There was no delay during OcaArpWrite. It's simply that this wasn't a problem, because the aforementioned global variable was never reset, and so OcaArpWrite wouldn't calculate the tick count again. But failing to reset DLL instance data is exactly what causes bug 10365.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #25 from Zebediah Figura z.figura12@gmail.com --- I've been really trying to think of something to do with this, and coming up essentially empty.
Trying to emulate Windows behaviour here means not only adjusting the string table heuristics such that the string table is rebuilt during this custom action and this one alone—a difficult task if it's even possible—but also introducing an artificial slowdown to guarantee that our rebuilding process takes at least 5 seconds.
The installer runs a custom action which checks a global variable, calls GetTickCount() if it's unset, then repeatedly calls MsiViewModify(MSIMODIFY_INSERT_TEMPORARY), raising an exception when this fails due to primary key collision. Trying to introduce a hack to interrupt this sequence means, as far as I can tell:
* keeping old DLLs loaded in the custom action server. But this would reintroduce bug 10365. Maybe none of those applications are as widely used as Office 2010, but there are several of them, and I'd really like to not do this as it means trading one unsolvable problem for another.
* introducing slowdown somewhere in the normal sequence of operations. This would affect a huge amount of installers. The slowdown needs to be 5 whole seconds, which is patently absurd.
* adjusting MSIMODIFY_INSERT_TEMPORARY to not fail when collisions happen. This seems very dangerous, and liable to break other installers (if not this one). Besides which we'd be dropping entries in the table (and while many of them are duplicates, not all of them are).
The best thing I can think of to do is an application-specific hack. Despite that these have always been forbidden (except, for whatever reason, that one in winevulkan), I really can't see any better option. At any rate it's not a workaround for an undiagnosed problem; the problem is understood and all but unsolvable.
Otherwise I don't think there's anything to do but leave at least one bug in our tracker closed as WONTFIX.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #26 from Andrew andrewbb43@gmail.com --- (In reply to Zebediah Figura from comment #25)
I've been really trying to think of something to do with this, and coming up essentially empty.
Trying to emulate Windows behaviour here means not only adjusting the string table heuristics such that the string table is rebuilt during this custom action and this one alone—a difficult task if it's even possible—but also introducing an artificial slowdown to guarantee that our rebuilding process takes at least 5 seconds.
The installer runs a custom action which checks a global variable, calls GetTickCount() if it's unset, then repeatedly calls MsiViewModify(MSIMODIFY_INSERT_TEMPORARY), raising an exception when this fails due to primary key collision. Trying to introduce a hack to interrupt this sequence means, as far as I can tell:
- keeping old DLLs loaded in the custom action server. But this would
reintroduce bug 10365. Maybe none of those applications are as widely used as Office 2010, but there are several of them, and I'd really like to not do this as it means trading one unsolvable problem for another.
- introducing slowdown somewhere in the normal sequence of operations. This
would affect a huge amount of installers. The slowdown needs to be 5 whole seconds, which is patently absurd.
- adjusting MSIMODIFY_INSERT_TEMPORARY to not fail when collisions happen.
This seems very dangerous, and liable to break other installers (if not this one). Besides which we'd be dropping entries in the table (and while many of them are duplicates, not all of them are).
The best thing I can think of to do is an application-specific hack. Despite that these have always been forbidden (except, for whatever reason, that one in winevulkan), I really can't see any better option. At any rate it's not a workaround for an undiagnosed problem; the problem is understood and all but unsolvable.
Otherwise I don't think there's anything to do but leave at least one bug in our tracker closed as WONTFIX.
On the contrary, I happened upon a Office 2010 copy and decided to install it through Wine on a 32-bit prefix myself. This Wine prefix was completely stock, and the installer worked perfectly for me at least on Wine 4.21. I would recommend that the status of this bug is RESOLVED to anyone interested.
https://bugs.winehq.org/show_bug.cgi?id=45208
Andreas Christ andreas.christ@runbox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas.christ@runbox.com
--- Comment #27 from Andreas Christ andreas.christ@runbox.com --- (In reply to Andrew from comment #26)
On the contrary, I happened upon a Office 2010 copy and decided to install it through Wine on a 32-bit prefix myself. This Wine prefix was completely stock, and the installer worked perfectly for me at least on Wine 4.21. I would recommend that the status of this bug is RESOLVED to anyone interested.
I can confirm this. After several failed attempts to install Office 2010 during the last years on other machines with some versions of Wine 4, I managed to install and run it without any issues on a fresh installation of Debian Buster (5.8.0-0.bpo.2-amd64 #1 SMP Debian 5.8.10-1~bpo10+1 (2020-09-26) x86_64 GNU/Linux) with Wine 5.0.3 from the winehq repositories following the usual instructions in the AppDB.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #28 from Zebediah Figura z.figura12@gmail.com --- I suspect it might work by chance, but it's not going to be reliable; the fundamental problem is still there.
Unless there's some other, unrelated cause for this bug, which would be surprising, but not impossible.
https://bugs.winehq.org/show_bug.cgi?id=45208
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kle@bluewin.ch
--- Comment #29 from C. Leu kle@bluewin.ch --- A new little update to this interesting topic. I can confirm this bug. It is 100% reproducible on more recent multi-core based systems running Kubuntu 20.04 LTS and Wine 6.0.1 stable.
Despite many many attempts I was NOT able to install Office 2010 Home and Student (incl. SP1) at a new AMD Ryzen 7 5700U based PC. I really have tried EVERYTHING but it didn't work, the installer always crashed at the 50% mark.
I decided then to try it at an old single-core AMD Athlon II Neo K145 based Netbook. And to my big surprise the installation worked perfectly well right from the first time. I deleted the prefix and started the installation a second time. It worked again absolutely error free! I repeated this a third and fourth time, - always without any issue.
So I am now really baffled, the installation of Office 2010 works 100% reliable at a single-core Netbook while it fails 100% at a modern 8-Core Ryzen based PC. Something really strange is going on here... ;-)
Finally, I copied the "preinstalled" Wine prefix over from the Netbook to the Ryzen PC. The installation of the MS Office 2010 Service Pack 2 went flawlessly, this also reinstalled the missing Start Menu entries. All Office 2010 Home and Student applications are running great. I have used the following winetricks parameters:
Before the installation: winetricks -q mfc100 winetricks -q msxml6
After the installation: winetricks -q riched20
Optional, maybe only sometimes needed (not used at the "Ryzen" Wine prefix): winetricks -q gdiplus
I also applied the "Office 2013 black window" registry tweak (before the installation): Add a new "Direct3D" key in "HKCU\Software\Wine" with dword "MaxVersionGL" and value "30002" (hexa).
It would be nice if someone can explain here how I can limit in Wine the number of CPU cores to one single? Maybe this would allow the installation of Office 2010 also on modern multi-core based systems.
https://appdb.winehq.org/objectManager.php?sClass=version&iId=17336&...
https://bugs.winehq.org/show_bug.cgi?id=45208
Michael McGuire spoon0042@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spoon0042@hotmail.com
--- Comment #30 from Michael McGuire spoon0042@hotmail.com --- If that's truly the issue you'd want like 'taskset -c 0 wine whatever.exe'
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #31 from C. Leu kle@bluewin.ch --- Thanks Michael McGuire for the example.
This looks really simple, - somehow too simple. ;-) It limits under Linux the CPU core usage of an application to one single core.
Will give this definitely a try... But I don't know when I find the time.
https://bugs.winehq.org/show_bug.cgi?id=45208
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #32 from Andreas Christ andreas.christ@runbox.com --- No, just tried and got the same crash at about 50% with taskset -c 0 and without. Wine is Version 6.0.2 from the winehq repositories installed on 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #33 from C. Leu kle@bluewin.ch --- What a shame, it would have been really nice if that had helped. Whatever, maybe the used CPU is still too fast, - even with only one core active...
The mentioned single-core AMD Athlon II Neo K145 CPU is really a slow one. It can be said that it is by today's standards a super-slow processor. This is also noticeable during the installation of Office 2010. Everything is more "leisurely". And if I read the comment 25 of Zebediah Figura then this is the key point in the whole matter here. The installer runs mostly too fast and crashes therefore at the 50% mark.
@Andreas Christ, maybe you must look for an even slower system and set up a Wine 6.0.2 prefix including Office 2010 on that machine. When done, just copy the whole prefix over to the new PC. In my case this worked perfectly well.
https://bugs.winehq.org/show_bug.cgi?id=45208
Serge V Shistarev madlynxed@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madlynxed@gmail.com
--- Comment #34 from Serge V Shistarev madlynxed@gmail.com --- I find out two simple workarounds to install Office.
Slow: Use cpulimit command to limit cpu cycles for setup.exe process (smth like cpulimit -l 10 -p <setup.exe_pid>
-OR-
More sophisticated, but much faster: while setup is installing office disable all cpu cores, except cpu0, run empty cycle with nice level -20 (highest priority), wait until setup finished (or last step, when setup says that it sets up updates), roll everything back.
Script:
cpus() { for i in $(seq $(cat /sys/devices/system/cpu/present | tr "-" " ")); do \ [ $i = 0 ] && continue; echo $1 | tee /sys/devices/system/cpu/cpu$i/online; \ done; }; cpus 0; echo "Press any key to stop CPU stress"; tty=$(stty --save); \ stty -icanon -icrnl time 0 min 0; nice -n -20 sh -c \ 'while [ -z "$(cat -v)" ]; do :; done'; stty $tty; cpus 1
Tested on Ryzen 3700X, Core i7-7700HQ
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #35 from C. Leu kle@bluewin.ch --- @Serge V Shistarev
This is really good news, thanks for these helpful workarounds! Maybe that shows an alternative approach for a solution in this topic here.
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #36 from Andreas Christ andreas.christ@runbox.com --- Just managed to install office as suggested by Serge using the following command (after preparing the prefix as explained in the AppDb):
WINEPREFIX=/home/christ/.local/share/wineprefixes/MS_Office_2010 WINEARCH=win32 wine /media/christ/OFFICE14/setup.exe & sleep 3 && cpulimit -l 10 -p $(pgrep -i setup.exe)
I took the command from here:
https://appdb.winehq.org/objectManager.php?sClass=version&iId=34941
So the problem may also affect the Office 2016 installer.
(In reply to Serge V Shistarev from comment #34)
I find out two simple workarounds to install Office.
Slow: Use cpulimit command to limit cpu cycles for setup.exe process (smth like cpulimit -l 10 -p <setup.exe_pid>
-OR-
More sophisticated, but much faster: while setup is installing office disable all cpu cores, except cpu0, run empty cycle with nice level -20 (highest priority), wait until setup finished (or last step, when setup says that it sets up updates), roll everything back.
Script:
cpus() { for i in $(seq $(cat /sys/devices/system/cpu/present | tr "-" " ")); do \ [ $i = 0 ] && continue; echo $1 | tee /sys/devices/system/cpu/cpu$i/online; \ done; }; cpus 0; echo "Press any key to stop CPU stress"; tty=$(stty --save); \ stty -icanon -icrnl time 0 min 0; nice -n -20 sh -c \ 'while [ -z "$(cat -v)" ]; do :; done'; stty $tty; cpus 1
Tested on Ryzen 3700X, Core i7-7700HQ
https://bugs.winehq.org/show_bug.cgi?id=45208
wi1itw atl4ntdev@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |atl4ntdev@yandex.ru
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #37 from wi1itw atl4ntdev@yandex.ru --- (In reply to Serge V Shistarev from comment #34)
I find out two simple workarounds to install Office.
Slow: Use cpulimit command to limit cpu cycles for setup.exe process (smth like cpulimit -l 10 -p <setup.exe_pid>
-OR-
More sophisticated, but much faster: while setup is installing office disable all cpu cores, except cpu0, run empty cycle with nice level -20 (highest priority), wait until setup finished (or last step, when setup says that it sets up updates), roll everything back.
Script:
cpus() { for i in $(seq $(cat /sys/devices/system/cpu/present | tr "-" " ")); do \ [ $i = 0 ] && continue; echo $1 | tee /sys/devices/system/cpu/cpu$i/online; \ done; }; cpus 0; echo "Press any key to stop CPU stress"; tty=$(stty --save); \ stty -icanon -icrnl time 0 min 0; nice -n -20 sh -c \ 'while [ -z "$(cat -v)" ]; do :; done'; stty $tty; cpus 1
Tested on Ryzen 3700X, Core i7-7700HQ
Thank you very much for this script. It only helped me. But wtf? did anyone find out how this fucking bug?
https://bugs.winehq.org/show_bug.cgi?id=45208
fivehe9345@bitofee.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fivehe9345@bitofee.com
--- Comment #38 from fivehe9345@bitofee.com --- Created attachment 76025 --> https://bugs.winehq.org/attachment.cgi?id=76025 run the installser by typing sudo wine Office_HB_2010_English_x32.exe instasler loads and enter key and then crashes around 50%
https://bugs.winehq.org/show_bug.cgi?id=45208
darkblaze69 bigfoothart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bigfoothart@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #39 from darkblaze69 bigfoothart@gmail.com --- Thanks for the hint! I wish I could find this bug earlier to save myself countless hours to try to install Office 2010/2013. This should be presented on appdb.
That bugged me out that on one hardware I could install it but failed on the other ones, I compared packages to find out what the difference, and no luck. By finding this bug description I found out that indeed on old HW it worked well but on faster CPUs it failed.
Finally I was able to install Office 2013 on a modern 22-cores laptop. To make sure it will behave slow enough I tried as suggested with taskset to limit to 1-core. But that was not enough, also ran with:
nice -n19 wine setup.exe
and to really slow it down:
stress-ng -c <number_of_cpus>
And all installed!
So there's still no acceptable solution?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla