http://bugs.winehq.org/show_bug.cgi?id=10365
--- Comment #23 from Anastasius Focht focht@gmx.net 2011-07-01 18:37:22 CDT --- Hello Hans,
--- quote --- This was done for two custom actions in the Office 2010 installer where the second depends on the initialization state of the first (it generates database keys from a time stamp). --- quote ---
Ok, I did some testing with a patch that does not pin the custom action dlls in memory to verify my findings from debugging session. The Adobe installer runs further - only to run into msxml bug which is a different issue.
Out of curiosity I downloaded MS Office 2010 and looked into the issue.
First thing I noticed was that enabling debugging channels (+msi is sufficient) or attaching to that "OcaArpWrite" custom action using MsiBreak and continue execution magically "fixes" the custom action/installer.
Then I saw the mess ... some guys at Microsoft had the "bright" idea to use GetTickCount() as seed value for generating unique database keys. There is a static guard/check so GetTickCount() gets only called once. Any subsequent request for creation of new temporary database records will increment the value (by one).
When the custom action dll is unloaded, the id value/counter is the initial GetTickCount() + increments due to requests for new database records. With the same custom action dll mapped again there is a chance that the new seed value returned by GetTickCount() is still within the range of previous seed + number of requested database records (assuming no WINEDEBUG tracing that slows down). To verify this I added a small (safe) delay of 500 msecs at the beginning of custom action thread and it helped the Office 2010 installer to succeed. On Windows there is probably tons of msi bloat (remote ca server) that adds sufficient delay to not make this problem appear.
Your approach of keeping the custom action dlls pinned in memory to fix Office 2010 installer makes this Adobe installer basically a WONTFIX.
Maybe we should just collect installers that depend on custom action dlls being completely unloaded and review the decision again if critical mass is reached or too many users complain. The only problem is all the wasted time debugging custom actions to find out about this issue. Breakage due to instance data issue is not that easy to spot.
Regards