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.