Bug Fixes and a Back Orifice 2000 Update

New bug fixes available from Microsoft Support and a method to check whether Back Orifice 2000 is installed on your system.

Paula Sharick

July 28, 1999

3 Min Read
ITPro Today logo in a gray background | ITPro Today

Graphics Device Interface Bug Fix
Two new postings document problems with programs that call Graphic Device Interface (GDI) functions. Because the GDI runs in kernel mode, bugs in this code can hang a system. Microsoft Support Online article Q237777 (http://support.microsoft.com/ support/kb/articles/ q237/7/77.asp) documents a serious GDI memory leak, including desktop objects and the desktop heap, which uses 3MB of pageable memory. When a leak this large occurs, Windows NT hangs. Article Q237780 (http://support.microsoft.com/ support/kb/ articles/q237/7/80.asp) documents another problem where a GDI function incorrectly calculates rectangular coordinates, but only when the monitor is in VGA mode. On April 28, Microsoft released a new version of win32k.sys that corrects both bugs. The bug fix applies to Service Pack 4 (SP4) and SP5. You must obtain the update from Microsoft Support.

Back Orifice 2000 Check Up
Cult of the Dead Cow recently released an updated version of Back Orifice 2000 (BO2K), and Microsoft Support Online article Q237280 (http://support.microsoft.com/ support/kb/articles/ q237/2/80.asp) tells you how to check whether a remote user has installed BO2K on your Windows NT or Windows 9x systems. The program itself is not dangerous, but it can let a remote user take control of a workstation or server for malicious purposes.

On Win9x systems, the checkup is straightforward. If the program is installed with all defaults, it creates an entry in the Registry path HKEY_LOCAL_MACHINE SOFTWAREMicrosoftWindows CurrentVersionRunService with the value "Umgr32.exe"="C:\Windows\ System\ Umgr32.exe e". Umgr32.exe is the name of the BO2K executable.

On NT systems, BO2K installs as a service with the default name of Remote Administration Service. The article cautions that a user can change the service name before installing the program, so the check is not foolproof.

Terminal Server Edition SP4 Profile and Home Directory Bugs
Have you recently upgraded a domain controller to Windows NT Terminal Server Edition Service Pack 4 (SP4)? Are you having problems with user profile directories? The symptoms for this problem are clear. When a user logs on to a Terminal Server domain controller running SP4, Terminal Server maps the profile directory and the home directory to the default location, even though you've entered a different path in the profile and home directory fields for that user's account.

SP4 changes the RestrictAnonymous value in the Registry from the default of 0 to 1. The RestrictAnonymous value entry appears in HKEY_LOCAL_MACHINE SYSTEM CurrentControlSetControlLSA. Two fixes exist for this problem. First, you can run Registry Editor and change the value back to 0, or you can delete the RestrictAnonymous value entry. This change might affect how users access Terminal Server, so be sure you read Microsoft Support Online article Q236185 (http://support.microsoft.com/ support/kb/ articles/q236/1/85.asp) and the additional references before you make the change.

Browser Bug Fix
For years, I’ve watched error messages from clients that can't log on to a Windows NT domain. According to Microsoft Support Online article Q235602 (http://support.microsoft.com/ support/kb/articles/ q235/6/02.asp), when clients try to log on, they might see any of four error messages, including the longstanding "RPC server is too busy to complete this operation." The logon failure can occur when bugs in the browser cause it to access an invalid memory location or corrupt a valid memory location. This browser bug can also cause an access violation on the client in services.exe. An updated browser.dll with a date of June 16, 1999, is available from Microsoft Support.

FTP Client Hang
If you’re running an FTP server on a slow network, the FTP client can hang if it doesn’t get a response from the server. Apparently, the Windows NT FTP client does not have a timeout value, and when the client doesn’t connect, it just waits indefinitely. I’ve seen this problem many times, and the workaround is to kill the client and start over. The bug fix adds a nonconfigurable timeout value of 270 seconds, which means the FTP client will exit gracefully if the software receives no response within this time period. Microsoft Support Online article Q235677 (http://support.microsoft.com/ support/kb/articles/ q235/6/77.asp) documents this problem, and you can obtain the updated ftp.exe from Microsoft Support.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like