Win32k.sys Blue Screen
Windows NT has a sporadic synchronization problem that can crash the OS. If one of your systems has this problem, you’ll see a blue screen with Stop Code 0x0000001e in the module win32k.sys. Microsoft documents the crash in Microsoft Support Online article Q237955 (http://support.microsoft.com/ support/kb/articles/q237/9/55.asp) and offers a new win32k.sys that corrects the synchronization problem. The bug fix applies to all versions of NT and NT Server 4.0, Terminal Server Edition, independent of service pack level.
SP4 and SP5 Exchange and Outlook Client Hang
According to Microsoft Support Online article Q239132 (http://support.microsoft.com/support/kb/articles/q239/1/32.ASP), Exchange and Outlook clients hang periodically when accessing email over slow connections. Exchange Server’s remote procedure call (RPC) Receive Any Thread processes email requests from Exchange and Outlook clients. The RPC thread cannot complete its operation until it receives all datagrams associated with a specific client’s request, and during a slow connection, it must wait for the data to trickle in. This wait prevents the thread from responding to any other client requests, which in turn temporarily freezes the email clients. You can get the bug fix, an updated rpcltscm.dll for Service Pack 4 (SP4) and SP5 systems, from Microsoft Support.
SP4/SP5 RAS LPR Print Bug
According to Microsoft Support Online article Q237420 (http://support.microsoft.com/support/ kb/articles/q237/4/20.ASP), Microsoft modified the Line Printer Daemon (LPD) server in Service Pack 4 (SP4) to acquire the IP address of an LPR printer during print spooler initialization, presumably at system startup. When an LPR printer is on the far side of a RAS connection, the print spooler cannot obtain the IP address because the spooler initialization occurs before the RAS connection. Without the IP address, print requests to the remote LPR printer fail. When this occurs, you’ll see Event ID 4008 in the application log with this message text:
-
Printer \\
in the request from
request ignored
You can get the bug fix, a new localspl.dll for SP4 and SP5 systems, from Microsoft Support.
Monitoring Network Browser Wars
Have you ever wondered how many browser elections occur on your network, or which Windows NT or Windows 9x workstations force elections at startup or try to take over as master browser? Or perhaps you’ve wanted notification when new systems join the network and appear in the browse list? NT logs just one or two event records during a browser election, and the only other way to investigate browser haggling (e.g., broadcasts and challenges), has been to capture and decipher the traffic in Network Monitor. Well we now have an alternative—I found instructions on how to enable detailed browser monitoring in a new Microsoft Support Online article, Q234870 (http://support.microsoft.com/support/kb/articles/q234/8/70.asp).
Browser code is located in the file %systemroot%\system32\drivers\rdr.sys. To get detailed logging information, you replace the standard rdr.sys with the debug version (i.e., the checked build). The checked build is available with your MSDN subscription, but I’m not sure it’s available online—a search for the checked build at the Microsoft Technet Web site turned up nothing.
Remember that you can’t replace or rename a file that’s loaded and running. Because the redirector code automatically loads whenever you connect to a network, you might have to unplug your network adapter card and stop the browser service before you replace the file. Next, you need to add two Redirector Registry value entries that instruct the debug version of Rdr.sys to create and populate the log file.
The log file and the Registry value entries are Bowser (not Browser) so be careful when making these Registry edits. (I’m sure the choice of Bowser was deliberate—browser chatter can clog a network like the barking dogs that crash through your dreams in the night.) If you enable logging on a production system, you might want to make a Registry backup before you start. This procedure should work equally well on NT Server and NT Workstation.
Rename %systemroot%\system32\drivers\rdr.sys to rdr.bak.
Rename the debug version to rdr.sys.
Copy the debug version to %systemroot%\system32\drivers\rdr.sys.
Find the Registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr and add value entry BowserDebugLogLevel:REG_DWORD: ffffffff, then add value entry
BowserDebugTraceLevel:REG_DWORD: ffffffff
Reboot the machine to activate logging
Browser debug mode is a great diagnostic tool, especially during a network reorganization or for troubleshooting a persistent network problem. To disable logging, reverse the procedure above and replace the debug version with the standard version. I’m guessing that you can also keep the checked Rdr.sys and disable logging by changing the Bowser data "ffffffff" values to blanks. If this doesn’t work, try deleting both Bowser value entries. Enjoy!
Internet Information Server 4.0 FTP GET Bug
Here’s a fun bug in Microsoft Internet Information Server (IIS) 4.0. Suppose you create a virtual FTP directory, enable anonymous access to the virtual directory, and then create a Uniform Naming Convention (UNC) share for FTP access. When you FTP to the UNC name, you can PUT files, but an authentication error causes a GET operation to the same share to fail. During an anonymous PUT, the ftp service uses the credentials of the virtual directory. The GET command uses the credentials of the logged-on user, and this bug prevents anyone from downloading files. The workaround is to add an ACL to the UNC share that enables access for the Windows NT anonymous account. You can get the permanent fix, an updated Ftpsvc2.dll, from Microsoft Support. Microsoft documents this bug in Microsoft Support Online article Q237987 (http://support.microsoft.com/ support/kb/articles/q237/9/87.asp).
SSL Connection Requires Same Encryption at Both Ends
If you’re having trouble with Secure Sockets Layer (SSL) connections to Microsoft Internet Information Server (IIS) 4.0, you might have a mix of 40-bit and 128-bit session keys. When IIS is configured with 40-bit encryption and the client has 128-bit encryption, IIS creates a 40-bit key and the client creates a 128-bit key—and because they don’t match, the connection request generates an error. In this situation, Microsoft Internet Explorer (IE) returns the message
-
"Internet Explorer could not open the Internet site:
The data area passed to a system call is too small"
and Netscape Communicator simply stops responding. To correct the problem, install the 128-bit encrypted version of your current Windows NT service pack. See Microsoft Support Online article Q207523 (http://support.microsoft.com/support/ kb/articles/q207/5/23.asp) for more information about this encryption mismatch problem.
