Hi:
I have an MSI that sets up a Web site (IIS) that uses several COM DLLs and a Windows service (not Web service). The MSI is used for new installations as well as upgrade existing installations. Occasionally upgrades are not completely successful because a COM DLL is loaded in memory and is not replaced. Usually this results in a reboot prompt, but after rebooting the upgraded DLL is not present. While trying to reproduce this file-in-use scenario for a DLL, I used a vbscript to do a createObject on the DLL and then loop forever, while the DLL is repeatedly executing a database update. I checked the file date and version in installation folder (3/20/2008, 7.1.0.0) and ran ProcExplorer to watch the DLL running in CScript process. This worked, at least I see an "Info 1603" message in the verbose log: Info 1603. The file C:\Program Files\At\ServerObjects\COMs\AtDiagnostics.dll is being held in use by the following process: Name: cscript, Id: 2580, Window Title: '(not determined yet)'. Close that application and retry. And further down in the log, the MSI log shows that cscript process does not have a window: MSI (c) (08:1C) [16:31:24:046]: File In Use: -cscript- Window could not be found. Process ID: 2580 MSI (c) (08:1C) [16:31:24:046]: No window with title could be found for FilesInUse As expected I did not get the FilesInUse dialog. A little later, the log shows a reboot is scheduled: MSI (s) (94:7C) [16:43:56:848]: Note: 1: 1321 2: C:\Config.Msi\34e15f.rbf MSI (s) (94:7C) [16:43:56:848]: Verifying accessibility of file: 34e15f.rbf Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\34e15f.rbf. Must reboot to complete operation. Before the installation completed I looked in the install folder and found the new DLL (2/11/2009, 7.4.0.0). CScript was still running, the old DLL was still held in use by CScript, still showing in ProcExplorer. However, if I bring up properties for the DLL in ProcExplorer window, the properties are from the new DLL. After installation completes, there was no reboot prompt. The DLL was replaced. I was unable to reproduce the issue where the COM DLL was not replaced but what is worse, it's not clear why there was no reboot prompt and how the MSI was able to replace the DLL while it was held in use. Am I missing something? Is there any information about how Windows Installer replaces COM DLLs that are in use? Thanks, Greg _________________________________________________________________ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- View this message in context: http://n2.nabble.com/No-reboot-prompt-but-log-shows-reboot-scheduled-tp2417703p2417703.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
