Bug Fixes vs. Hotfixes
I write about bug fixes and hotfixes every week, but I don’t think I’ve ever discussed how I distinguish between them. I hope this description helps you understand when you need to call Microsoft Support and when you can download an update from Microsoft’s Web site. These definitions are my own, and not an official description from Microsoft.
A bug fix corrects an intermittent problem in a Windows NT component and in general, published bugs do not occur on all systems. Some bugs might appear only with a specific combination of services and protocols, a specific combination of hardware components, when the number of file or print shares exceeds a certain threshold, or when the account database contains a very large number of accounts or groups. Because the bugs are configuration-dependent and not pervasive, they can be difficult to isolate and diagnose correctly. To verify that you need a specific update (and to improve the odds that the bug fix will correct your problem), you have to call Microsoft Support. When the symptoms of your problem match those corrected by a bug fix, Microsoft Support gives you the updated code; this is why bug fixes for NT are seldom available for public download. When a bug fix is available, I’ll always include the download URL.
Hotfixes correct bugs that occur on a large number of systems. Hotfixes typically address problems related to security, performance, corruption, and fairly predictable system crashes. Because hotfixes address serious and pervasive system issues, Microsoft always posts them at the company’s FTP site for public download. When I document a new hotfix, I always verify the availability of the hotfix download and include the download URL.
Win32k.sys Blue Screen Update
On rare occasions, information about a bug fix or hotfix changes after I submit my column but before publication of UPDATE, which is exactly what happened with the Win32k blue screen I documented last week. Many readers checked the Web reference only to find that Microsoft Support did not have the updated win32k.sys ready for release.
I write up bug fixes and hotfixes based on articles posted at the Microsoft FTP site. Contrary to what Microsoft published in the original version of article Q237955 (http://support.microsoft.com/ support/kb/articles/q237/9/55.asp), the win32k.sys update was not available. Microsoft updated the support article to reflect this delay on August 17, 1999—the day we published this column. Because I don’t have a Microsoft Support contract, I can’t tell you when Microsoft will release the Win32k.sys update. If you get it, let me know and I’ll pass the information on to our community.
Disappearing RAS Ports
Do RAS ports disappear on your server? Microsoft Support Online article Q238171 (http://support.microsoft.com/support/ kb/articles/q238/1/71.asp) verifies that in some cases, ports disappear after a client disconnects, a problem that arises from a port status mismatch in two different RAS modules, rasman.exe and rassrv.exe. The free port never reinitializes—
it just disappears into the bit bucket. Microsoft has corrected the port disappearance in a new version of rassrv.exe, which you can get from Microsoft Support. This bug applies to all versions of Windows NT, independent of service-pack level.
Manually Assigning WINS and DNS Servers to RAS Clients
RAS assigns a TCP/IP address and its own WINS and DNS servers to incoming client connections. In some situations, you might want to assign different servers—for example, if you want to restrict how much of your network incoming clients can see or browse. A new posting describes three Registry modifications you can make to the incoming RAS adapter (e.g., NDISWAN1) to override the default WINS and DNS server assignments. Because the edits are long, I won’t reproduce them here. Instead, get the details directly from Microsoft Support Online article Q205247 (http://support.microsoft.com/ support/kb/articles/q205/2/47.asp).
Disabling CHAP Authentication in RRAS
RRAS is commercial-strength routing and remote access software, complete with packet filtering and PPTP. RRAS authenticates incoming client-to-server and router-to-router (or server-to-server) PPTP connections and also functions as a Remote Authentication Dial-In User Service (RADIUS) client for authentication purposes. When RRAS acts as a RADIUS client and receives a PPTP connection request from a non-Microsoft client, the request succeeds if the client supports the Challenge Handshake Authentication Protocol (CHAP). If the client does not support CHAP, incoming connection requests fail. Microsoft Support Online article Q238734 (http://support.microsoft.com/support/ kb/articles/q238/7/34.asp) documents this problem, which applies to all versions of Windows NT, independent of service-pack level.
You can permanently disable CHAP on an RRAS server with a Registry modification to work around the problem. Go to the path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\PPP\CHAP
and add the value entry OfferMSCHAP:DWORD:0x00000000. Although the article does not mention this, I’m pretty sure this control is not dynamic. To activate the change, you need to restart RRAS or reboot the server. The permanent solution is an updated raspppen.dll, available from Microsoft Support.
CSNW/GSNW Bug Fix
Microsoft Support Online article Q238380 (http://support.microsoft.com/ support/kb/articles/q238/3/80.asp) documents timing problems in the code for Client Services for NetWare (CSNW) and Gateway Services for NetWare (GSNW) that cause Windows NT to hang at shutdown. Microsoft has corrected the hang in a new version of nwrdr.sys, the NetWare redirector; call Microsoft Support for the bug fix. The article indicates that the bug fix may or may not correct the system hang, so you might want to wait for a couple of weeks.
