[Bug 10365] Nero 7 essentials fails to install (NeroAg_Init custom action fails because CA dll instance data is not reset/unloaded due to binary dll resource reference kept from main msi thread)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10365

--- Comment #23 from Anastasius Focht <focht at 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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.