Java Hotfix Feedback, a RIS-Based XP Installation Bug, and Several Other Hotfixes

Critical Java Hotfix Feedback
Last week I wrote about the MS02-052 hotfix, which eliminates a couple of critical security flaws in how Java screens access embedded code and objects. The Microsoft article "MS02-052: Flaw in Microsoft VM JDBC Classes Might Permit Code to Be Run" states that you must update all systems running Java version 3805 or earlier and that the version number after the installation should be 3807. Many of you emailed me to say the hotfix didn't change the Java version number: If you started at version 3805, the jview command, which displays the current version number, reported 3805 after you installed the hotfix.

After a little investigating, I discovered that the critical hotfix updates the Java version number in one registry key, but the jview command queries a different registry key when reporting the current Java version number. To be consistent, the MS02-052 hotfix should update the Java version number in both places.

MS02-052 creates a registry subkey in the Software hive and writes the information shown below in this subkey. On my test system, the key ending in CEDF was the last entry in the Installed Components list. You can confirm installation of this hotfix by verifying that this subkey and these values appear in the registry.

HKEY_LOCAL_MACHINESOFTWAREMicrosoftActive SetupInstalledComponents\{DBB3C81D-3C91-4a1e-BDDF-905B61C7CEDF}="Security Update for the Microsoft VM""ComponentID"="JAVAVM""IsInstalled"=hex:01,00,00,00"KeyFileName"="C:\WINDOWS\System32\msjava.dll""Version"="5,00,3807,0

After you install the MS02-052 hotfix, the version number in this registry key is 3807, as expected. However, the jview command apparently pulls the current version number from the first Installed Components key 08B0E5C0-4FCB-11CF-AAA5-00401C608500, not from the registry key the critical hotfix creates.

RIS-based XP Installation Bug Fix
If you use Windows 2000’s Remote Installation Service (RIS) to install Windows XP, you’ll be happy to know that Microsoft has corrected an authentication problem that prevents a successful installation of XP Service Pack 1 (SP1) slipstream builds. If you don’t install this patch, a RIS-based installation crashes with a stop code of 0x6b and error message PROCESS1_INITIALIZATION_FAILED. XP SP1 systems use a more secure authentication protocol, NT LAN Manager v2 (NTLMv2), to authenticate in a Win2K domain. A bug in how domain controllers (DCs) process the client’s authentication packets causes the setup failure. Microsoft Product Support Services (PSS) has an extensive update that resolves this problem: It contains 32 modified files, most of which have a file release date of August 26. To use RIS to deploy XP SP1 systems, you must apply the authentication patch to all DCs (not the RIS servers). For details, see the Microsoft article " 'Stop 0x0000006b' or Setup Stops Responding at 'Setup is Starting Windows' When You Install a Windows XP SP1 Client Image from a RIS Server," at http://support.microsoft.com/default.aspx?scid=kb;en-us;q327536.

Disk Manager Hangs Services.exe
If you stop and restart the Microsoft Management Console (MMC) Disk Manager snap-in utility several times in a row, you might encounter a deadlock in the master service management component, services.exe. One symptom of this problem is that the services.exe component hangs, and the system doesn't respond to net stop and net start commands you enter at a command prompt. A second symptom is that Disk Manager doesn't detect device changes, for example, when you place a disk into a removable-media drive. If either of these problems occurs on your systems, you need to reboot to restart services.exe. This deadlock problem exists in all versions of Windows 2000, including Service Pack 3 (SP3). Contact Microsoft PSS for a fix that contains updates of 24 system components, most of which have a release date of August 27. Reference: For more information, see the Microsoft article "Services.exe May Hang When You Restart a Service," at http://support.microsoft.com/default.aspx?scid=kb;en-us;q328477.

Stressed Server Blues
An extremely busy Windows 2000 server running either Win2K Server Terminal Services or Microsoft IIS might crash several times a week with a stop code of 0x0a. Before the crash, clients report that the server is very slow to respond to input. The failure is caused by the thread management method the OS uses to manage multiple requests to access the same data structure. When multiple accesses to the same object encounter delays, the system activates a CPU "starvation avoidance" algorithm to improve response time to the outstanding requests. The blue screen occurs when the system incorrectly attempts to increase the priority of a thread that no longer exists. The system crash affects all versions of Win2K, including Service Pack 3 (SP3). It occurs most often on terminal servers but can also occur on IIS systems that manage multiple concurrent requests to the same object. Microsoft Product Support Services (PSS) has a bug fix that contains a new version of the redirector, mrxsmb.sys, and rdbss.sys. Both files have a release date of September 23. For details, see the Microsoft article "Stop 0x0a Error in nt!ExpBoostOwnerThread() Occurs on a Large Terminal Server Installation" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q321613.

MSTask Leaks Handles
When you schedule a batch job with MSTask and the batch job runs with the same account as the currently logged-on user, the task scheduler creates a handle to the user’s profile that it never returns. If the same task runs multiple times during one interactive session, the handle leak can potentially consume crucial system paged pool space. The leak also delays the unloading of a roaming profile when the user logs off. The fix updates two task scheduler files, mstask.dll and mstask.exe, with release dates of October 1 and September 30, respectively. See the Microsoft article "A Handle Leak Occurs in Mstask.exe," at http://support.microsoft.com/default.aspx?scid=kb;en-us;q329346, for more information.