Hello everyone:
I ran into this problem creating a package with the PDW, and apparently the problem is widespread. In my case, I was creating the package on an XP system and attempting to install it on a Win2000 system.
The problem arises when the package has system files (if you open SETUP.LST, you will find that files that are installed to $(WinSysPathSysFile) are candidates to cause this problem. Here is an example from my travels:
File9=@msjtes40.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,4/2/02 10:51:52 AM,241695,4.0.5914.0
Note the last part of the string: 4.0.5914.0. This is the version number of the copy of the file on the machine creating the package. On the install machine, there is an earlier version, which you can verify by finding the file (should be WINxxxx/SYSTEM32 directory) and checking the version in its properties. This situation will raise our by now familiar error message.
All of the fixes (add service packs, make sure the temp file is in the right place, etc. etc.) are attempts to upgrade the existing system file to the one in the package. The common thread in all of the problems is the attempt to install a newer version of a system dll on top of an older version being used by the installee system. This is especially a problem when using XP (and probaby Win2003 as well) to create packages that are intended for Win2000 systems.
Solutions differ for Win9x and Win2000 systems.
In neither opsys type can one overwrite a system file dll: by definition, the system is using it and prevents a full lock.
Win 9x: Win 9x systems, when encountering a newer version of a system file, write the file to the temp directory (specified by the set temp and set tmp commands). On bootup, the system looks in the temp directory and overwrites older system files with newer ones in said directory. This works fine, assuming the opsys can find the temp directory and the files haven't been erased. Workarounds to these problems are well-documented and basically trivial.
Win 2000: According to the Microsoft documentation:
"Both installation programs (ASW and PDW) use the same method to delay the replacement of in-use system files until reboot. For any system files that are in use, the new files are saved as temporary files in the Temp folder. In order to replace the existing files with the .tmp files, the system will use the Wininit.ini file on WIN 9x systems. On Windows NT and Windows 2000, the system will call the MoveFileEx function with the MOVEFILE_REPLACE_EXISTING flag. This function places the file replacement instructions in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
If something interferes with this replace and rename operation, these files are not updated. Therefore, once the computer reboots and restarts the installation program, the same error message appears."
I ran the offending SETUP.EXE file, got my error message, and started looking around. I was unable to find a "PendingFileRenameOperations" key under SessionManager, although I did find a "FileRenameOperations" key with no value set. Second, I was unable to find any temp files in the temp directory. Although it is possible that I made some sort of arcane setting on the several test systems I have been using to prevent the documented behavior, my practical conclusion is that Win2000 systems do not allow the direct overwriting of system files, despite suggestions to the contrary in this documentation.
The overwriting of system files can be accomplished through the installation of service packs. However, Win2000 service packs cannot be expected to have system dll's that are up to date in terms of WinXP/2003 environments.
The important ramification of these conclusions is that PDW packages created on systems later than Win2000 with no service packs are not downwardly compatible with Win2000 systems with earlier service packs, and in a less than gracious fashion to boot.
Therefore, the most "foolproof" packaging strategy is to keep a machine or virtual machine with a Win2000 opsys with no service pack, or an earlier Win 9x or NT machine. Do your development on whatever system you like, but use the PDW on this machine. This will ship old versions of the system files that will not be installed.
Bob Rodes
I ran into this problem creating a package with the PDW, and apparently the problem is widespread. In my case, I was creating the package on an XP system and attempting to install it on a Win2000 system.
The problem arises when the package has system files (if you open SETUP.LST, you will find that files that are installed to $(WinSysPathSysFile) are candidates to cause this problem. Here is an example from my travels:
File9=@msjtes40.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,4/2/02 10:51:52 AM,241695,4.0.5914.0
Note the last part of the string: 4.0.5914.0. This is the version number of the copy of the file on the machine creating the package. On the install machine, there is an earlier version, which you can verify by finding the file (should be WINxxxx/SYSTEM32 directory) and checking the version in its properties. This situation will raise our by now familiar error message.
All of the fixes (add service packs, make sure the temp file is in the right place, etc. etc.) are attempts to upgrade the existing system file to the one in the package. The common thread in all of the problems is the attempt to install a newer version of a system dll on top of an older version being used by the installee system. This is especially a problem when using XP (and probaby Win2003 as well) to create packages that are intended for Win2000 systems.
Solutions differ for Win9x and Win2000 systems.
In neither opsys type can one overwrite a system file dll: by definition, the system is using it and prevents a full lock.
Win 9x: Win 9x systems, when encountering a newer version of a system file, write the file to the temp directory (specified by the set temp and set tmp commands). On bootup, the system looks in the temp directory and overwrites older system files with newer ones in said directory. This works fine, assuming the opsys can find the temp directory and the files haven't been erased. Workarounds to these problems are well-documented and basically trivial.
Win 2000: According to the Microsoft documentation:
"Both installation programs (ASW and PDW) use the same method to delay the replacement of in-use system files until reboot. For any system files that are in use, the new files are saved as temporary files in the Temp folder. In order to replace the existing files with the .tmp files, the system will use the Wininit.ini file on WIN 9x systems. On Windows NT and Windows 2000, the system will call the MoveFileEx function with the MOVEFILE_REPLACE_EXISTING flag. This function places the file replacement instructions in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
If something interferes with this replace and rename operation, these files are not updated. Therefore, once the computer reboots and restarts the installation program, the same error message appears."
I ran the offending SETUP.EXE file, got my error message, and started looking around. I was unable to find a "PendingFileRenameOperations" key under SessionManager, although I did find a "FileRenameOperations" key with no value set. Second, I was unable to find any temp files in the temp directory. Although it is possible that I made some sort of arcane setting on the several test systems I have been using to prevent the documented behavior, my practical conclusion is that Win2000 systems do not allow the direct overwriting of system files, despite suggestions to the contrary in this documentation.
The overwriting of system files can be accomplished through the installation of service packs. However, Win2000 service packs cannot be expected to have system dll's that are up to date in terms of WinXP/2003 environments.
The important ramification of these conclusions is that PDW packages created on systems later than Win2000 with no service packs are not downwardly compatible with Win2000 systems with earlier service packs, and in a less than gracious fashion to boot.
Therefore, the most "foolproof" packaging strategy is to keep a machine or virtual machine with a Win2000 opsys with no service pack, or an earlier Win 9x or NT machine. Do your development on whatever system you like, but use the PDW on this machine. This will ship old versions of the system files that will not be installed.
Bob Rodes
