New Qchain Release Corrects Versioning Bug
If you use a script to install multiple hotfixes with only one system restart, you probably invoke the Qchain utility at the end of the script. Qchain examines the files each hotfix replaces, identifies hotfixes that update the same file, and ensures that only the most recent file version is installed. The March release of Qchain corrects situations in which the utility doesn't install the most recent version of a file. This bug occurs when you install two or more patches that contain different versions of the same file, and that file is open when the hotfix installation runs. When you update an open OS component, the file replace operation occurs after you reboot; for each file you want to replace, the update procedure for service packs and hotfixes uses a File Rename Pending operation. Here’s where the Qchain problem crops up. For example, let’s assume that you're going to install two hotfixes that update shell32.dll, the component that supports many desktop operations. The first hotfix installs shell32.dll version 6344, and the second hotfix installs shell32.dll version 6345. Because shell32.dll version 6345 is more recent, you expect to see version 6345 when the system restarts. According to the Microsoft article "The Correct File Is Not Installed When You Chain Multiple Hotfixes" ( http://support.microsoft.com/?kbid=815062 ), Qchain copies the most recent version (6345) to disk but renames the file to the lower version number. If I'm interpreting the problem description correctly, the system has the most current version of shell32.dll, but the file has the wrong version number (6344 instead of 6345). The disparity can cause errors when the Windows File Protection (WFP) component attempts to verify the file by comparing the loaded file’s version and file signature against the version and signature in the catalog. If the file has the wrong version number, the comparison file will likely fail. Microsoft states that Windows XP and Windows 2000 hotfixes released on or before December 2000 contain the buggy version of Qchain, so this problem has a broad reach. This bug also can cause widespread problems if you use scripts and Qchain to update XP, Win2K, and Windows NT systems using scripts and Qchain. You can work around the problem by expanding hotfixes and grouping only those updates that have no OS components in common. You can solve the problem by downloading the new version of Qchain at http://microsoft.com/downloads/details.aspx?familyid=3c64d889-74f1-490b-a2fb-f15671a3b60c&displaylang=en or from the catalog at Windows Update (search for article 815062).
Where Did Network Connections Go?
Have you ever gone to the Network and Dial-Up Connections Group only to discover that the only available icon is one that lets you define a new dial-up connection? Or, alternatively, when you start the Make New Connection Wizard, the only available options are Dial-up to the Internet or Accept Incoming Connections. The following events can cause this puzzling state of affairs on XP and Win2K systems.
1. A duplicate rasapi32.dll file exists in the system root. This file is usually in the %systemroot%system32 and %systemroot%system32\dllcache directories (and possibly some service pack uninstallation directories). If this file exists anywhere else in %systemroot%, you need to delete the rogue copies and restart the Remote Access Connection Manager Service.
2. The Telephony or Remote Access Connection Manager services aren't running. If so, start the stopped service. If the services are running, restart them and see whether it corrects the problem.
3. A user-specific registry setting is preventing access to network connections. Microsoft provides no information about how or why the registry contains invalid data, but the company does indicate that you should delete the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Telephony\Cards\Next registry subkey and restart the Make New Connection Wizard. You might also want to restart the Telephony service after you make this registry modification.
4. You use NTBackup to restore the System State, and network adapters are missing or identified incorrectly. NTBackup has a known Plug and Play (PnP) bug that occurs when you restore the system state on Win2K systems. A new version of NTBackup is available directly from Microsoft Product Support Services (PSS). If you can’t wait for a support contract, you can work around the problem by modifying a registry subkey on the target system before you initiate the restore. The subkey tells NTBackup not to restore the PnP database. See the Microsoft article "Network Adapters Are Missing or Incorrect in Device Manager After You Run NTBackup to Restore System State Data" (http://support.microsoft.com/?kbid=810161) for details.
