https://bugs.winehq.org/show_bug.cgi?id=45845
Bug ID: 45845 Summary: Microsoft Office 2010: installer crashes at the beginning of the installation process Product: Wine Version: 3.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs@winehq.org Reporter: yaroslav.cpp@gmail.com Distribution: ---
Created attachment 62317 --> https://bugs.winehq.org/attachment.cgi?id=62317 Backtrace and CLI-output that were received during installation process
Debian 9.5 Stable (64 bit) Wine-Development v3.16 Clean Windows 7 prefix (32 bit)
Starting with version 3.15, the MS-Office 2010 crashes during installation (at the beginning, but not immediately after starting). On Windows XP prefix the same situation.
https://bugs.winehq.org/show_bug.cgi?id=45845
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45208 Ever confirmed|0 |1 Regression SHA1| |baea371c3d4153bc4a718c07f46 | |971d4d39aa9f3 Status|UNCONFIRMED |NEW CC| |z.figura12@gmail.com
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- Confirming the early crash, though I suspect this is going to be resolved as a duplicate of bug 45208.
The regression test showed:
baea371c3d4153bc4a718c07f46971d4d39aa9f3 is the first bad commit commit baea371c3d4153bc4a718c07f46971d4d39aa9f3 Author: Zebediah Figura z.figura12@gmail.com Date: Fri Sep 7 20:17:22 2018 -0500
msi: Add exception handling around all custom action RPC calls.
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
:040000 040000 aac7b8f9a1511d39e31a9f6bfdacefb458d04a15 8100fd9e2780398bc325c94d2ca992ec77779570 M dlls
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
https://bugs.winehq.org/show_bug.cgi?id=45845
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.goosev@gmail.com
--- Comment #3 from Dmitry Timoshkov dmitry@baikal.ru --- *** Bug 45850 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #2)
One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
MsiSetMode() is even more broken regarding the returned value.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #2)
One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
Eh, well, that's not always a guarantee. For example, COM proxies always return an HRESULT-style error code even if the function doesn't return an HRESULT.
I'd be very curious to see how either of those functions are throwing an exception, however.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #4)
One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
MsiSetMode() is even more broken regarding the returned value.
Add to the list MsiGetLanguage(), MsiProcessMessage(),
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #5)
One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
Eh, well, that's not always a guarantee. For example, COM proxies always return an HRESULT-style error code even if the function doesn't return an HRESULT.
I'd be very curious to see how either of those functions are throwing an exception, however.
My point is that your patch has changed the return value of many MSI APIs, and that *might* be the source of the regression.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #7)
My point is that your patch has changed the return value of many MSI APIs, and that *might* be the source of the regression.
As far as I'm aware rpcrt4 makes it clear if a proxy call fails. Since I don't see that in the log, and since I can't really envision a situation where any of the relevant functions crash, I'm inclined to think that's a red herring.
Anyway, I'll take a look at .NET 4.0.
https://bugs.winehq.org/show_bug.cgi?id=45845
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #9 from Dmitry Timoshkov dmitry@baikal.ru --- I just sent a patch that should fix the regression.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #10 from Dmitry Timoshkov dmitry@baikal.ru --- https://source.winehq.org/patches/data/151322
https://bugs.winehq.org/show_bug.cgi?id=45845
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=45845
alasky@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasky@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #11 from Rosanne DiMesio dimesio@earthlink.net --- The patch fixes this bug and bug 45850.
https://bugs.winehq.org/show_bug.cgi?id=45845
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |09e4240f33425eda3ea05eb2a98 | |adaec184b7ba4 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #12 from Rosanne DiMesio dimesio@earthlink.net --- The patch was committed; marking fixed.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #6)
One of the problems with baea371c3d4153bc4a718c07f46971d4d39aa9f3 is that it makes MSI APIs return wrong value on exception. Let's look for instance at MsiEvaluateConditionW implementation: it's supposed to return MSICONDITION, however in the case of an exception it returns the exception code instead of MSICONDITION_NONE.
MsiSetMode() is even more broken regarding the returned value.
Add to the list MsiGetLanguage(), MsiProcessMessage().
While this particular regression was not caused by returning wrong value due an exception, it's still worth IMO to add the tests to the listed above APIs to check their behaviour.
Zebediah, since that's your patch are you planning to investigate this?
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #13)
While this particular regression was not caused by returning wrong value due an exception, it's still worth IMO to add the tests to the listed above APIs to check their behaviour.
Zebediah, since that's your patch are you planning to investigate this?
I'm not sure how to force any of those APIs to cause a page fault on Windows. Do you have any ideas?
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zebediah Figura from comment #14)
While this particular regression was not caused by returning wrong value due an exception, it's still worth IMO to add the tests to the listed above APIs to check their behaviour.
Zebediah, since that's your patch are you planning to investigate this?
I'm not sure how to force any of those APIs to cause a page fault on Windows. Do you have any ideas?
Setting a break point on an rpcrt4 API that MSI uses for calling to the remote side seems a workable solution. A starting point would be to figure out first which one to exploit for this purpose.
https://bugs.winehq.org/show_bug.cgi?id=45845
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 62361 --> https://bugs.winehq.org/attachment.cgi?id=62361 hack
I played with the attached patch. Unfortunately it looks like any exception in the thunk leads to the installation termination. Perhaps I'm missing something, fill free to join the club.
https://bugs.winehq.org/show_bug.cgi?id=45845
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #17 from Anastasius Focht focht@gmx.net --- *** Bug 45835 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45845
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.17.
https://bugs.winehq.org/show_bug.cgi?id=45845
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression