http://bugs.winehq.org/show_bug.cgi?id=11759 --- Comment #25 from Anastasius Focht <focht(a)gmx.net> 2008-08-05 16:34:41 --- Created an attachment (id=15304) --> (http://bugs.winehq.org/attachment.cgi?id=15304) +tid,+seh,+msi,+msidb trace Hello, attached is relevant msi trace. That file(s) in question resides in msi patch db (silverlight.msp) and is not temporarily extracted at the time, hence the copy fails. There is also a bug in MsiConfigureProductExW() which sometimes leads to premature failures. --- snip dlls/msi/msi.c --- UINT WINAPI MsiConfigureProductExW(LPCWSTR szProduct, int iInstallLevel, INSTALLSTATE eInstallState, LPCWSTR szCommandLine) { MSIPACKAGE* package = NULL; MSIINSTALLCONTEXT context; UINT r; DWORD sz; WCHAR sourcepath[MAX_PATH]; WCHAR filename[MAX_PATH]; .. sz = sizeof(sourcepath); memset( sourcepath, 0, sz); MsiSourceListGetInfoW(szProduct, NULL, context, MSICODE_PRODUCT, INSTALLPROPERTY_LASTUSEDSOURCEW, sourcepath, &sz); sz = sizeof(filename); memset( filename, 0, sz); MsiSourceListGetInfoW(szProduct, NULL, context, MSICODE_PRODUCT, INSTALLPROPERTY_PACKAGENAMEW, filename, &sz); lstrcatW(sourcepath, filename); r = MSI_OpenPackageW(sourcepath, &package); .. } --- snip dlls/msi/msi.c --- If MsiSourceListGetInfoW() calls fail for some reason and don't fill out/return buffer (see fixme:msi:MsiSourceListGetInfoW Unhandled context 4), you might end up copying garbage because the buffer is allocated on stack and not explicitly initialized. 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.