Post-SP2 FRS Update
The Windows 2000 post-Service Pack 2 (SP2) File Replication Service (FRS) update contains many improvements that speed FRS performance, eliminate timeouts, and reduce the need for nonauthoritative restores. In native Win2K domains, the update results in obvious speed improvements and more robust and reliable file replication. Here’s a quick overview of the changes:
FRS no longer replicates files that Group Policy updates have incorrectly marked as changed.
FRS now obtains replica sets from partner systems serially, which cuts both the time and the resources that FRS requires to obtain replica information.
FRS uses a new algorithm that lets the service continue to replicate files, even when the staging area is 90 percent full. The new algorithm permits FRS to delete staging files until the amount of space consumed drops below 60 percent of the staging area’s capacity, which is 660MB by default.
The update increases the FRS journal size to a default of 128MB. The larger size reduces the frequency of journal overwrites and nonauthoritative restores.
Instead of automatically initiating a nonauthoritative restore, FRS writes a message indicating that the restore is required in the FRS event log.
FRS lets you change the staging path without first requiring a nonauthoritative restore. To change the staging path, stop FRS, move the files, and restart the service.
The update eliminates an earlier bug that cropped up when the SP2 version of FRS attempted to replicate compressed files.
This post-SP2 update contains new versions of the five components responsible for file replication: ntfrs.exe, ntfrsapi.dll, ntfrsprf.dll, ntfrsres.dll, and ntfrsutl.exe. You must contact Microsoft Product Support Services (PSS) to obtain the update. For more information, see Microsoft article Q307319.
New Multiprocessor Issues
I seldom track problems that pertain to multiprocessor systems, but because of the prevalence of two- and four-CPU systems today, I now pay attention. Here are two problems that I recently became aware of:
A USB lockup problem. If you connect a USB device that has multiple ports (i.e., not a mouse or keyboard), the device might stop responding after you read or write a large amount of data. When the USB device hangs, you must reboot the machine to restore system operation. Call Microsoft Products Support Services (PSS) for the bug fix, a new version of uhcd.sys with a file release date of January 11, 2002. For more information, see Microsoft article Q306788.
A ClassPnP Blue Screen. The generic Plug and Play (PnP) driver, classpnp.sys, contains a bug that affects only multiprocessor systems. If your system crashes repeatedly and displays a stop code on a blue screen that identifies classpnp.sys as the culprit (i.e., Stop Code Ox1E), you need the code fix. Call PSS and ask for the version of classpnp.sys that has a file-release date of November 16, 2001. For more information, see Microsoft article Q311278.
Corrupt Recycle Bins
If you used the Subst command to create a virtual drive on your Windows XP or Windows 2000 system, you might see an error message stating that the Recycle Bin is either corrupt or invalid when you try to delete files or directories. The file system generates this error when it can't successfully compare permissions on the virtual drive, which it must do before it deletes the file or folder. Microsoft released the Win2K bug fix, shell32.dll, in June 2001 and released the equivalent update for XP systems on January 10, 2002. You must contact Microsoft Product Support Services (PSS) to get the update. For more information, see Microsoft article Q297760.
If you don't have a username & password, please
register now.
Reader Comments
Nice to see someone taking onboard the fact that there is a growing number of multiprocessor servers out there - but don't forget NT !!
I've got 2 NT4 SP6a domain controllers (one running NT4 & Exchange 5.5, the other running SBS 4.5)on totally separate customer sites. Both are rebooting randomly, 2-3 times a week, with the following STOP bugcheck error (never varies) :
The only thing they have in common is dual PIII processors (one pair @ 700MHz and the other pair @ 1GHz)and software mirrored SCSI drives.
Technet refers to a similar error saying that the problem is caused by timing errors between the CPUs e.g. when writing to mirrored disks. But no fix. Any ideas ?