This is my log: MSI (s) (D8:E8) [10:34:00:250]: Doing action: ReadSqlBinPath Action 10:34:00: ReadSqlBinPath. Action start 10:34:00: ReadSqlBinPath. MSI (s) (D8:E8) [10:34:00:343]: Creating MSIHANDLE (31) of type 790542 for thread 3048 MSI (s) (D8:B0) [10:34:00:421]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIE0.tmp, Entrypoint: ReadSqlBinPath MSI (s) (D8!24) [10:34:01:031]: Creating MSIHANDLE (32) of type 790531 for thread 2084 SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSIE0.tmp-\ MSI (s) (D8!24) [10:34:01:031]: Closing MSIHANDLE (32) of type 790531 for thread 2084 MSI (s) (D8!24) [10:34:01:078]: Creating MSIHANDLE (33) of type 790531 for thread 2084 SFXCA: Binding to CLR version v4.0.30319 MSI (s) (D8!24) [10:34:01:078]: Closing MSIHANDLE (33) of type 790531 for thread 2084 MSI (s) (D8!24) [10:34:01:281]: Creating MSIHANDLE (34) of type 790531 for thread 2084 Calling custom action Gendis.ProSync.CustomAction!zzz.zzz.CustomAction.SqlCustomActions.ReadSqlBinPath MSI (s) (D8!24) [10:34:01:296]: Closing MSIHANDLE (34) of type 790531 for thread 2084 MSI (s) (D8!24) [10:34:01:328]: Creating MSIHANDLE (35) of type 790531 for thread 2084 ReadSqlBinPath: Begin MSI (s) (D8!24) [10:34:01:328]: Closing MSIHANDLE (35) of type 790531 for thread 2084 MSI (s) (D8!24) [10:34:01:328]: PROPERTY CHANGE: Adding SqlBinPath property. Its value is 'c:\Program Files\Microsoft SQL Server\100\Tools\Binn\'. MSI (s) (D8:B0) [10:34:01:343]: Closing MSIHANDLE (31) of type 790542 for thread 3048 Action ended 10:34:01: ReadSqlBinPath. Return value 3.
Slightly different I believe. Neil From: Christopher Painter [mailto:chr...@iswix.com] Sent: 24 January 2012 19:41 To: Neil Sleightholm; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec Neil, I think you're spot on with what I'm seeing. My static method entry point instantiates a class which then logs that it's been created and then nothing. Run it again and it's fine. Here are some snippets from the log: PS- FWIW, I plan on making a fake MSI that just does some infrastructure tests and run it regularly through SCCM across the enterprise to try to get some metrics. --------------------------------------------- // Setting up the CustomActionData during the costing action.... MSI (s) (94!70) [00:00:12:479]: PROPERTY CHANGE: Adding UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4 property. Its value is '[]'. ...... // Script Generation Phase... MSI (s) (94:18) [00:00:13:151]: Doing action: UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4 Action start 0:00:13: UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4. ..... // Script Execution Phase... MSI (s) (94:18) [00:00:15:869]: Executing op: ActionStart(Name=UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4,,) MSI (s) (94:18) [00:00:15:869]: Executing op: CustomActionSchedule(Action=UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4,ActionType=1025,Source=BinaryData,Target=UninstallPrinterDrivers,CustomActionData=[]) MSI (s) (94:38) [00:00:15:885]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI981C.tmp, Entrypoint: UninstallPrinterDrivers SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI981C.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action PrinterDriverCA!PrinterDriverCA.RemovePrinterDrivers.UninstallPrinterDrivers Class Constructed ( Logged from Base ) CustomAction UninstallPrinterDrivers.A2D45838_79FA_464A_AC38_8A203E43C3A4 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (94:18) [00:00:16:494]: User policy value 'DisableRollback' is 0 MSI (s) (94:18) [00:00:16:494]: Machine policy value 'DisableRollback' is 0 Action ended 0:00:16: InstallFinalize. Return value 3 ________________________________ From: "Neil Sleightholm" <n...@x2systems.com<mailto:n...@x2systems.com>> Sent: Tuesday, January 24, 2012 11:38 AM To: "chr...@iswix.com<mailto:chr...@iswix.com>" <chr...@iswix.com<mailto:chr...@iswix.com>>, "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net<mailto:wix-users@lists.sourceforge.net>> Subject: RE: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec I can't help but I have seen something similar to 1 - my DTF action is an immediate action that just reads the registry and sets a property, 99% of the time it is fine. The tracing all indicates it is ok but on exit it returns "value 3", no logs, exception or anything useful - run again and it is fine. I started to think the problem was in DTF but I never got a good enough repro to debug it. Neil -----Original Message----- From: Christopher Painter [mailto:chr...@iswix.com]<mailto:[mailto:chr...@iswix.com]> Sent: 24 January 2012 16:35 To: wix-users@lists.sourceforge.net<mailto:wix-users@lists.sourceforge.net> Subject: [WiX-users] Two Wierd Installer Problems - DTF and QuietExec I have an installer that I wrote that I've been pushing out through SCCM. We have deployed to about 600 servers so far and so far I've seen 6 failures. There are 3 of one failure mode and 3 of another. 1) C# DTF terminates with 1603 This one is wierd. It's a deferred CA that get's it's CustomActionData property and then does something for each record in the collection. There's actually no records in the collection so therefore nothing to do. I don't get any kind of .NET stack dump it just simply logs that it started and then poof the CA returns with a 1603. On the other 597 servers it works ( i.e. does nothing ) just fine. ( Trivia: it's really an uninstall custom action that can be instructed to remove something during an install I just haven't neeed to yet. ) If I run this install again on the same machine it works. 2) I use a QuietExecCA64 to call dism to install a Windows feature. I see in the log that DISM added the feature and completed successfully but then that's the end of my MSI log. It's like either DISM didn't actually terminate of the C++ code didn't terminate and it hung MSI. SCCM then waited a period of time ( 20 minutes ) and decided that the MSI was orphaned and killed it followed by a reboot. All of these machines are Server 2008 R2 SP1. Does anyone have any thoughts about this? I could redo #1 as a C++ CA and I could factor the DISM call out of the MSI and into the SCCM task sequence but I think at this point people are willing to take their changes since we are already 25% into the deployment. I'm wondering if there are any bugs in DTF and or the QuietExec patterns that need to be investigated. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net<mailto:WiX-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
