Wine 1.1.20 crashes while installing Photoshop CS4

Bug #357456 reported by David Steltz
2
Affects Status Importance Assigned to Milestone
Wine
Fix Released
High
wine (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Tried to execute Setup.exe for Adobe Photoshop CS4, and I got this output:

fixme:console:AttachConsole stub ffffffff
fixme:advapi:SetNamedSecurityInfoW L"MACHINE\\Software\\Classes\\.svg" 4 4 (nil) (nil) 0x1305a8 (nil)
fixme:advapi:SetNamedSecurityInfoW L"MACHINE\\Software\\Classes\\.svgz" 4 4 (nil) (nil) 0x1305a8 (nil)
wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:00000000 ESP:0032f8e0 EBP:0032fb0c EFLAGS:00210206( - 00 - RIP1)
 EAX:00000000 EBX:00000000 ECX:0032f908 EDX:00000079
 ESI:00000006 EDI:00000000
Stack dump:
0x0032f8e0: 00434e15 00000006 00000000 00000000
0x0032f8f0: 00000000 0032f908 6f921c8c 00698338
0x0032f900: 0032fd58 00000000 00000030 00000000
0x0032f910: 00000007 001304d8 00110014 00130518
0x0032f920: 7bc93ff4 001304c8 00000000 0000011c
0x0032f930: 00000006 00000000 00001770 00000002
Backtrace:
=>0 0x00000000 (0x0032fb0c)
  1 0x0045c064 in setup (+0x5c064) (0x0032fb50)
  2 0x0042b114 in setup (+0x2b114) (0x0032fbc8)
  3 0x536e6957 (0x02020002)
  4 0x00000000 (0x00000000)
0x00000000: addb %al,0x0(%eax)
Modules:
Module Address Debug info Name (90 modules)
PE 400000- 6fc000 Export setup
ELF 7b800000-7b93e000 Deferred kernel32<elf>
  \-PE 7b820000-7b93e000 \ kernel32
ELF 7bc00000-7bcb0000 Deferred ntdll<elf>
  \-PE 7bc10000-7bcb0000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7df1e000-7df22000 Deferred libgpg-error.so.0
ELF 7df22000-7df8b000 Deferred libgcrypt.so.11
ELF 7df8b000-7df9d000 Deferred libtasn1.so.3
ELF 7df9d000-7dfa1000 Deferred libkeyutils.so.1
ELF 7dfa1000-7dfaa000 Deferred libkrb5support.so.0
ELF 7dfaa000-7dfdc000 Deferred libcrypt.so.1
ELF 7dfdc000-7e079000 Deferred libgnutls.so.26
ELF 7e079000-7e09d000 Deferred libk5crypto.so.3
ELF 7e09d000-7e12f000 Deferred libkrb5.so.3
ELF 7e12f000-7e159000 Deferred libgssapi_krb5.so.2
ELF 7e159000-7e18f000 Deferred libcups.so.2
ELF 7e1ea000-7e21d000 Deferred uxtheme<elf>
  \-PE 7e1f0000-7e21d000 \ uxtheme
ELF 7e21d000-7e226000 Deferred libxcursor.so.1
ELF 7e226000-7e22b000 Deferred libxfixes.so.3
ELF 7e22b000-7e22f000 Deferred libxcomposite.so.1
ELF 7e22f000-7e236000 Deferred libxrandr.so.2
ELF 7e236000-7e240000 Deferred libxrender.so.1
ELF 7e240000-7e246000 Deferred libxxf86vm.so.1
ELF 7e246000-7e249000 Deferred libxinerama.so.1
ELF 7e249000-7e26a000 Deferred imm32<elf>
  \-PE 7e250000-7e26a000 \ imm32
ELF 7e26a000-7e26f000 Deferred libxdmcp.so.6
ELF 7e26f000-7e288000 Deferred libxcb.so.1
ELF 7e288000-7e28b000 Deferred libxcb-xlib.so.0
ELF 7e28b000-7e28e000 Deferred libxau.so.6
ELF 7e28e000-7e37d000 Deferred libx11.so.6
ELF 7e37d000-7e38c000 Deferred libxext.so.6
ELF 7e38c000-7e3a4000 Deferred libice.so.6
ELF 7e3a4000-7e3ad000 Deferred libsm.so.6
ELF 7e3b8000-7e3bc000 Deferred libcom_err.so.2
ELF 7e3bc000-7e458000 Deferred winex11<elf>
  \-PE 7e3d0000-7e458000 \ winex11
ELF 7e477000-7e49e000 Deferred libexpat.so.1
ELF 7e49e000-7e4cb000 Deferred libfontconfig.so.1
ELF 7e4da000-7e4f0000 Deferred libz.so.1
ELF 7e4f0000-7e566000 Deferred libfreetype.so.6
ELF 7e566000-7e57c000 Deferred psapi<elf>
  \-PE 7e570000-7e57c000 \ psapi
ELF 7e57c000-7e590000 Deferred lz32<elf>
  \-PE 7e580000-7e590000 \ lz32
ELF 7e590000-7e5ab000 Deferred version<elf>
  \-PE 7e5a0000-7e5ab000 \ version
ELF 7e5ab000-7e692000 Deferred oleaut32<elf>
  \-PE 7e5c0000-7e692000 \ oleaut32
ELF 7e692000-7e6fe000 Deferred rpcrt4<elf>
  \-PE 7e6a0000-7e6fe000 \ rpcrt4
ELF 7e6fe000-7e7f6000 Deferred ole32<elf>
  \-PE 7e720000-7e7f6000 \ ole32
ELF 7e7f6000-7e81f000 Deferred oledlg<elf>
  \-PE 7e800000-7e81f000 \ oledlg
ELF 7e81f000-7e855000 Deferred winspool<elf>
  \-PE 7e830000-7e855000 \ winspool
ELF 7e855000-7e91d000 Deferred comctl32<elf>
  \-PE 7e860000-7e91d000 \ comctl32
ELF 7e91d000-7eaaa000 Deferred shell32<elf>
  \-PE 7e930000-7eaaa000 \ shell32
ELF 7eaaa000-7eb5b000 Deferred comdlg32<elf>
  \-PE 7eab0000-7eb5b000 \ comdlg32
ELF 7eb5b000-7eb6f000 Deferred libresolv.so.2
ELF 7eb7e000-7eb9d000 Deferred iphlpapi<elf>
  \-PE 7eb80000-7eb9d000 \ iphlpapi
ELF 7eb9d000-7ebca000 Deferred ws2_32<elf>
  \-PE 7ebb0000-7ebca000 \ ws2_32
ELF 7ebca000-7ebe5000 Deferred wsock32<elf>
  \-PE 7ebd0000-7ebe5000 \ wsock32
ELF 7ebe5000-7ec3b000 Deferred advapi32<elf>
  \-PE 7ebf0000-7ec3b000 \ advapi32
ELF 7ec3b000-7ecdc000 Deferred gdi32<elf>
  \-PE 7ec50000-7ecdc000 \ gdi32
ELF 7ecdc000-7ee28000 Deferred user32<elf>
  \-PE 7ed00000-7ee28000 \ user32
ELF 7ee28000-7ee86000 Deferred shlwapi<elf>
  \-PE 7ee40000-7ee86000 \ shlwapi
ELF 7efa6000-7efb2000 Deferred libnss_files.so.2
ELF 7efb2000-7efcb000 Deferred libnsl.so.1
ELF 7efcb000-7eff1000 Deferred libm.so.6
ELF 7eff5000-7f000000 Deferred libnss_nis.so.2
ELF b7d55000-b7d5e000 Deferred libnss_compat.so.2
ELF b7d5f000-b7d63000 Deferred libdl.so.2
ELF b7d63000-b7ec1000 Deferred libc.so.6
ELF b7ec2000-b7edb000 Deferred libpthread.so.0
ELF b7eea000-b8025000 Deferred libwine.so.1
ELF b8027000-b8044000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home\david\Desktop\Photoshop CS4\Adobe CS4\Setup.exe
 00000009 0 <==
0000000c
 00000013 0
 00000012 0
 0000000e 0
 0000000d 0
0000000f
 00000015 0
 00000014 0
 00000011 0
 00000010 0
00000016
 00000017 0
Backtrace:
=>0 0x00000000 (0x0032fb0c)
  1 0x0045c064 in setup (+0x5c064) (0x0032fb50)
  2 0x0042b114 in setup (+0x2b114) (0x0032fbc8)
  3 0x536e6957 (0x02020002)
  4 0x00000000 (0x00000000)

lsb_release -rd says:
Description: Ubuntu 8.10
Release: 8.10

Using version 1.1.18~winehq0~ubuntu~8.10-0ubuntu1

Revision history for this message
In , Jaime Rave (jaimerave) wrote :

This commit make the installer fail when it's starting.

b8965ee7c90a687af4c84ad0ede73b1df901e16c is first bad commit
commit b8965ee7c90a687af4c84ad0ede73b1df901e16c
Author: Hans Leidekker <email address hidden>
Date: Tue Mar 24 10:26:24 2009 +0100

    msi: Don't initialize COM for custom action threads.

:040000 040000 e3395252ab46bf3c623252deb94ceba713c0596a 7e7d74822b91c0a5981893f375a05c22bb144360 M dlls

Revision history for this message
In , Jaime Rave (jaimerave) wrote :

Adding Hans to the bug.

Revision history for this message
In , Austin English (austinenglish) wrote :

Please attach a +msi,+msidb trace.

Revision history for this message
In , Jaime Rave (jaimerave) wrote :

Created an attachment (id=20480)
Console Output

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

I'd like to see a +msi,+relay,+seh trace. Custom actions execute
arbitrary code, so +msi may not reveal enough information.

Revision history for this message
In , Jaime Rave (jaimerave) wrote :

The +msi,+relay,+seh trace was more than 1 MB so I upload it to RapidShare.

The link is: http://rapidshare.com/files/222695971/log.txt.tar.bz2.html

Revision history for this message
In , Focht (focht) wrote :

Hello,

well the custom action thread tries to use MSXML6 COM inproc server and fails because there is no apartment (COM not initialized).
There are basically two problems here.
One part (reuse of existing MTA) is covered by my bug 17902 though CoGetClassObject() is the culprit there.

As for the other part, I found the following blog containing useful information regarding custom actions and COM: http://blogs.msdn.com/astebner/archive/2005/02/07/368917.aspx

--- quote ---
...
This question rang a bell so I dug into some of the emails that have gone across our internal Windows Installer question-n-answer alias and here is the official answer from the Windows Installer team:

"One of the first things that a custom action server does when it is created is to call CoInitializeEx(0, COINIT_MULTITHREADED).

However, the thread on which a DLL custom action is run is different from the main thread (on which COM is initialized) and COM will not be initialized on it. It is up to the custom action to initialize COM to its liking."
--- quote ---

Because the custom action thread which executes "Adobe_ProcessPropertyFile" CA doesn't initialize COM explicitly (not creating apartment), the MTA from the main thread has to be used.

The problem is: there is no custom action server the blog talks about here which does this.
Msi will be called in the context of installer threads which might have or have not initialized COM in various ways.

One solution could be to have Wine's Msi create a dedicated thread serving as "fake" CA server main thread which creates an MTA if not already exist by calling CoInitializeEx(NULL, COINIT_MULTITHREADED).
All custom action threads that don't explicitly initialize COM would be then part of that MTA (which is guaranteed to be an MTA, not relying on installer STA threads).

Regards

Revision history for this message
asuastrophysics (grimsrudjk) wrote : Re: Wine crashes with error "Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000)." while trying to run the CS4 installation.

I can confirm this

Changed in wine (Ubuntu):
status: New → Confirmed
Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

I linked it to upstream bug.

Please see http://appdb.winehq.org/objectManager.php?sClass=version&iId=14318 for instructions on how to install Photoshop CS4. You'll need to install it from Wine 1.1.17, apparently.

Cordially, SD.

summary: - Wine crashes with error "Unhandled exception: page fault on read access
- to 0x00000000 in 32-bit code (0x00000000)." while trying to run the CS4
- installation.
+ Wine 1.1.20 crashes while installing Photoshop CS4
Changed in wine:
status: Unknown → New
Revision history for this message
In , Focht (focht) wrote :

Hello,

although Hans implemented reuse of existing MTA part now (commit bd4975acb0b682bbf2b4934d12f942ea629f5bbb) which fixes my bug 17902 *g* this still might not be enough for Adobe and possibly other installers.

Wine needs to ensure there _is_ an MTA present for CA's
If the app installer only consists of single threaded apartments or the installer didn't initialize COM at all, custom actions will still fail.
An indication might be messages like that:

--- snip ---
err:ole:CoCreateInstance apartment not initialised
...
err:msi:ITERATE_Actions Execution halted, action "foo" returned "bar"
--- snip ---

Maybe you can take up my suggestion about creating an msi (internal) thread solely for the purpose of ensuring MTA present which CA's can reuse.
Don't use the app/installer own threads to initialize the COM MTA, it would backfire when the app later decides to initialize COM with a different model (STA).

Regards

Changed in wine:
status: New → Confirmed
Changed in wine (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
In , Nicklas (nicklas) wrote :

*** Bug 18228 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Nicklas (nicklas) wrote :

*** This bug has been confirmed by popular vote. ***

Changed in wine:
status: Confirmed → Invalid
Revision history for this message
Scott Ritchie (scottritchie) wrote :

Upstream bug was a duplicate -- new upstream bug

Changed in wine:
status: Invalid → Unknown
Changed in wine:
status: Unknown → Confirmed
Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

*** Bug 17070 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Dan Kegel (dank) wrote :

Good analysis, affects many apps, key subsystem -> nominating for 1.s

Revision history for this message
In , Austin English (austinenglish) wrote :

*** Bug 16795 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ekstasis0 (ekstasis0) wrote :

When will this error been fixed?

I have now, not been able to install Photoshop CS4 from wine-1.1.18 to wine-1.1.22 how many versions do you think of coming before it gets fixed?

Revision history for this message
In , Dmitry-codeweavers (dmitry-codeweavers) wrote :

(In reply to comment #13)
> When will this error been fixed?
> I have now, not been able to install Photoshop CS4 from wine-1.1.18 to
> wine-1.1.22 how many versions do you think of coming before it gets fixed?

Feel free to send patches.

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #13)
> When will this error been fixed?

Not repeating the somewhat acidulous "feel free to send patches"-comment of Dmitry, it seems to have been nominated to be done before the next major stable release, which would be 1.2.
Hopefully, a solution will be available in earlier releases.

Thing is that this does not seem to be simply a bug, but also a design issue, which makes it a bit bigger.

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

*** Bug 18938 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

Making title more generic, reported to affect all CS3/CS4 applications.

Revision history for this message
In , Dan Kegel (dank) wrote :

Patch sent, http://www.winehq.org/pipermail/wine-patches/2009-June/074531.html
I just typed it in and only very lightly tested it, but it seems to
work. At the very least it demonstrates that Anastasius was on target as usual.

Revision history for this message
In , cem (cemelmaci-hotmail) wrote :

thank you, this patch worked for me!
my wine version is 1.1.24

Revision history for this message
In , cem (cemelmaci-hotmail) wrote :

sory but for cs3 installer failed with "Critical errors were found in setup. Please see the Setup log file for details.
log file
...
Using cached language set
HTML data complete: personalization
Using cached language set
[ 44] Mon Jun 22 23:10:56 2009 FATAL
Critical errors were found in setup
Please see the Setup log file for details.
[ 44] Mon Jun 22 23:10:58 2009 INFO
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
END - Installer Session
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

and cs4 installer failed with

Error message: Adobe Anchor Service CS4

Error 1603

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

*** Bug 19057 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Richard-cornbread (richard-cornbread) wrote :

So is commit b8965ee7c90a687af4c84ad0ede73b1df901e16c a bad commit? or is it a step in the right direction it just breaks some installers currently?

Revision history for this message
In , Dan Kegel (dank) wrote :

It was probably a correct change that exposed a problem. It's probably a week's worth of work to fix the newly exposed problem correctly. Don't know for sure yet if Alexandre will insist on that, or if he'll accept something like my easy workaround patch (suitable improved).

Revision history for this message
In , Javierbere (javierbere) wrote :

At lest the reason was finally found :]
Looking forward to seeing a fix/workaround soon.

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

> So is commit b8965ee7c90a687af4c84ad0ede73b1df901e16c a bad commit?
> or is it a step in the right direction it just breaks some installers
> currently?

It's a step in the right direction. Before that commit office 2007
service pack 1 and other installers would fail because of custom
actions with conflicting demands for COM initialization.

FWIW, I think an improved version of Dan's patch would be acceptable,
after testing with some more installers. MS installers are good
candidates since they seem to consistently check the result of
CoInitialize().

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #26)
> FWIW, I think an improved version of Dan's patch would be acceptable,
> after testing with some more installers. MS installers are good
> candidates since they seem to consistently check the result of
> CoInitialize().

I'd be happy to run my application test suite on any candidate patches..

Revision history for this message
In , Focht (focht) wrote :

Hello,

you need to put more love into it else nothing will happen and people will suffer for a long time.
Sure, any solution that creates MTA helper thread within app process remains sort of a hack until Wine Msi can roll its own custom action server.

As already said: avoid using DllMain for dedicated threads.
Ideal would be a place where one can control the startup and shutdown of MTA helper thread within same function scope while avoiding/minimizing the need for recreation it due to multiple custom actions.

Have a look at MSI_InstallPackage. All applicable custom actions are run from within that entry.
MTA helper thread creation should be done before any ACTION_ProcessExecSequence().
MTA helper thread shutdown should be done after ACTION_FinishCustomActions() to ensure deferred/pending custom actions have ended.
Use event signalling not only for shutdown but also for startup to prevent possible race condition between threads, ensuring CoInitializeEx() is called from MTA helper thread before any custom action is run.

Regards

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

Created an attachment (id=22139)
msi: Start a dummy thread to initialize an MTA.

Here's an improved version of Dan's patch. Please test.

Revision history for this message
In , Dan Kegel (dank) wrote :

Works for me, thanks.

Revision history for this message
In , Richard-cornbread (richard-cornbread) wrote :

How do we apply this patch? sorry patch newb...

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #31)
> How do we apply this patch? sorry patch newb...

http://wiki.winehq.org/Patching

Revision history for this message
In , Dan Kegel (dank) wrote :

Our FAQ didn't answer that question, so I added it:
http://wiki.winehq.org/FAQ#head-7ed3c3163e2b932ee2030a48f9c5e553dc41817b

Revision history for this message
In , cem (cemelmaci-hotmail) wrote :

i have the msi: Start a dummy thread to initialize an MTA patch tested. This is worked in 64 bit ubunutu jaunty. Thanks

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #29)
> Created an attachment (id=22139) [details]
> msi: Start a dummy thread to initialize an MTA.
>
> Here's an improved version of Dan's patch. Please test.

http://austinenglish.com/logs/appinstall-bug_18070_test/

Works fine for all the programs currently being tested.

Revision history for this message
In , Daniel-wallace (daniel-wallace) wrote :

On my gentoo x86_64 system, patching 1.1.25 with Hans' patch allows me to get farther in the Photoshop CS3 installer. I then run into bug 15590 but if I use Hans' workaround of bringing down all interfaces, I'm able to install completely. Thanks Hans!

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

I can get up to the license agreement but when I click on Accept it does nothing

I've compiled from git:
wine-1.1.26-82-gda86ab7

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

Created an attachment (id=22518)
Console Output[+trace, wine-1.1.26-82-gda86ab7]

Pressing on accept button does nothing, added output

Revision history for this message
In , cem (cemelmaci-hotmail) wrote :

see Bug 18681. try winetricks ie6.

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

Created an attachment (id=22524)
 Console Output[+trace, wine-1.1.26-82-gda86ab7] Photoshop/Bridge Fail CS4

When installing ie6 with winetricks you can get past the I Agree button, then when it goes to install it says that Photoshop CS4 and Bridge CS4 have failed to install do you wish to continue or cancel?

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #40)

> When installing ie6 with winetricks you can get past the I Agree button, then
> when it goes to install it says that Photoshop CS4 and Bridge CS4 have failed
> to install do you wish to continue or cancel?

Now this might not be the reason for the failure, but I am not sure that bridge is installable yet(even though that would have been great).
Have you tried deselecting bridge during the installation?

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

(In reply to comment #41)
> Now this might not be the reason for the failure, but I am not sure that bridge
> is installable yet(even though that would have been great).
> Have you tried deselecting bridge during the installation?

Not yet, bridge use to install perfect on 1.1.19(I guess things have changed..) i'll clean wine and try again this evening

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #42)

> Not yet, bridge use to install perfect on 1.1.19(I guess things have changed..)
> i'll clean wine and try again this evening

Ok. Anyway, I had to install all these until my installation worked.
sh winetricks msxml6 gdiplus gecko vcrun2005 ie6

Now, I really can't recommend you to use that much winetricks stuff since it
hides problems and some of them might not be needed anymore.
But I suppose you could start with what seems the first issue in the log,
msxml6, see what happens, then gdiplus, then vcrun2005 to try to find the first
working solution.

Actually I am not sure when to use winetricks and when to submit a bug. The projects' actual ambitions are not that clear to me.

Revision history for this message
In , Dan Kegel (dank) wrote :

Almost any use of winetricks is a workaround for a wine bug.
Many of my wine bug reports go like this:
  Program X wouldn't ...; the log shows ...
  winetricks Z works around the failure and lets you continue.

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

(In reply to comment #43)
> (In reply to comment #42)
>
> > Not yet, bridge use to install perfect on 1.1.19(I guess things have changed..)
> > i'll clean wine and try again this evening
>
> Ok. Anyway, I had to install all these until my installation worked.
> sh winetricks msxml6 gdiplus gecko vcrun2005 ie6
>
> Now, I really can't recommend you to use that much winetricks stuff since it
> hides problems and some of them might not be needed anymore.
> But I suppose you could start with what seems the first issue in the log,
> msxml6, see what happens, then gdiplus, then vcrun2005 to try to find the first
> working solution.
>
> Actually I am not sure when to use winetricks and when to submit a bug. The
> projects' actual ambitions are not that clear to me.

I think you are only allowed to use gecko, but now if you don't have the engine installed it will prompt you to download it and install it(no need for winetricks). Currently I only have ie6 installed to get past the "I agree" I'll try to find an incremental solution

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to comment #43)
> Actually I am not sure when to use winetricks and when to submit a bug. The
> projects' actual ambitions are not that clear to me.

Winetricks is used to workaround wine (e.g., msxml3/pdh) or application (not bundling visual basic/c runtimes) bugs. If you use winetricks to workaround a bug, be sure to mention it in the bug report (with a link to the bug you worked around).

IE6 is a bit of special case, since it's also meant to be used instead of ies4linux. IE6 also works around bugs in wine's mshtml/shdocvw implementations. The case here may be a jscript bug (based on some of the comments, though I haven't verified this myself).

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #45,#46,#47)

Yeah, I have seen especially Dan Kegel submitting numerous bugs with regards to the CSn-series. However, I am not nearly as initiated, so when I look at the logs I have problems knowing what to report, because I don't know which tricks are "legal" to make a certain application work in wine.

For example, It would feel kind of pointless to file a ".NET 3.5 is not implemented" bug.

In this case, IE6 seems to be allowed since there is some unspecified problem with gecko. gdiplus as well, if I look at the Dan's "How Bugs Affect Application".

So what does that mean? Should I always try installing IE6 and gdiplus before making a bug report?

My point is, if an application requires that winetricks redistributables(which never will be implemented in wine) are installed, shouldn't that say somewhere?
Like a version-level installation instruction field? Wouldn't that make it much easier to control and lessen the amount of questions?

Just a thought.

Revision history for this message
In , Dan Kegel (dank) wrote :

> if an application requires that winetricks redistributables (which
never will be implemented in wine) are installed, shouldn't that say somewhere?

Yes, in the appdb.

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #48)
> > if an application requires that winetricks redistributables (which
> never will be implemented in wine) are installed, shouldn't that say somewhere?
>
> Yes, in the appdb.

Oops. Missed the "add HOWTO" button. :-)

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

Doesn't work for me with : msxml6 gdiplus gecko vcrun2005 ie6 allfonts

Still getting the same error as earlyer

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #47)
> Yeah, I have seen especially Dan Kegel submitting numerous bugs with regards to

Ehum, that should have been Ken Sharp(not that Dan hasn't been at it), sorry about the mix up.

Revision history for this message
In , Nicklas (nicklas) wrote :

Created an attachment (id=22915)
This is a dump of Adobe photoshop failing to install on 1.1.27.

Test data here:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=14318

Revision history for this message
In , Nicklas (nicklas) wrote :

Created an attachment (id=22916)
This is a dump of Adobe photoshop failing to install on 1.1.27.

Appdb test data:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=14318&iTestingId=43378

Revision history for this message
In , Focht (focht) wrote :

Hello,

there is no need to provide test data.
The problem is well known and a short-term hack-patch exists which was consequently rejected by AJ.

Until someone takes up the task to implement "remote" custom actions (custom action server) you'll have to use the hack-patch.

Unfortunately this whole bug is now messed up with many useless/irritating comments that have nothing to do with the original bug.

Regards

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #54)
> Hello,
>
> there is no need to provide test data.
> The problem is well known and a short-term hack-patch exists which was
> consequently rejected by AJ.
>
I was not aware of this. I was just trying to help out to show how it was on the latest version.

> Until someone takes up the task to implement "remote" custom actions (custom
> action server) you'll have to use the hack-patch.
>
Ok, that's a letdown.

> Unfortunately this whole bug is now messed up with many useless/irritating
> comments that have nothing to do with the original bug.
>
I am sorry if I have irritated you, it was a mistake, I thought the comment on the attachment was going to end up under the attachment details, an not on the bug, I had forgot how that worked. Please feel free to delete all comments you feel are redundant(like this one and the preceeding short discussion).

Revision history for this message
In , Spoon (spoon) wrote :

(In reply to comment #43)
> ...
> Ok. Anyway, I had to install all these until my installation worked.
> sh winetricks msxml6 gdiplus gecko vcrun2005 ie6
>
> Now, I really can't recommend you to use that much winetricks stuff since it
> hides problems and some of them might not be needed anymore.
> But I suppose you could start with what seems the first issue in the log,
> msxml6, see what happens, then gdiplus, then vcrun2005 to try to find the first
> working solution.
> ...

For me the first working solution was only installing gecko and msxml6. Installation succeeded on all components except Adobe VersionCue. (Wine 1.1.27)

Thank you so much!

Revision history for this message
In , Nicklas (nicklas) wrote :

(In reply to comment #56)
> For me the first working solution was only installing gecko and msxml6.
> Installation succeeded on all components except Adobe VersionCue. (Wine 1.1.27)

Let me get this straight, it worked to install PS CS4 without reverting to an older version? And the with only gecko msxml6? In any case, the lessened need for winetricks is really great news. If you could submit a test result, it would be great.

Revision history for this message
In , Dan Kegel (dank) wrote :

And was that on a clean .wine?

Color me skeptical...

Revision history for this message
In , Spoon (spoon) wrote :

(In reply to comment #57)

> ...
> Let me get this straight, it worked to install PS CS4 without reverting to an
> older version? And the with only gecko msxml6? In any case, the lessened need
> for winetricks is really great news. If you could submit a test result, it
> would be great.

It was CS3 and I didn't revert to an older version, but of course I used the patch mentioned above. As for the test results, would a log of the terminal output be sufficient, or do you need any debug traces? In fact I have never submitted any test results... I more or less just stumbled in here, on my never ending journey to get dreamweaver running...

(In reply to comment #58)
> And was that on a clean .wine?
>
> Color me skeptical...

Yes, it was clean.

Revision history for this message
In , Dan Kegel (dank) wrote :

"For me the first working solution was only installing gecko and msxml6."

You forgot to mention the patch. Rather crucial detail :-)

No logs, please, we understand the bug well enough already.

Revision history for this message
In , cem (cemelmaci-hotmail) wrote :

 msi: Start a dummy thread to initialize an MTA patch is worked. when accepting the patch?

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

(In reply to comment #61)
> msi: Start a dummy thread to initialize an MTA patch is worked. when accepting
> the patch?

They aren't. If you read this thread on the bug, the patch is simply that A PATCH(a work-around) a bigger problem, which they have to implement.

Revision history for this message
In , Dan Kegel (dank) wrote :

The Vista SDK installer is throwing errors like

err:ole:CoInitializeEx Attempt to change threading model of this
apartment from multi-threaded to apartment threaded
err:msi:ACTION_CreateShortcuts CoInitialize failed
err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1627

Perhaps it also suffers from this?

Revision history for this message
In , Focht (focht) wrote :

Hello,

--- quote ---
err:ole:CoInitializeEx Attempt to change threading model of this
apartment from multi-threaded to apartment threaded
err:msi:ACTION_CreateShortcuts CoInitialize failed
err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned
1627

Perhaps it also suffers from this?
--- quote ---

No, you shouldn't mix up different issues here. This whole bug thread gets more and more messy. You are talking about bug 19636.

Regards

Revision history for this message
In , Dan Kegel (dank) wrote :

OK, thanks.

Revision history for this message
In , Austin English (austinenglish) wrote :

*** Bug 19910 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Scott Ritchie (scottritchie) wrote :

I'm considering rolling Hans' patch into the distribution package I ship with Ubuntu 9.10 (I'm shipping both Wine 1.0 and a recent Wine beta) -- is there any plausible downside to it?

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

Personally I don't see a problem in including the patch in the "beta" builds, not until someone starts work on the service

Revision history for this message
In , Dan Kegel (dank) wrote :

Make sure it doesn't cause any regressions in appinstall
(have you run austin's script yet?)

Revision history for this message
In , Scott Ritchie (scottritchie) wrote :

I tried applying the workaround patch to Wine 1.1.31 but the demo is still failing with the same error as before.

Can someone else confirm that it no longer works?

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

Patch works fine for me for PS CS4.

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

*** Bug 20723 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Toni Spets (hifi) wrote :

Created an attachment (id=25093)
msi: Start a dummy thread to initialize an MTA (wine-1.1.34)

I rebased the original patch to apply cleanly on 1.1.34.

The installer itself seems to work better than before, all dialogs are drawn correctly and work (compared to 1.1.33 where texts overlap).

During the installation process itself it fails when installing Photoshop CS4. The installer then exits telling that it failed to install Photoshop.

I tested with the tryout package which is linked from the appdb entry.

Revision history for this message
In , Jelle De Loecker (skerit) wrote :

I've tested this patch (#25093) for Adobe Premiere Pro CS3 & CS4.

On CS3 it will get to the setup initialization screen (which is a huge improvement) but it will just hang at that point.

CS4 actually manages to install perfectly.

Revision history for this message
In , Vitaliy-bugzilla (vitaliy-bugzilla) wrote :

Lots of apps affected - major.

Revision history for this message
In , Juan-lang (juan-lang) wrote :

*** Bug 21914 has been marked as a duplicate of this bug. ***

Revision history for this message
In , onny (onny) wrote :

so, why not apply this patch to the next wine-version?

Revision history for this message
In , onny (onny) wrote :

Created an attachment (id=28390)
AfterEffects CS4 setup crashed (wine1.2rc2)

I could select the trial-setup but while showing the "choose language"-dialog on the second page, it crashed.

Revision history for this message
In , onny (onny) wrote :

Created an attachment (id=28391)
PremierePro CS4 setup crashed (wine1.2rc2)

The initialization-window does not disappear and the setup stops working :(

Revision history for this message
In , Slamdunk84 (slamdunk84) wrote :

(In reply to comment #77)
> so, why not apply this patch to the next wine-version?

I hope that will be done and this bug will be fixed for 1.2. This one bug is the only reason I still need to use Windows every now and then.

Revision history for this message
In , Richard (shiningarcanine) wrote :

Are the trials for Adobe CS4 software still available? It seems to me that it would be difficult for most people to work on this without some sort of trial download link.

Revision history for this message
In , Andrej-cremoznik (andrej-cremoznik) wrote :

CS4 trial is still available here: http://adobe-photoshop.en.softonic.com/download-version/adobe-photoshop-CS4

Link points to depositfiles which, unfortunately, might block some countries at certain times.

Please fix this bug.

Revision history for this message
In , onny (onny) wrote :

Bug is still present in Wine 1.3.1

Revision history for this message
In , trusktr (trusktr) wrote :

Hey, for what version of Wine is Hans' patch intended for? Because I tried patching my 1.3.1 but it didn't work, hehe.

Can someone make a patch for 1.3.1 ?? :D :D :D

Revision history for this message
In , Dan Kegel (dank) wrote :

Did you try the rebased one, from comment #73 ?

Revision history for this message
In , trusktr (trusktr) wrote :

(In reply to comment #85)
> Did you try the rebased one, from comment #73 ?

Yeah, i tried it on wine 1.3.1 but not on 1.1.34 yet hehe. Um... But I have an idea. I'm just going to install Adobe Master Collection CS5 in windows then perform digital surgery and transplant it to wine.

Revision history for this message
In , trusktr (trusktr) wrote :

(In reply to comment #85)
> Did you try the rebased one, from comment #73 ?

Oh, hehe, Dan, by the way, how do I perform this digital surgery? :D

Revision history for this message
In , trusktr (trusktr) wrote :

By the way, has anyone requested a custom build using this patch yet (http://www.playonlinux.com/repository/wine-demand.php)?

Revision history for this message
In , rusivi2 (rusivi2-deactivatedaccount) wrote :

Does this occur in newest WINE?

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for posting this bug.

As per upstream web link:

http://appdb.winehq.org/objectManager.php?sClass=version&iId=14318

This is fixed as of 1.1.43. Marking as such.

Changed in wine (Ubuntu):
status: Triaged → Fix Released
Changed in wine:
importance: Unknown → High
Revision history for this message
In , Ken Sharp (kennybobs) wrote :

With a patched version of 1.3.7 the Accept button on the licence screen doesn't do anything, so cannot continue. This must be a regression as it did not do this before. Will look into this.

Revision history for this message
In , Richard-cornbread (richard-cornbread) wrote :

I vote that this gets fixed before 4-15. Would be nice to not have this bug go over the 2 year mark... This is a pretty high priority app in many circles just surprising it's gone this long without a proper fix.

Looks like all adobe has to do to stop linux adoption is make the installer not clickable or simply fail. :P

Revision history for this message
In , TTB (32b) wrote :

Shame that the installer fails when Photoshop, Dreamweaver and possibly more from the suite do actually work once setup but props to those that can hack at Wine and have gotten us this far.

Always been patient as understand these things take effort but would particularly love to see this fixed as might mean people then start looking at getting other programs from the suite working.

Since this only covers CS3 + CS4 might be worth mentioning there's also bug reports raised for CS5...
http://bugs.winehq.org/show_bug.cgi?id=22680
http://bugs.winehq.org/show_bug.cgi?id=22679

Revision history for this message
In , Andre_H (nerv-dawncrow) wrote :

*** Bug 25571 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

*** Bug 26484 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Focht (focht) wrote :

Hello,

refining summary. There are more apps that need separate CA server process either to fix COM/MTA problems or for isolation (crash handler invocations).

Regards

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

*** Bug 27546 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Sprog-g (sprog-g) wrote :

The bug is still in Wine 1.3.27 (amd64)

err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files (x86)\\Common Files\\Adobe\\caps" 1 -2147483644 0x172b2c 0x172b38 0x172c00 (nil)
err:msi:ITERATE_Actions Execution halted, action L"ProcessPropertyFile.E35C3ECB_5FDA_49E1_AB1F_D472B7CB9017" returned 1603
End Adobe Setup. Exit code: 4

Revision history for this message
In , Scott Ritchie (scottritchie) wrote :

With 1.3.28:

Adding the dummy thread patch lets the Photoshop CS4 Installer (linked above) start, however it fails to complete for some other reason. It looks like clicking the Next button on the license screen isn't doing anything (it generates an OLE warning each time in the terminal).

Without the dummy thread patch, the installer gets an error before its first screen.

Revision history for this message
In , Austin English (austinenglish) wrote :

*** Bug 21345 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Christine (fire-child) wrote :
Download full text (14.6 KiB)

I am still getting this same bug as well and I have tried everything I know :(

wine /media/Adobe\ CS3\ Design\ Premium/Adobe\ CS3/Setup.exe
fixme:console:AttachConsole stub ffffffff
Begin Adobe Setup
UI mode: Full GUI
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files\\Common Files\\Adobe\\caps" 1 -2147483644 0x13684c 0x136858 0x136950 (nil)
fixme:browseui:ProgressDialog_SetAnimation (0x1368c0, 0x400000, 1000) - stub
fixme:browseui:ProgressDialog_StartProgressDialog Flags PROGDLG_NOTIME not supported
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files\\Common Files\\Adobe\\caps" 1 -2147483644 0x16a8ec 0x16a8f8 0x16a9c0 (nil)
fixme:storage:create_storagefile Storage share mode not implemented.
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files\\Common Files\\Adobe\\caps" 1 -2147483644 0x193ebc 0x193ec8 0x193fc0 (nil)
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files\\Common Files\\Adobe\\caps" 1 -2147483644 0x193e24 0x193e30 0x193e60 (nil)
err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
err:ole:CoCreateInstance apartment not initialised
fixme:advapi:SetNamedSecurityInfoW L"C:\\Program Files\\Common Files\\Adobe\\caps" 1 -2147483644 0x193e6c 0x193e78 0x194ae8 (nil)
err:msi:ITERATE_Actions Execution halted, action L"ProcessPropertyFile.E35C3ECB_5FDA_49E1_AB1F_D472B7CB9017" returned 1603
End Adobe Setup. Exit code: 4
christine@christine:~$ wine /media/Adobe\ CS3\ Design\ Premium/Adobe\ CS3/
deployment/ payloads/ redist/ resources/ Setup.exe
christine@christine:~$ wine /media/Adobe\ CS3\ Design\ Premium/Adobe\ CS3/payloads/Adobe
AdobeAcrobat8en_US/ AdobeFlash9en_US/
AdobeALMAnchorServiceAll/ AdobeFlashPlayer9_axDbg_mul/
AdobeAssetServices3All/ AdobeFlashPlayer9_plDbg_mul/
AdobeAUM5.1All/ AdobeFlashVideoEncoder2en_US/
AdobeBridge2All/ AdobeFontsAll/
AdobeBridgeTalkPluginAll/ AdobeHelpViewerAll/
AdobeCameraRaw4.0All/ AdobeIllustrator13en_US/
AdobeCMapsAll/ AdobeInDesign5en_US/
AdobeColorCommonSetAll/ AdobeInDesignCS3IconHandler/
AdobeColorEU_ExtraSettingsAll/ AdobeLinguisticsAll/
AdobeColorEU_RecommendedAll/ AdobeMotionPictureAll/
AdobeColorJA_ExtraSettingsAll/ AdobePDFL8All/
AdobeColorJA_RecommendedAll/ AdobePDFSettingsAll/
AdobeColorNA_ExtraSettingsAll/ AdobePhotoshop10en_US/
AdobeColorNA_RecommendedAll/ AdobeSINGAll/
AdobeColorPhotoshopAll/ AdobeStockPhotos1.5All/
AdobeDefaultLanguageCS3All/ AdobeTypeSupportAll/
AdobeDesignSuitePremiumen_US/ AdobeVersionCue3All/
AdobeDeviceCentralAll/ AdobeVersionCueClient3All/
AdobeDreamweaver9en_US/ AdobeWASAll/
AdobeExtendScriptToolKitAll/ AdobeWinSoftLinguisticsPluginAll/
AdobeExtensionManager1.8All/ AdobeXMPPanelsAll/
christine@christine:~$ wine /media/Adobe\ CS3\ Design\ Premium/Adobe\ CS3/payloads/AdobeF
AdobeFlash9en_US/ AdobeFlashVideoEncoder2en_US/
AdobeFlashPlayer9_axDbg_mul/ AdobeFontsAll/
AdobeFlashPlayer...

Revision history for this message
In , Focht (focht) wrote :

*** Bug 15432 has been marked as a duplicate of this bug. ***

Revision history for this message
In , NSLW (nslw) wrote :

*** Bug 30589 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

*** Bug 30646 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Hans-meelstraat (hans-meelstraat) wrote :

*** Bug 30680 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Soohyun2222 (soohyun2222) wrote :

*** Bug 32689 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Sergey Sarbash (sarbash-s) wrote :

Applied the patch mentioned in #73 to the current source 1.5.22.
Only last hunk was failed so applied it manually.
Now, only "winetricks ie6" and Indesign CS3 was installed successfully.
Thank you very much.

Revision history for this message
In , Dimesio (dimesio) wrote :

*** Bug 33671 has been marked as a duplicate of this bug. ***

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

I see 1.5.31 is available for testing, and this bug is still sticking it's ugly little head up and I'm not sure if the patch mentioned in comment #73 will work on 1.5. How's the progress looking for a more permanent fix?

Revision history for this message
In , Ken Sharp (kennybobs) wrote :

Created attachment 45275
msi: Start a dummy thread to initialize an MTA (wine-1.6-rc5)

Still present, obviously.

Patch rebased to wine-1.6-rc5 works for me.

Note: We don't need any more console output or confirmation until a developer asks for it. This bug is well known.

Revision history for this message
In , Kevin Brodsky (cor-ax26) wrote :

I think this bug prevents any Adobe application from installing in fact (at least Acrobat XI). I can't believe such a nuisance is still there 5 years after being reported, with patches posted right here, without a dev taking a look at it?!

I think most Wine users would better have this fixed to be able to install the few major Windows software unmatched in Linux, rather than have DX10 fully implemented (which is for sure by far more complicated than this!).

Or maybe this bug is rooted deeper than it seems and a proper fix would need a huge rework? Anyway with a bug still being marked NEW after 5 years, hard to tell...

Revision history for this message
In , NSLW (nslw) wrote :

Corax made good point. To summarize:
- very old bug,
- blocks many other bugs (and thus applications),
- many observers,
- some patches already present.

Nevertheless no progress since long time.

Revision history for this message
In , Austin English (austinenglish) wrote :

Commenting on a bug is easy, coding is not. Wishing for the bug to be fixed doesn't make the work magically done.

The problem is known, and it's a lot of work to do. Patches are welcome (as with all bugs..).

Revision history for this message
In , Jamie Nadeau (james2432) wrote :

Might I remind everyone that is following this bug something that has been said countless times:

[QUOTE]Anastasius Focht 2009-08-09 04:20:40 CDT

Hello,

there is no need to provide test data.
The problem is well known and a short-term hack-patch exists which was consequently rejected by AJ.

Until someone takes up the task to implement "remote" custom actions (custom action server) you'll have to use the hack-patch.

Unfortunately this whole bug is now messed up with many useless/irritating comments that have nothing to do with the original bug.

Regards
[/QUOTE]

Thank you

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

(In reply to Ken Sharp from comment #108)
> Created attachment 45275 [details]
> msi: Start a dummy thread to initialize an MTA (wine-1.6-rc5)
>
> Still present, obviously.
>
> Patch rebased to wine-1.6-rc5 works for me.
>
> Note: We don't need any more console output or confirmation until a
> developer asks for it. This bug is well known.

How well will this patch work with the 1.7x branch?

Revision history for this message
In , Focht (focht) wrote :

Hello folks,

adding another "test-case", 'Windows Live ID Sign-in Assistant 6.5' required for newer GFWL (Games For Windows Live) 3.x clients.

Download: https://www.microsoft.com/en-us/download/confirmation.aspx?id=15106

COM is not initialized in any main/CA thread hence the failure of 'ole32.CoCreateInstance' in CA thread.

--- snip ---
$ WINEDEBUG=+tid,+seh,+relay,+msi wine msiexec -i wllogin_32.msi >>log.txt 2>&1
...
002b:trace:msi:HANDLE_CustomType1 Calling function L"CAPerformMUOptin" from L"C:\\users\\focht\\Temp\\msid8c6.tmp"
...
002b:Call KERNEL32.CreateThread(00000000,00000000,7ecf3c96,001b18a4,00000000,00000000) ret=7ecf3eab
002b:Ret KERNEL32.CreateThread() retval=000000a8 ret=7ecf3eab
002b:trace:msi:wait_thread_handle waiting for L"CAPerformMUOptIn"
...
002d:Starting thread proc 0x7ecf3c96 (arg=0x1b18a4)
002d:trace:msi:DllThread custom action (2d) started
002d:trace:msi:ACTION_CallDllFunction {ef9499af-7bcd-4aac-ad13-ebfa5220026c}
002d:trace:msi:DllGetClassObject {ba26e6fa-4f27-4f56-953a-3f90272018aa} {00000001-0000-0000-c000-000000000046} 0x9ce854
002d:trace:msi:MsiCF_CreateInstance 0x7edda178 (nil) {56d58b64-8780-4c22-a8bc-8b0b29e4a9f8} 0x9ce850
...
002d:Call KERNEL32.LoadLibraryW(00b28f4c L"C:\\users\\focht\\Temp\\msid8c6.tmp") ret=7ecf3907
002d:Ret KERNEL32.LoadLibraryW() retval=00d10000 ret=7ecf3907
...
002d:trace:msi:ACTION_CallDllFunction calling L"CAPerformMUOptin"
...
002d:Call ole32.CoCreateInstance(00d112d0,00000000,00000001,00d112b0,009ce830) ret=00d16c7c
002d:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=7eac6d64
002d:Ret ntdll.RtlAllocateHeap() retval=001edfe8 ret=7eac6d64
002d:err:ole:CoCreateInstance apartment not initialised
002d:Ret ole32.CoCreateInstance() retval=800401f0 ret=00d16c7c
...
002d:Call msi.MsiRecordSetStringW(00000003,00000000,001ee138 L"PPMSI_ERROR: CAPerformMUOptin: Could not Check for MU opt in. nReturn = -2147221008") ret=00d14d35
...
002d:trace:msi:DllThread custom action (2d) returned -2147221008
...
002b:err:msi:ITERATE_Actions Execution halted, action L"CAPerformMUOptIn" returned 1603
--- snip ---

$ sha1sum wllogin_32.msi
f477f8abc4519532ef2921b1343a06f2ac546c2c wllogin_32.msi

$ du -sh wllogin_32.msi
4.5M wllogin_32.msi

$ wine --version
wine-1.7.19-71-g94ccd61

Regards

Revision history for this message
In , Focht (focht) wrote :
Download full text (3.5 KiB)

Hello folks,

while visiting bug 16940 I made a trace log with 'Adobe Indesign CS4'.

There is nothing new, just for getting more search engine hits... so please ignore :)

--- snip ---
...
002a:Ret PE DLL (proc=0x100dc2c6,module=0x10000000 L"msid91c.tmp",reason=THREAD_ATTACH,res=(nil)) retval=1
002a:Starting thread proc 0x7be18b2a (arg=0x29e89b4)
002a:trace:msi:DllThread custom action (2a) started
002a:trace:msi:ACTION_CallDllFunction {a18ece91-2e21-4d3f-b36d-92bfac358582}
...
002a:trace:msi:ACTION_CallDllFunction calling L"Adobe_ProcessPropertyFile"
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a1bf0 L"19:58:17:970 -(Adobe)- -*-*-*-*-*-*-*-*-*-*-*-*- BEGIN - Adobe_ProcessPropertyFile -*-*-*-*-*-*-*-*-*-*-*-*- ") ret=10010ecc
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b49e048 L"19:58:17:971 -(Adobe)- Requesting property: PROPERTY_FILE ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a1b10 L"19:58:17:973 -(Adobe)- Value C:\\users\\focht\\Temp\\adbd633.tmp ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b49e048 L"19:58:17:974 -(Adobe)- Processing property file ") ret=10002eac
...
002a:Call ole32.CLSIDFromProgID(0b49e2a0 L"MSXML2.DOMDocument.6.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=00000000 ret=100909f1
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b49de90 L"MSXML2.DOMDocument.5.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=800401f3 ret=100909f1
002a:Call ole32.CLSIDFromProgID(0b49e118 L"MSXML2.DOMDocument.4.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=00000000 ret=100909f1
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b4a19b8 L"MSXML2.DOMDocument.3.0",0b79e054) ret=100909f1
...
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b4a19f0 L"MSXML.DOMDocument",0b79e054) ret=100909f1
...
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a19c0 L"19:58:17:976 -(Adobe)- Unable to load file: C:\\users\\focht\\Temp\\adbd633.tmp ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000004,00000000,0b49e048 L"19:58:18:111 -(Adobe)- #_AdobeError_# 1603 ") ret=100114b7
...
002a:trace:msi:MsiCloseHandle 1
002a:trace:msi:DllThread custom action (2a) returned 1603
002a:trace:msi:MsiCloseAllHandles
002a:trace:msi:MsiCloseHandle 3
002a:t...

Read more...

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

Created attachment 49557
msi: Start a dummy thread to initialize an MTA (wine-1.7.26)

Revision history for this message
In , Fincer (fincer89) wrote :

Created attachment 50758
msi: Start a dummy thread to initialize an MTA (wine-1.7.36)

Adobe Premiere Pro CS3 installer works fine with the patch from comment #73 applied to Wine 1.7.36 (see attachment). However, winetricks stuff which is still necessarily required (msxml3 msxml6 ie6 vcrun6).

*OT* You can also run Adobe Premiere Pro CS3 with Wine 1.7.36. There's serious GUI issues, though (Bug 38073). *OT*

Revision history for this message
In , Dimesio (dimesio) wrote :

*** Bug 40278 has been marked as a duplicate of this bug. ***

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

Created attachment 53943
Patch for running dummy MSI thread, updated for wine 1.9.5

action.c Patch for running dummy MSI thread, updated for wine 1.9.5

Revision history for this message
In , Qwerty Chouskie (asdfghrbljzmkd) wrote :

Could the dummy MSI thread patch at least get put in Staging?

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

Created attachment 58400
action.c Patch for running dummy MSI thread, updated for wine 2.10

I don't know if anybody still cares, but this patch works on wine 2.10

Revision history for this message
In , Emailmeat (emailmeat) wrote :

(In reply to Seann from comment #121)
> Created attachment 58400 [details]
> action.c Patch for running dummy MSI thread, updated for wine 2.10
>
> I don't know if anybody still cares, but this patch works on wine 2.10

I still care about Fireworks. If you have some free time, please take a look at this bug to see if you can do anything about it: https://bugs.winehq.org/show_bug.cgi?id=39086

Revision history for this message
In , Qwerty Chouskie (asdfghrbljzmkd) wrote :

(In reply to Seann from comment #121)
> Created attachment 58400 [details]
> action.c Patch for running dummy MSI thread, updated for wine 2.10
>
> I don't know if anybody still cares, but this patch works on wine 2.10

Thanks for keeping this up-to-date.

I submitted the patch to Wine Staging: https://dev.wine-staging.com/patches/132/
Let's hope this gets accepted.

Revision history for this message
In , Qwerty Chouskie (asdfghrbljzmkd) wrote :

(In reply to Qwerty Chouskie from comment #123)
> (In reply to Seann from comment #121)
> > Created attachment 58400 [details]
> > action.c Patch for running dummy MSI thread, updated for wine 2.10
> >
> > I don't know if anybody still cares, but this patch works on wine 2.10
>
> Thanks for keeping this up-to-date.
>
> I submitted the patch to Wine Staging:
> https://dev.wine-staging.com/patches/132/
> Let's hope this gets accepted.

It has been accepted into Staging. Yay!

Revision history for this message
In , Fjfrackiewicz (fjfrackiewicz) wrote :

(In reply to Qwerty Chouskie from comment #124)
> (In reply to Qwerty Chouskie from comment #123)
> > (In reply to Seann from comment #121)
> > > Created attachment 58400 [details]
> > > action.c Patch for running dummy MSI thread, updated for wine 2.10
> > >
> > > I don't know if anybody still cares, but this patch works on wine 2.10
> >
> > Thanks for keeping this up-to-date.
> >
> > I submitted the patch to Wine Staging:
> > https://dev.wine-staging.com/patches/132/
> > Let's hope this gets accepted.
>
> It has been accepted into Staging. Yay!

Shouldn't the status be set to "staging" along with the accepted patchset?

Revision history for this message
In , Gia- (gia-) wrote :

(In reply to fjfrackiewicz from comment #125)
[...]
> > > I submitted the patch to Wine Staging:
> > > https://dev.wine-staging.com/patches/132/
> > > Let's hope this gets accepted.
> >
> > It has been accepted into Staging. Yay!
>
> Shouldn't the status be set to "staging" along with the accepted patchset?

The description of the patch above says it's only a workaround to make the apps work until there is a proper fix.

I can't see a policy for this in https://wiki.winehq.org/Bugs
but I assume that a bug can be marked as "fixed on staging" only if it's a proper fix, even if it hasn't been merged into the main codebase yet because it needs reviewing and some improvements.

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to Giacomo Orlandi from comment #126)
> (In reply to fjfrackiewicz from comment #125)
> [...]
> > > > I submitted the patch to Wine Staging:
> > > > https://dev.wine-staging.com/patches/132/
> > > > Let's hope this gets accepted.
> > >
> > > It has been accepted into Staging. Yay!
> >
> > Shouldn't the status be set to "staging" along with the accepted patchset?
>
> The description of the patch above says it's only a workaround to make the
> apps work until there is a proper fix.
>
> I can't see a policy for this in https://wiki.winehq.org/Bugs
> but I assume that a bug can be marked as "fixed on staging" only if it's a
> proper fix, even if it hasn't been merged into the main codebase yet because
> it needs reviewing and some improvements.

That's not such an easy distinction to make. If the fix is proper, it wouldn't be in staging anyway, but in vanilla Wine.

If the bug exists in vanilla wine, but not wine-staging, it is reasonable to make the status 'STAGED'.

Side note: the staging version is less hacky than the original submission..

Changed in wine:
status: Confirmed → Unknown
Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

(In reply to Austin English from comment #127)
> (In reply to Giacomo Orlandi from comment #126)
> > (In reply to fjfrackiewicz from comment #125)
> > [...]
> > > > > I submitted the patch to Wine Staging:
> > > > > https://dev.wine-staging.com/patches/132/
> > > > > Let's hope this gets accepted.
> > > >
> > > > It has been accepted into Staging. Yay!
> > >
> > > Shouldn't the status be set to "staging" along with the accepted patchset?
> >
> > The description of the patch above says it's only a workaround to make the
> > apps work until there is a proper fix.
> >
> > I can't see a policy for this in https://wiki.winehq.org/Bugs
> > but I assume that a bug can be marked as "fixed on staging" only if it's a
> > proper fix, even if it hasn't been merged into the main codebase yet because
> > it needs reviewing and some improvements.
>
> That's not such an easy distinction to make. If the fix is proper, it
> wouldn't be in staging anyway, but in vanilla Wine.
>
> If the bug exists in vanilla wine, but not wine-staging, it is reasonable to
> make the status 'STAGED'.
>
> Side note: the staging version is less hacky than the original submission..

The staging version looks good. I'm going to test it this weekend.

Revision history for this message
In , Emailmeat (emailmeat) wrote :

It's good to see activity in an issue related to Fireworks.

Could any of you who worked on this take a look at https://bugs.winehq.org/show_bug.cgi?id=39086 or at least mark it as confirmed? Fireworks CS6 is completely unusable because of it.

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

I've been looking at a proper solution for this.

We already have the MSIServer service already implemented—it just doesn't do anything yet. I think the best way to fix this is to register the IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so not much change in infrastructure at all. I see two ways of doing this: either move all of the COM objects into msiexec.exe, or add an internal function in msi.dll. I like the first one for the sake of separation, but it does mean we need an internal idl.

Any thoughts on this from anyone else?

Revision history for this message
In , Dmitry-baikal (dmitry-baikal) wrote :

(In reply to Zebediah Figura from comment #130)
> I've been looking at a proper solution for this.
>
> We already have the MSIServer service already implemented—it just doesn't do
> anything yet. I think the best way to fix this is to register the
> IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so
> not much change in infrastructure at all. I see two ways of doing this:
> either move all of the COM objects into msiexec.exe, or add an internal
> function in msi.dll. I like the first one for the sake of separation, but it
> does mean we need an internal idl.
>
> Any thoughts on this from anyone else?

Did you try to investigate how that's done in Windows, so you wouldn't need
to invent custom interfaces?

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

(In reply to Dmitry Timoshkov from comment #131)
> (In reply to Zebediah Figura from comment #130)
> > I've been looking at a proper solution for this.
> >
> > We already have the MSIServer service already implemented—it just doesn't do
> > anything yet. I think the best way to fix this is to register the
> > IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so
> > not much change in infrastructure at all. I see two ways of doing this:
> > either move all of the COM objects into msiexec.exe, or add an internal
> > function in msi.dll. I like the first one for the sake of separation, but it
> > does mean we need an internal idl.
> >
> > Any thoughts on this from anyone else?
>
> Did you try to investigate how that's done in Windows, so you wouldn't need
> to invent custom interfaces?

Windows appears to have its own set of internal interfaces, e.g. {000c101c-0000-0000-c000-000000000046} "Msi install server". We actually have an IDL for these in msi.dll, since evidently some program tries to create one. But these interfaces are all internal; we don't even know the vtbls. It would appear that this approach would be close enough to replicating that one.

Revision history for this message
In , Dmitry-baikal (dmitry-baikal) wrote :

(In reply to Zebediah Figura from comment #132)
> Windows appears to have its own set of internal interfaces, e.g.
> {000c101c-0000-0000-c000-000000000046} "Msi install server". We actually
> have an IDL for these in msi.dll, since evidently some program tries to
> create one. But these interfaces are all internal; we don't even know the
> vtbls. It would appear that this approach would be close enough to
> replicating that one.

Does this help?
https://www.winehq.org/pipermail/wine-cvs/2007-January/029786.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa369432(v=vs.85).aspx

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

(In reply to Dmitry Timoshkov from comment #133)
> Does this help?
> https://www.winehq.org/pipermail/wine-cvs/2007-January/029786.html
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa369432(v=vs.85).
> aspx

Unfortunately, no. It seems pretty clear that IInstaller & co. aren't the interfaces to the server, since they can still be created and used while the service is disabled. Rather, I suspect, the interface labeled IMsiServer (and probably also the unlabeled 000C1094) are the interfaces, and these are not documented either as coclass or IDispatch.

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

Actually, on further testing, it seems that the server creates a separate process to run custom DLLs, so it's not necessarily true that we need a proper implementation of the server process.

Revision history for this message
In , Pembertona (pembertona) wrote :

Can anyone share exactly where this patch is staged? Is it available on 3.x staging builds for example? Or 2.21?

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

(In reply to Andy P from comment #136)
> Can anyone share exactly where this patch is staged? Is it available on 3.x
> staging builds for example? Or 2.21?

The patch should be included in 2.x and 3.x builds since 2.12.

Revision history for this message
In , Pembertona (pembertona) wrote :

Thanks, Zebediah. Does that mean -staging builds from then on? Or -devel too?

Revision history for this message
In , Austin English (austinenglish) wrote :

(In reply to Andy P from comment #138)
> Thanks, Zebediah. Does that mean -staging builds from then on? Or -devel too?

Just staging.

Revision history for this message
In , Pembertona (pembertona) wrote :

Thanks, Austin.

I've not found the patch to help with the dotnet40 issues related to msi's installing only 32 bit DLLs. My suspicion is that because the Executables involved are 32 bit themselves, they are loading msiexec through 32 bit. When I manually trigger msiexec on 64 bit, the correct DLLs are loaded - but only for 64 bit... and I think there are also some important steps loaded through the .exe that I then miss in the case.

In case it helps anyone, here's the command to run msiexec manually (and work around the prompt telling you only to use setup.exe):

wine64 'msiexec' '/i' 'c:/dotnet40/netfx_Core_x64.msi' 'EXTUI=1'

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :
Changed in wine:
status: Unknown → Fix Released
Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

I take it this does not apply to Wine development release 3.6, so I'll have to build from a fresh git or use the patch?

Revision history for this message
In , Ztirfe Elgnid (z-figura12) wrote :

(In reply to Seann from comment #142)
> I take it this does not apply to Wine development release 3.6, so I'll have
> to build from a fresh git or use the patch?

It does not apply to 3.6, but it'll be included in 3.7, which is released tomorrow.

Revision history for this message
In , Focht (focht) wrote :

Hello folks,

that's actually a great milestone after all the years analysing all the apps affected by this and collecting them here ;-)

*** NOTE ***

Currently it won't work because the MSI custom action server process crashes on all custom actions. See bug 45073 for details.
I hope a fix makes it in before the Wine 3.7 release - otherwise expect gazillion of bug reports.

I've tested with some smaller installers I could quickly get hold of (Windows SDK 2008) and they work as expected (after applying fix for bug 45073).

Regards

Revision history for this message
In , EvilSupahFly (seann-giffin) wrote :

(In reply to Zebediah Figura from comment #143)
> (In reply to Seann from comment #142)
> > I take it this does not apply to Wine development release 3.6, so I'll have
> > to build from a fresh git or use the patch?
>
> It does not apply to 3.6, but it'll be included in 3.7, which is released
> tomorrow.

Excellent! Thanks for the hard work!

Revision history for this message
In , Alexandre Julliard (julliard) wrote :

Closing bugs fixed in 3.7.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.