[Bug 8062] Adobe Acrobat Pro 7 Tryout installer crashes while trying to remove printer

[Wine Bugs]

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

------- Additional Comments From [e-mail]  2007-02-06 07:37 -------
Hello,

--- quote ---
Not an msi bug.
--- quote ---

ok, this statement convinced me to debug this one on windows too :-)

- full msi logging/debug verbosity enabled (msi installer policy:
"Logging"="voicewarmup", "Debug=0x3")
- MsiBreak "UninstallPrinter"

Windows MSI breaks upon this custom action in same helper dll, so this action is
executed on windows too.

--- snip windows msi log ---
..
MSI (s) (DC:E4) [13:05:41:859]: Executing op: ActionStart(Name=UninstallPrinter,,)
Action 13:05:41: UninstallPrinter. 
MSI (s) (DC:E4) [13:05:41:859]: Executing op:
CustomActionSchedule(Action=UninstallPrinter,ActionType=3137,Source=BinaryData,Target=DeleteDistillerPrinter,)
MSI (s) (DC:E4) [13:05:41:859]: Creating MSIHANDLE (827) of type 790536 for
thread 2276
MSI (s) (DC:8C) [13:05:41:859]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI191.tmp, Entrypoint: DeleteDistillerPrinter
MSI (s) (DC:04) [13:05:41:859]: Generating random cookie.
MSI (s) (DC:04) [13:05:41:875]: Created Custom Action Server with PID 2416 (0x970).
MSI (s) (DC:CC) [13:05:41:906]: Running as a service.
MSI (s) (DC:88) [13:05:41:921]: Hello, I'm your 32bit Elevated custom action server.
MSI (s) (DC:8C) [13:05:42:078]: Closing MSIHANDLE (827) of type 790536 for
thread 2276
..
--- snip windows msi log ---

It produces same access violation exception due to buggy custom action dll code
(see my comment #3 for explanation) - but it doesnt crash the custom action
server itself.

The installer service employs additional "security" measures to guard against
"rogue" action code.
It checks for stack corruption upon return of custom msi action call
(debugprints "Possible stack corruption. Custom action may not be declared
__stdcall." in that case).
But this measure only applies if the top level custom action was declared wrong.
It can never detect/repair any stdcall/cdecl misuse within the custom action
code itself (like in this case due to messed up return stack after
"DeletePrinterDriverExA").

The second measure is an structured exception handler, set by MSI which catches
access violations produced by rogue custom action code.
This allows to recover without crashing the whole custom action server instance.

If adobe devs had done MsiBreak="UninstallPrinter" they would see the same crash
on their crappy code, regardless if windows or wine.

The file which contains the <censored for mild profanity> code (temporarily
extracted from installer):

temp name: msiXXXX.tmp
real name: Adobeisf.dll
size: 53.248 bytes
version resource comment: "Installer utility file"

Regards