A Windows NT 4.0 Bug Fix Update

A TCP/IP crash. If you’re running a multiprocessor FTP server, your system might crash and display stop code 0x0000000A from tcpip.sys. A buffer-management error that occurs when the system processes TCP/IP packets from non-Windows systems causes the crash. Call Microsoft Support to obtain the bug fix, a February 4 version of tcpip.sys. Microsoft documents the bug, which exists in all versions of NT 4.0, in Microsoft Support Online article Q252664 .

LPD access violation. Yep, another bug fix for printing from a UNIX client to a Line Print Daemon (LPD) printer. When a print job from a UNIX system contains invalid bytes at the end of the job, the LPD service generates an access violation (Dr. Watson) from tcpip.sys. Call Microsoft for the February 7 update of lpdsvc.dll, which processes the invalid bytes without crashing the printing service. Microsoft documents the issue in Microsoft Support Online article Q253714.

Full NTFS volume incorrectly marked dirty. We all know that we need to keep at least 20 percent of a disk drive free for top performance, but every now and then a disk fills up unexpectedly. In NT 4.0, when a drive fills up and the file system can’t allocate space for its internal data structures (e.g., entries in the Master File Table—MFT—or an index file), the file system incorrectly labels the full volume dirty, even though no structural errors exist. Chkdsk runs every time you reboot a system that has a full disk, so this bug, which applies to all versions of NT 4.0, is an annoyance and a problem because you have to wait for Chkdsk to complete before you can restart the system. According to Microsoft Support Online article Q253229, data on a full volume retains its integrity, even when the drive is full. If you’re experiencing this problem, call Microsoft Support for the February 2 release of ntfs.sys, which doesn’t enable the dirty bit when a disk is at capacity.

Network file transfer timeouts. Microsoft Support Online article Q252332 describes a redirector timeout problem that occurs when many clients transfer large files to a server whose server disk I/O is near capacity. When the redirector timeout occurs, the file transfer from the client to the server might fail and generate the message, "Error 3013, The redirector has timed out to " in the client’s event log. Redirector timeout messages are generic errors that indicate that the server didn’t respond to the client within the timeout period.

When Microsoft reproduced the problem, it determined that the redirector timeout occurs only when NT 4.0 clients connect to a Windows 2000 (Win2K) server with a combination of the following conditions: a large number of concurrent network file transfers, a server with more than 128MB of RAM, and a RAID 5 stripe set. In such a scenario, the cache manager causes the timeout because it locks file resources for longer than the redirector timeout period. Microsoft corrected the problem with January 31 updates to NT 4.0 kernel components ntkrnlmp.exe and ntoskrnl.exe. You can get the updates from Microsoft Support.

RAS NetBIOS name resolution problem. When testing remote clients, I’ve seen the infamous "System Error 53 has occurred" error message so often that it threatens to become my mantra. Microsoft Support Online article Q253502 documents yet another cause for this error: When a remote client attempts to resolve a NetBIOS name longer than 16 characters (e.g., when you issue a command such as Net view \longlongservername ). After a client connects, the service responsible for directing the resolution of NetBIOS server names longer than 16 characters doesn’t check the temporary Registry key that contains the DNS server’s address, so the service doesn’t send the name resolution request to the proper authority. The bug might also cause "server not found" or "server unavailable" messages to return any time a program on a remote client attempts to resolve a NetBIOS name longer than 16 characters. Microsoft corrected the problem with February 3 updates to NT components mswsock.dll and mnr20.dll, which you can get directly from Microsoft Support.

A Windows Installer problem. Here’s a cryptic Windows Installer problem that I’m sure occurs only under unusual circumstances (I’ve never seen it on any of my systems). Have you received the error message, "The Windows Installer service failed to start. Contact your support personnel" when installing an application? According to Microsoft Support Online article Q251274, this failure can occur when the value entry CLASSPATH:REG_EXPAND_SZ contains a null string in the Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerEnvironment. When I checked a couple of my NT 4.0 systems, I didn’t find the CLASSPATH value entry in the Environment key, which is why I think the problem is unusual. The article doesn’t identify the component that writes this entry or how it appears, but it does indicate that Microsoft released a January 18 version of userenv.dll that corrects the problem. As a temporary workaround, the article suggests that you delete the CLASSPATH value entry and try the installation again.