Copyright: Copyright 1993 Microsoft Corp.
Citation: Copyright 1993 Microsoft Corporation. All rights reserved.


 Windows NT 3.51 U.S. Service Pack 2

Prepared 09/14/95

 README.TXT File

 Fixlist Knowledge Base Articles (Previously Included in SP 1)

 Fixlist Knowledge Base Articles (New in SP 2)

THE INFORMATION IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES EITHER EXPRESSED OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS, OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FORGOING EXCLUSION OR LIMITATION MAY NOT APPLY.Copyright (c) 1994 Microsoft Corporation.  All rights reserved.


README.TXT File
 Windows NT 3.51 U.S. Service Pack 2

 README.TXT File

 README.TXT: Windows NT Version 3.51 U.S. Service Pack

 Fixlist Knowledge Base Articles (Previously Included in SP 1)

 Fixlist Knowledge Base Articles (New in SP 2)


Fixlist Knowledge Base Articles (Previously Included in SP 1)
 Windows NT 3.51 U.S. Service Pack 2

 README.TXT File

 Fixlist Knowledge Base Articles (Previously Included in SP 1)

 Windows NT 3.51 Hangs (Memory Access Violation) Running Exchange

 Windows NT 3.51 Hangs with Office 95 (Word) Help File Wizard

 Err Msg: Incorrect Response from the Network

 Windows NT Win16 Subsystem Crashes Printing from Quicken 4.0

 TCP/IP Generates Frames with Loopback Address as Source Address

 "Invalid Page Fault" Running Office 95 Help Wizard

 Help File Opens Very Slowly with Office 95 Applications

 Help Fails for Visual Basic Modules in Microsoft Excel

 Middle Mouse Button Does Not Work Under Windows NT 3.51

 Problems Printing From DCA IRMA Workstation for NT 1.1

 STOP Msg: 0x0000000A or 0x0000001E When Using PING

 PowerStack with Cirrus Video Adapter Hangs During Startup

 Fixlist Knowledge Base Articles (New in SP 2)


Fixlist Knowledge Base Articles (New in SP 2)
 Windows NT 3.51 U.S. Service Pack 2

 README.TXT File

 Fixlist Knowledge Base Articles (Previously Included in SP 1)

 Fixlist Knowledge Base Articles (New in SP 2)

 UPDATE.EXE Starts Setup Help If Space Exists in Directory Path

 Landscape Orientation Reversed With Postscript Driver

 GSNW Not Releasing Session to NetWare Server

 Macintosh Client Has Slow Access to Windows NT 3.5x SFM Volume

 Banner Always Printed When Using GSNW Print Gateway

 STOP Msg: 0x0000003F NO_MORE_SYSTEMS_PTES Repetitive I/O on MIPS

 Desktop Remains Active At Logoff

 User Environment Variables Set Before Default Home Directory

 Datagram Sends Fail if Route is Not in IPX Cache

 FTPSVC Orphans Connections, Uses Up Virtual Memory

 DHCPADMN Reports Error 14 After You Select Local Machine

 Postscript Jobs Do Not Print Correctly Over SFM and AppleTalk

 Applications Hang When Opening Files when CSNW is Installed

 Streaming Mode NPMCA.SYS NIC Sleeps on Transmit.

 Windows NT 3.51 Hangs on Shutdown With Some S3 Based Video Cards

 Server Instability After Reboot Caused by NDIS Driver Problem

 FTP Client Scripts Terminate Without Completing

 Err Msg Using NetBIOS over TCP/IP (NETBT.SYS): STOP 0x0000000A

 NetWkstaSetUid2 API Returns Access Denied

 Printing From Windows NT 3.51 to an HP4 at 600 DPI is Slow

 Windows NT 3.51 GSNW Help Reports The File Is Corrupted

 FTPSVC: Delay Receiving FTP Directory Annotation and Prompt

 WINFILE.EXE Application Error When Associating a Searched File

 Maximum Disk Space of 1.99 GB Displayed for NetWare Volume

 Event ID 2019: Nonpaged Memory Pool Empty

 The Breakpoint "{,<filename>,} .<line>" Cannot Be Set

 LPR Printing Fails After Setting Up Security

 Forward Slash May Be Ignored As A Path Delimiter In 3.51

 Performance Monitor SQLServer-Log Object Corrupted

 No Compaq Netflex Drivers in Windows NT 3.51 for RISC Platforms

 STOP Msg: 0x0000007B or "0x4,0,0,0 Error" in WinNT 3.51 Setup

 Windows NT 3.51 LsarLookupSids errors from Big Endian Servers

 Computers Using QVision Display Driver Lock Up

 Dr. Watson Access Violation Occurs Sending Mail Attachments

 Uninitialized Pointers in DHCPSSVC.DLL Cause Access Violation

 Unknown Software Exception When Application Calls OpenGL

 Cannot copy Icons From a Common Group to a Personal Group

 NetWare Connections Remain Connected After You Log

 Faxing from 16-bit Program Using Separate Memory Space Fails

 Browsing & Other Traffic Incur High Costs over ISDN Routers

 Access Violation in glsbCreateAndDuplicateSection API on PowerPC

 Windows NT 3.51 Hangs on Shutdown

 Windows NT Backup : Incorrect Date in "Tape Name" Text

 WINS Records of Multi-homed Computers Do Not Replicate

 Print Manager: Owner Appears as System Printing from Macintosh

 Disk Administrator Corrupts Partitions

 Cannot Reconnect to OS/2 Name Space Resources on NetWare Server

 PIF Editor Reserve Shortcut Keys Settings May Be Ineffective

 IOCTL_NDIS_QUERY_ALL_STATS Causes STOP Msg in Windows NT 3.51

 NetWare Transaction Tracking System (TTS) Not Detected

 STOP 1E When Using File Manager and Services for Macintosh (SFM)

 "List Name From" List Box Shows Only 20 Trusted Domains

 Deleted Disk Space Not Released on Converted NTFS Volume

 Performance Monitor Counters Produce Unlikely Results

 Unable to Connect Using Cabletron EISA F70XX FDDI NIC

 RIP Table Does Not Update When New RIPX Response Is Received

 Batch Files Stop Executing with Windows NT version 3.51

 Tape Hardware Data Compression Disabled After Running NTBackup

 Access Violation in LSASS.EXE During User Password Change

 Windows NT Fails Because of an Access Violation in WINLOGON

 NTFS directory corruption with more than 100,000 files

 IniFileMapping for 16-Bit Windows Apps Fail in Windows NT 3.51

 NE3200 NIC Driver Can Lose Locally Administered Address

 Layered Drivers Never See WINSOCK IRPs for the TCP/IP Device

 WinFax Pro Software Causes 16-bit Applications To Hang

 Unable To Connect To AT&T Advanced Server For UNIX Printer Share


README.TXT: Windows NT Version 3.51 U.S. Service Pack

Article ID: Q128531

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

Following is the README.TXT file that accompanies the Microsoft Windows

NT 3.51 Workstation and Server U.S. Service Pack 2:

---------------------------------------------------------------------------

              Microsoft Windows NT 3.51 Workstation and Server

                            U.S. Service Pack 2

---------------------------------------------------------------------------

Contents

--------

1.0  Introduction

2.0  Installation Instructions for the Windows NT 3.5 U.S. Service Pack 2

2.1  User Notes

2.2  List of Bugs Fixed in Windows NT 3.51 U.S. Service Pack 2

1.0  Introduction

-----------------

This release of Microsoft(R) Windows NT(TM) 3.51 U.S. Service Pack 2 is

easy to apply from within Windows NT and changes only those files that

were originally set up on the Windows NT Workstation or Windows NT Server

system.  Service Pack releases are cumulative: they contain all previous

fixes, as well as any new fixes made to the system.

2.0  Installation Instructions for the Windows NT U.S. Service Pack

-------------------------------------------------------------------

Installing the Service Pack from a floppy disk:

1.  Insert Service Pack Disk 1 into the floppy drive.

2.  At the Windows NT Command Prompt, change to that floppy drive (that is,

    A: or B:) and type UPDATE.

3.  Follow the instructions given on the screen.

Installing the Service Pack from a CD-ROM:

1.  Insert the Service Pack CD-ROM disk into the CD-ROM drive.

2.  At the Windows NT Command Prompt, change to that CD-ROM drive, then

    change to the i386, MIPS, or ALPHA directory (depending upon whether

    you have an Intel(TM), MIPS(R), or ALPHA AXP(TM) CPU), and type UPDATE.

3.  Follow the instructions given on the screen.

Installing the Service Pack from a network drive:

1.  At the Windows NT Command Prompt, type the command to connect to the

    network drive on which the Service Pack files reside.

2.  Change to that network drive and type UPDATE.

3.  Follow the instructions given on the screen.

2.1  User Notes

---------------

*** New ROUTE.EXE Command Line Argument

A new command line argument for ROUTE.EXE has been added in Service Pack 2.

The new parameter is METRIC, and is described below:

ROUTE [-f] [command [destination] [MASK netmask] [gateway] [METRIC metric]]

METRIC

   The metric option is used to associate a cost/hop count for the

   destination specified by the route entry. Generally this specifies the

   distance in number of hops from the destination. If not specified, the

   metric is set to 1 by default.

*** Emergency Repair Disk

If it is necessary to use the Windows NT Emergency Repair Disk to repair

your Windows NT system at some time after you apply the Service Pack, you

will need to re-apply the Service Pack after the repair is completed.  This

is because the Emergency Repair Disk repairs your system by restoring your

original Windows NT setup.  After the repair has completed, simply follow

the above Installation Instructions to reapply the Service Pack.

*** Adding New Components to the System

If new software or hardware components are changed or added to your system

after you have applied the Service Pack, it will be necessary to reapply

the Service Pack.  This is because the files taken from the original

Windows NT disk set may not be equivalent to the files on the Service Pack

disk set.  It is not possible to install new components directly from the

Service Pack media (such as a new keyboard or printer driver).  New

components must be installed from the original product media.

*** Installing Symbol Files from the CD-ROM

To install the symbol files corresponding to the new binaries in Service

Pack 2, do the following (assuming your CD-ROM drive is D:, your symbol

files are located in the C:\WINNT\SYMBOLS directory, and you are installing

the files for an x86 machine):

    XCOPY /S /U /D D:\SUPPORT\DEBUG\I386\SYMBOLS C:\WINNT\SYMBOLS

This will copy the Service Pack 2 .DBG files over the existing versions of

these files.  The XCOPY command shown will copy only those .DBG files that

are already installed (/U switch), and only those with a more recent time-

date stamp (/D switch).

2.2  List of Bugs Fixed in Windows NT 3.5 U.S. Service Pack 2

-------------------------------------------------------------

NOTE: Use the Qxxxxxx number that precedes the title of the bug fix to

query the Microsoft Knowledge Base to find an article about that bug.

KBCategory: kbreadme kbfixlist3.51.sp1

KBSubcategory: ntdistrib

Additional reference words: prodnt 3.51 servpack sp1 bug fix qfe compac

disc


Windows NT 3.51 Hangs (Memory Access Violation) Running Exchange

Article ID: Q128453

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

While running Microsoft Exchange, Windows NT 3.51 stops responding (hangs).

Program Manager may disappear and the Task List may be inaccessible.

CAUSE

=====

Windows NT causes a memory access violation.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntgeneral

Additional reference words: 3.51 prodnt


Windows NT 3.51 Hangs with Office 95 (Word) Help File Wizard

Article ID: Q128454

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you run Microsoft Word for Windows 95 (from Microsoft Office for

Windows 95) on Windows NT 3.51 and open the help file wizard (Winhlp32),

Windows NT stops responding (hangs).

CAUSE

=====

Windows NT causes a memory access violation.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbinterop kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntgeneral

Additional reference words: 3.51 prodnt


Err Msg: Incorrect Response from the Network

Article ID: Q130093

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

The following error message appears:

   Incorrect Response from the Network

This error message can occur when you run NetBench version 3.0 under

Windows NT with Windows NT file system (NTFS) file compression enabled.

CAUSE

=====

The Windows NT client receiving this error message timed out during an MPX

write request.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

NOTE: If the Windows NT Server's CPU usage is at 100% direct host IPX

clients may experience unreliable service and should therefore switch to a

connection oriented protocol like NetBEUI or TCP/IP, etc.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntnetserv ntprotocol

Additional reference words: 3.51 prodnt net bench


Windows NT Win16 Subsystem Crashes Printing from Quicken 4.0

Article ID: Q130292

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

On MIPS computers, the Windows NT subsystem for 16-bit MS-DOS or Windows

3.1 applications terminates when you print from Quicken version 4.0 to a

local postscript printer. This problem usually occurs when a macro executes

the print command from Quicken at computer speed; it is unlikely to occur

if you execute the print command manually.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kb3rdparty kbprint kbbug3.51 kbfix3.51.sp1

KBSubcategory: nt16ap ntprint

Additional reference words: 3.51 prodnt


TCP/IP Generates Frames with Loopback Address as Source Address

Article ID: Q130677

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

TCP/IP generates echo frames with the loopback address (127.0.0.1) as the

source address.

CAUSE

=====

You sent an echo request with the host's network media access control (MAC)

address and the TCP/IP loopback address as the destination address.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntprotocol nttcp

Additional reference words: 3.51 prodnt


"Invalid Page Fault" Running Office 95 Help Wizard

Article ID: Q131343

--------------------------------------------------------------------------

The information in this article applies to:

  - Microsoft Windows NT Workstation version 3.51

  - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you install Office 95 under Windows NT 3.51, start help from one of

the Office applications, start the application, and then choose an "Answer

Wizard" from the Help menu, the help menu may disappear or appear as an

incomplete dialog box. If the Find tab button is blank and you attempt to

use this function, the following error appears:

   WINHLP32 caused an invalid page fault in module WINHLP32.EXE at

   0137:00401CF5.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

    S E R V P A C K

KBCategory: kbtool kberrmsg kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntutil

Additional reference words: 3.51 prodnt


Help File Opens Very Slowly with Office 95 Applications

Article ID: Q131683

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

After you install Office 95 under Windows NT 3.51, it takes up to fifteen

minutes to start Help from Office applications.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

    S E R V P A C K

KBCategory: kbinterop kbtool kbbug3.51 kbfix3.51.sp1

KBSubcategory: nt32ap

Additional reference words: 3.51 prodnt


Help Fails for Visual Basic Modules in Microsoft Excel

Article ID: Q131779

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

After you open a Visual Basic for Applications module in Microsoft Excel,

you lose the use of context sensitive help for keywords such as "worksheet"

and "window."

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

    S E R V P A C K

KBCategory: kbtool kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntutil

Additional reference words: 3.51 prodnt


Middle Mouse Button Does Not Work Under Windows NT 3.51

Article ID: Q132198

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you use the "Microsoft Mouse Port Mouse (includes Ballpoint)" mouse

driver with a three button mouse on a Intergraph computer running Windows

NT 3.51, the middle mouse button doesn't work.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbhw kb3rdparty kbbug3.51 kbfix3.51.sp1

KBSubcategory: nthw ntdriver

Additional reference words: 3.51 prodnt ball point


Problems Printing From DCA IRMA Workstation for NT 1.1

Article ID: Q132466

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you run DCA IRMA Workstation for NT 1.1 and then select File, Print,

and Screen Print, the following error appears and DCA IRMA terminates:

   Standard: EMU.EXE -Application Error

   The instruction at 0x77f76eb9 referenced memory at 0x00000008. The

   memory could not be "read".

This problem does not occur under Windows NT 3.5, nor does it occur with

earlier versions of DCA IRMA Workstation.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

DCA IRMA Workstation for NT is manufactured by DCA, a vendor independent of

Microsoft; we make no warranty, implied or otherwise, regarding this

product's performance or reliability.

KBCategory: kbprint kb3rdparty kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntprint

Additional reference words: 3.50 3.51 prodnt 1.1.0 3270 emulator window

quit exit


STOP Msg: 0x0000000A or 0x0000001E When Using PING

Article ID: Q132470

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you use PING similar to "PING -l 65527 -s 1 <target computer>"

(without quotes) in Windows NT 3.51, the target computer stops responding

(hangs) and one of the following STOP messages may appear on your computer:

   STOP: 0X0000001E

   KMODE_EXCEPTION_NOT_HANDLED - TCPIP.SYS

   -OR-

   STOP: 0x0000000A

   IRQL_NOT_LESS_OR_EQUAL - TCPIP.SYS

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntstop nttcp

Additional reference words: 3.51 prodnt


PowerStack with Cirrus Video Adapter Hangs During Startup

Article ID: Q132858

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

After you install Windows NT 3.51 on a Motorola PowerStack computer that

has 16 megabytes (MB) of memory and a Cirrus video adapter, Windows NT 3.51

stops responding (hangs) during startup.

CAUSE

=====

This problem occurs due to low system memory. The Cirrus miniport driver

maps 16 MB of virtual memory (frame buffer) during startup and does not

release it.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbsetup kbbug3.51 kbfix3.51.sp1

KBSubcategory: ntboot

Additional reference words: 3.51 prodnt power stack mini port


UPDATE.EXE Starts Setup Help If Space Exists in Directory Path

Article ID: Q112665

------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT operating system version 3.1

 - Microsoft Windows NT Advanced Server version 3.1

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

------------------------------------------------------------------------

SUMMARY

=======

If you run UPDATE.EXE (from any Service Pack) in a directory in which the

complete path name includes a space or long directory name, instead of

running UPDATE.EXE, a screen explaining the SETUP.EXE command-line options

appears.

MORE INFORMATION

================

When you run UPDATE.EXE, it calls Windows NT SETUP.EXE with some command-

line parameters. If a space exists in the directory name or the directory

name is a long directory name, the Setup screen titled "Usage" (which

explains the Microsoft Setup command-line options) appears. SETUP.EXE

does not parse the command line properly if a space exists in the directory

name of the parameters passed to it. For example, if you have a directory

called "C:\FILES\NT FILES\SPACK" or "C:\FILES\NTFILESFORSPACK\SPACK", and

you place the update files in the SPACK directory and then run UPDATE.EXE,

you receive the above error.

RESOLUTION

==========

Move the Service Pack files to a directory path that does not include a

space or long directory name.

STATUS

======

Microsoft has confirmed this to be a problem in the Service Packs for

Windows NT versions 3.1 and 3.5 and Windows NT Service Pack 1.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbusage kbbug3.10 kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral

Additional reference words: prodnt 3.10 3.50 CSD ldn lfn file


Landscape Orientation Reversed With Postscript Driver

Article ID: Q128567

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you print a page in landscape orientation with a PostScript driver

under Windows NT 3.5 or 3.51, the text is in the opposite corner of where

the landscape text is when printing with a Windows NT PCL driver. This is

not consistent with the Windows 95, Windows, Windows for Workgroups, or the

Windows NT 3.1 PostScript drivers.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbprint kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint

Additional reference words: 3.50 3.51 prodnt


GSNW Not Releasing Session to NetWare Server

Article ID: Q129670

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Gateway Service for NetWare (GSNW) and Client Services for NetWare (CSNW)

allow Windows NT to initiate and terminate a session with a NetWare server.

When you stop the CSNW or CSNW service in the Services section of Control

Panel or shutdown the system, the session to the NetWare service is not

released.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop ntnetserv

Additional reference words: prodnt 3.50 3.51 connection


Macintosh Client Has Slow Access to Windows NT 3.5x SFM Volume

Article ID: Q129724

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

When Services for Macintosh (SFM) is installed on a Windows NT 3.5 Server,

Macintosh clients periodically appear to stop responding, even if they are

not directly accessing a mounted volume (the client is waiting for a

response from the Windows NT server). The amount of time that a client

waits for a response from the server depends on the volume layout and how

many files are in each directory.

CAUSE

=====

When a shared directory is initially accessed by a Macintosh client, SFM

must read the entire contents of the directory and update the sub-section

of the volume catalog. If there are many files in the directory (several

thousand), the volume is exclusively locked until the catalog is updated.

This causes other Macintosh clients to wait for their requests to be

satisfied.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

Microsoft has modified the Windows NT version 3.51 file, SFMSRV.SYS, to

correct these problems. SFM Servers configured with large Macintosh

Accessible Volumes will still have large amounts of disk activity when the

server starts or when a volume is created. This may go on for several

minutes depending on how  large and complex directory structures are.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntmac

Additional reference words: 3.50 3.51 prodnt


Banner Always Printed When Using GSNW Print Gateway

Article ID: Q130226

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

If you print from a computer running Windows NT 3.5x to a NetWare Print

Gateway defined on a computer running Windows NT 3.5x Server and Microsoft

Gateway Service for NetWare (GSNW), you always receive a NetWare banner

page before the print job.

The banner page is printed even if you clear the Print Banner check box in

the GSNW options on the computer running Windows NT 3.5x Server. Disabling

the banner option in the print queue configuration using the NetWare

PrintCon utility does not prevent the banner from being printed.

If you print directly from the computer running Windows NT Server and GSNW,

a banner is not printed. If you print to the same computer running Windows

NT 3.5x Server and GSNW from a computer running Windows for Workgroups 3.11

a banner is not printed.

NOTE: This issue is most problematic when the printer on the NetWare print

server is a postscript printer because NetWare is unable to generate

postscript code for the banner.

RESOLUTION

==========

To work around this problem, install Client Services for NetWare (CSNW) on

the Windows NT Workstation so that you do not have to print through the

print gateway on the Windows NT server running GSNW. Using CSNW will allow

you to directly connect to the NetWare print queue. You can disable banners

by running Control Panel and choosing CSNW.

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbprint kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint ntnetserv

Additional reference words: prodnt 3.50 3.51 ipx nwlink novell print con


STOP Msg: 0x0000003F NO_MORE_SYSTEMS_PTES Repetitive I/O on MIPS

Article ID: Q130783

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you perform repetitive reads and writes to your floppy disk on a MIPS

computer, the STOP Message appears:

   STOP: 0x0000003F 0x00000000,0x00000000,0x00000000,0x00000000)

   NO_MORE_SYSTEMS_PTES

CAUSE

=====

During repetitive floppy disk I/O, the Memory Descriptor List (MDL) becomes

corrupted and supplies erroneous information leading Windows NT to believe

that no more Page Table Entries (PTES) exist.

NOTE: You can observe the decrease in PTES on the system during the floppy

disk I/O by monitoring the counter "Free System Page Table Entries" for the

Memory object in Performance Monitor.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntstop

Additional reference words: prodnt 3.50 3.51 nec express risc server r96


Desktop Remains Active At Logoff

Article ID: Q130932

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.5

 - Microsoft Windows NT Server version 3.5

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you lock your local workstation using CTRL+ALT+DEL, and then an

administrator logs you off of that machine locally (using CTRL+ALT+DEL),

the desktop becomes active for approx. 5-10 seconds (depending on what

processes are active, etc.). During this time, the administrator can see

the desktop, any open files, and can even manipulate objects on the

desktop.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Microsoft Windows NT

versions 3.5 and 3.51. This problem has been corrected in the latest U.S.

Service Pack for Windows NT version 3.51. For information on obtaining the

Service Pack, query on the following word in the Microsoft Knowledge Base

(without the spaces):

   S E R V P A C K

KBCategory: kbui kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntsecurity

Additional reference words: 3.50 3.51 security prodnt log off


User Environment Variables Set Before Default Home Directory

Article ID: Q130979

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you do not have a home directory defined for your account in User

Manager for Domains and you log on, Windows NT incorrectly sets your user

environment variables before the default home directory environment

variable is set.

However, if you have a home directory defined in User Manager for Domains

and you log on, Windows NT correctly sets your home directory environment

variable before your user environment variables.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral ntconfig

Additional reference words: prodnt 3.51


Datagram Sends Fail if Route is Not in IPX Cache

Article ID: Q131073

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOM

=======

If your transport driver interface (TDI) program is a client of the IPX

protocol and uses datagram-sends for connectionless sends at an interval

that is greater than 15 minutes, it fails. If the interval is shorter than

15 minutes, your TDI client performance is slowed down.

This symptom occurs if your TDI client program is a socket program using

datagram-sends, the NetWare redirector, or the Server Message Block (SMB)

redirector or server.

The problem does not occur with the SPX or NetBEUI protocol, or their TDI

clients. The RIP protocol is also not affected by this problem.

CAUSE

=====

When your transport driver interface (TDI) client does a send to a

destination whose route is not in the IPX cache, IPX sends a corrupted

packet in form of some superfluous bytes appended to the IPX header. The

next time the client sends the datagram, assuming it is within 15 minutes

which is the default routing information protocol (RIP) time-out, it

succeeds.

If a send happens after 15 minutes, then assuming that the route did not

get cached again, the send fails. A subsequent send succeeds.

This pattern repeats itself with each datagram send in these intervals.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprotocol

Additional reference words: prodnt 3.51


FTPSVC Orphans Connections, Uses Up Virtual Memory

Article ID: Q131241

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Symptoms may include dropping ftp users, "Not enough storage to process

this command" error message, growing page file, and other signs of virtual

memory exhaustion.

CAUSE

=====

FTPSVC may experience internal difficulties and start "orphaning" ftp

users. As the list of open resources expands, virtual memory is exhausted.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

Microsoft corrected this problem with the modified file, FTPSVC.DLL. This

fix was tested on ftp.microsoft.com, which performs over 50,000 anonymous

ftp logons per day.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv nttcp

Additional reference words: prodnt 3.51


DHCPADMN Reports Error 14 After You Select Local Machine

Article ID: Q131428

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

 ----------------------------------------------------------------------

SYMPTOMS

========

When you run DHCP Manager and select Local Machine to obtain a list of

scopes on the local DHCP Server, the following error message appears:

   Error 14: Not enough storage available to process this request

   Unable to connect to "Local Machine". Do you want to remove it from

   the list of DHCP servers?

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: prodnt 3.50 3.51


Postscript Jobs Do Not Print Correctly Over SFM and AppleTalk

Article ID: Q131689

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server version 3.5

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

Postscript print jobs sent to shared AppleTalk printers through Services

for Macintosh (SFM) may not print correctly, or may not get printed.

CAUSE

=====

The Services for Macintosh printer monitor incorrectly removes Postscript

printer reset characters (0x04) from the end of each print buffer when it

sends print data to a shared AppleTalk printer. Both valid printer resets

and 0x04 occurrences in binary-encoded data are removed. This keep valid

printer resets from executing, and corrupts binary data streams, preventing

the job from printing correctly.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv ntmac

Additional reference words: 3.50 3.51 prodnt


Applications Hang When Opening Files when CSNW is Installed

Article ID: Q132085

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you run Windows NT 3.5 or 3.51, start Client Services for NetWare

(CSNW), and run an application that opens files on the network, the

application may stop responding (hang). Also, if a drive is redirected to

point to the local drive, and the application opens files on the redirected

drive, the application may hang. For example, if you use SUBST to redirect

the C:\TEST directory to drive Z:, the application may hang when it opens

files on drive Z. Once the problem occurs, any NET USE command will also

hang.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: 3.50 3.51 prodnt


Streaming Mode NPMCA.SYS NIC Sleeps on Transmit.

Article ID: Q132394

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.5 and 3.51

 - Microsoft Windows NT Server version 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Under heavy stress situations a WinNT Server with a Network Peripherals

Inc. FDDI NIC (NPMCA.SYS) disappears from the network. Performing a

NET VIEW \\<Server_Name> command returns Error 53, "Name not found."

Existing connections and applications return errors.

CAUSE

=====

When set for "Streaming Mode" the Network Peripherals FDDI NIC goes to

sleep under heavy stress. Packets are indicated to the transport and the

transport submits packets to the NIC (NPMCA.SYS) but the NIC does not put

the packet on the network.

A Network General Sniffer trace during the sleep shows retry traffic to the

target, but no responses.

When you set the card to "Normal Mode", it does not exhibit this behavior.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

Network Peripherals Inc. provided Microsoft with the fix.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kb3rdparty kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdriver

Additional reference words: 3.50 3.51 prodnt


Windows NT 3.51 Hangs on Shutdown With Some S3 Based Video Cards

Article ID: Q132511

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Windows NT fails to shutdown correctly on some computers have video cards

with an S3 chipset.

RESOLUTION

==========

To work around this problem, start Windows NT in VGA mode.

To correct this problem, install the latest U.S. Service Pack for

Windows NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kb3rdparty kbhw kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdriver nthw

Additional reference words: 3.51 video s3 hang restart prodnt


Server Instability After Reboot Caused by NDIS Driver Problem

Article ID: Q132722

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Computers running Windows NT (especially multiprocessor computers) may stop

responding (hang) or display a STOP message, within a few minutes of the

Windows NT startup sequence after being rebooted.

CAUSE

=====

There is a problem is NDIS.SYS that causes Windows NT to attempt to close a

Windows NT file handle twice when NdisOpenFile and NdisCloseFile are

called. Closing a handle a second time causes undefined results. If the

handle being closed a second time is in use by another driver, the results

are unpredictable, but may include a system hang or STOP message.

The following network card drivers make calls to the NdisOpenFile and

NdisCloseFile APIs, and therefore may indirectly cause the symptoms

mentioned above.

   ANDTOK.SYS

   F30N3.SYS

   F70N3.SYS

   IRMATRAC.SYS

   NCRTOK.SYS

   MDGMPORT.SYS

   NE3200.SYS

   NETFLX.SYS

   PCIMAC.SYS

   PRONET16.SYS

   TCTOKNT.SYS

   UBNEI.SYS

NOTE: The problem is in NDIS, not in these drivers. They are listed here to

help identify systems that may exhibit the symptoms mentioned above.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

NDIS.SYS was corrected to close the Windows NT file handle only once.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdriver ntstop

Additional reference words: 3.50 3.51 prodnt blue screen trap


FTP Client Scripts Terminate Without Completing

Article ID: Q132896

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.5 and 3.51

 - Microsoft Windows NT Server version 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

FTP Client scripts appear to terminate early without performing any

work.

CAUSE

=====

The Windows NT FTP client (FTP.EXE) script handler does not wait for a

final response before issuing additional commands when a command is

responded to by multiple Multi-Line Responses ("xyz-"). Per RFC959, Multi-

Line Responses should be bracketed by prefixing only the first and last

line with "xyz-" and "xyz<SP>" respectively. The script handler buffers the

multiple "xys-" responses to satisfy its requests until it receives a QUIT

(which terminates the session).

RESOLUTION

==========

To correct this problem, install the fix mentioned below. The FTP Client

was enhanced to accept multiple Multi-Line Responses.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: nttcp

Additional reference words: 3.50 3.51 prodnt


Err Msg Using NetBIOS over TCP/IP (NETBT.SYS): STOP 0x0000000A

Article ID: Q132903

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

When you use the NetBIOS over TCP/IP transport (NETBT.SYS) in Windows NT

3.5 or 3.51, the following error message appears:

   STOP: 0x0000000A

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: nttcp ntstop

Additional reference words: prodnt 3.50 3.51 trap 0x0a 0xa blue screen


NetWkstaSetUid2 API Returns Access Denied

Article ID: Q133112

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you run a batch file that repeatedly logs a user on and logs using the

NetWkstaSetUid2 API, you may receive "Access Denied" error messages.

NOTE: The error message that is returned depends on the application that is

calling the NetWkstaSetUid2 API.

CAUSE

=====

NetWkstaSetUID2 performs the following three distinct operations:

1. Discovery. A mailslot message is sent to all the domain controllers

   (DCs) in a domain. Each DC responds with a message indicating whether

   the user account exists on the DC, and contains the name of the DC

   responding. The client looks at the first response and ignores the

   others.

2. Authentication. To authenticate the password, the client calls NetUseAdd

   IPC$ to contact the first DC that responded.

3. Account Information. A remote API call is used to retrieve account

   information to determine if you are an administrator, your password

   expiration date, and so on.

The problem listed above occurs when the third operation fails.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdomain

Additional reference words: prodnt 3.51 netlogon.dll


Printing From Windows NT 3.51 to an HP4 at 600 DPI is Slow

Article ID: Q133128

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Printing a document from any application can be much slower in Windows NT

3.51 than it is in Windows NT 3.5, when printing to an HP4 printer at 600

dots per inch (DPI). Spool files may be ten times larger under NT 3.51

than they were under 3.5.

CAUSE

=====

The text is being printed as a graphic even though that option is not

selected in the driver.

To work around this problem, set the printer to 300 DPI.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbprint kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint

Additional reference words: 3.51 prodnt kbbug3.51 kbfix3.51.sp2 HP4p 4p


Windows NT 3.51 GSNW Help Reports The File Is Corrupted

Article ID: Q133252

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

After you install the Gateway Service for NetWare (GSNW) in Windows NT

3.51 and choose Help in Control Panel GSNW, the following error message

appears:

   The <drive>:\%SystemRoot%\system32\nwdoc.hlp file is not a Windows

   Help file, or the file is corrupted.

CAUSE

=====

The GSNW Setup does not correctly copy the help file to the

%SYSTEMROOT%\SYSTEM32 directory. The NWDOC.HLP in that directory is only

111 bytes.

WORKAROUND

==========

To work around this problem, manually expand NWDOCGW.HL_ from the Windows

NT Server compact disc (CD) to the %SYSTEMROOT%\SYSTEM32 directory as

NWDOC.HLP.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbtool kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntutil

Additional reference words: prodnt 3.51 nwc


FTPSVC: Delay Receiving FTP Directory Annotation and Prompt

Article ID: Q133280

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you logon to a very busy Windows NT 3.51 ftp server, you experience a

delay receiving the directory annotation and ftp prompt (after you enter

your password).

Network Performance Monitor (PERFMON.EXE) shows the number of ftp server

current connections increasing, but the number of anonymous users logged on

decreasing. The system normally recovers within a few minutes.

CAUSE

=====

The FTP service was modified for Windows NT version 3.51 to provide

directory annotation of the ftp root directory at logon. The calls used to

do this annotation involved unnecessary file locking, especially when no

~ftpsvc~.ckm (directory annotation) file existed in the ftp root directory.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

Microsoft corrected this problem in the modified file, FTPSVC.DLL. This fix

improves logon performance by optimizing the directory annotation code so

it does less file locking.

NOTE: This fix was tested on ftp.microsoft.com, which performs over 50,000

anonymous ftp logons per day.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv nttcp

Additional reference words: 3.51 prodnt log on ons


WINFILE.EXE Application Error When Associating a Searched File

Article ID: Q133303

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

After the Search option in Windows NT 3.51 File Manager finds a requested

file and you attempt to associate the file with an application, one of the

following error messages appear:

   WINFILE.EXE - Application Error

   The instruction at "<Hex Memory Address>" referenced memory

   at "<Hex Memory Address>". The memory could not be "written".

   -or-

   An application error has occurred and an application error log

   is being generated.

   WINFILE.exe

   Exception: access violation (<Hex Memory Address>),

   Address: <Hex Memory Address>

When you choose either OK or CANCEL from either error message dialog box,

File Manager exits.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbtool kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntutil

Additional reference words: prodnt 3.51


Maximum Disk Space of 1.99 GB Displayed for NetWare Volume

Article ID: Q133306

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

When you connect to a NetWare 3.11 server through Gateway Service for

NetWare (GSNW) or Client Service for NetWare (CSNW), and the server has a

partition larger than two gigabytes (GB), the maximum available or total

disk space displayed in Windows NT 3.51 File Manager is 1.99 GB.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop ntnetserv

Additional reference words: prodnt 3.51 winfile fpnw


Event ID 2019: Nonpaged Memory Pool Empty

Article ID: Q133384

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you run a TCP/IP sockets based program on a Windows NT computer a non-

paged pool memory leak occurs. When the memory leak occurs for a while it

causes Windows NT to malfunction and the following out of memory error

appears in the system log:

   Event ID 2019

   Description:

   The server was unable to allocate from the system

   nonpaged pool because the pool was empty.

To determine that there is a memory leak:

1. Run Performance Monitor.

2. From the Edit menu, choose Add To Chart.

3. In the Object field, select Memory.

4. In the Counter field:

   a. Select Pool Nonpaged Bytes and choose Add.

   b. Select Pool Paged Bytes and choose Add.

5. Choose Done and watch Performance Monitor in Chart view mode.

   If the Nonpaged value rises rapidly while the TCP/IP sockets program is

   running then you may be experiencing this problem.

Example configurations under which this problem may occur:

 - Systems Management Server needs to communicate with an SQL server.

 - A SQL default client is configured for sockets - not Named Pipes.

 - TCP/IP is installed on the server, but SQL Server is not set up to use

   it. SQL Server is designed to use Named Pipes only.

 - Systems Management Server uses the default SQL client configuration for

   sockets.

 - Systems Management Server attempts to access SQL using sockets

   repeatedly.

CAUSE

=====

This problem can be caused by a TCP/IP sockets program that continuously

attempts to open a socket port that does not exist.

RESOLUTION

==========

To work around this problem, correct your TCP/IP sockets program so that it

does not attempt to open the unsupported socket port.

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: nttcp

Additional reference words: prodnt 3.51 tcp udp ip pmon perfmon listen bind


The Breakpoint "{,<filename>,} .<line>" Cannot Be Set

Article ID: Q133410

---------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

 - Microsoft Visual C++, 32-bit Edition, versions 2.0, 2.1, 2.2

---------------------------------------------------------------------

SYMPTOMS

========

When debugging projects located on a Novell Netware server from Windows NT

version 3.51, you can receive this error:

   The breakpoint "{,<filename>,} .<line>" cannot be set.

CAUSE

=====

There is a problem in NWRDR.SYS. The file read modes are not set correctly.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kb3rdparty kberrmsg kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral VWBIss

Additional reference words: 2.00 2.10 2.20 3.51 prodnt


LPR Printing Fails After Setting Up Security

Article ID: Q133488

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

A temp file is created in the %SYSTEMROOT%\SYSTEM32 subdirectory when your

print using the LPR monitor. This requires all users of this print share to

have read, write, delete privileges to this share. If security is applied

to the %SYSTEMROOT%\SYSTEM32 directory revoking the required permissions,

then printing via LPR fails.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbprint kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint

Additional reference words: 3.50 prodnt


Forward Slash May Be Ignored As A Path Delimiter In 3.51

Article ID: Q133701

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

Functions like stat() may fail when a forward slash is used as a path

delimiter.

CAUSE

=====

Windows NT 3.51 ignores the '/' as a path delimiter when the ExpandDosPath

function is called.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51. A fix was made to ExpandDosPath(PSTR pszPathGiven) in

WKFILEIO.C to pass over the path name string first and convert any "/"

characters to "\".

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbprg kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral

Additional reference words: 3.51 prodnt pathname


Performance Monitor SQLServer-Log Object Corrupted

Article ID: Q133757

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server version 3.51

 - Microsoft SQL Server, version 4.21a

-------------------------------------------------------------------------

SYMPTOMS

========

When you use the performance monitor SQLServer-log object, the instance

list of databases is corrupted with black bars.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop ntnetserv

Additional reference words: 3.51 prodnt sql perfmon


No Compaq Netflex Drivers in Windows NT 3.51 for RISC Platforms

Article ID: Q134250

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation 3.51

 - Microsoft Windows NT Server 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When installing or upgrading Windows NT 3.51 on a RISC platform, the Compaq

Netflex network interface card (NIC) is not recognized or the driver is not

updated.

NOTE: The Windows NT 3.5 driver does not work correctly on version 3.51.

CAUSE

=====

Microsoft has removed support for Netflex NICs from Windows NT because

Compaq only supports the Intel platform with the adapters.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

The Compaq Netflex NIC in RISC computers is supported by Microsoft. It is

currently the only Token Ring adapter supporting promiscuous mode for RISC

platforms. A driver for this NIC is planned for future versions of Windows

NT.

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdriver

Additional reference words: prodnt 3.51


STOP Msg: 0x0000007B or "0x4,0,0,0 Error" in WinNT 3.51 Setup

Article ID: Q134285

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

 ----------------------------------------------------------------------

SYMPTOMS

========

Windows NT 3.51 Setup traps with a "STOP: 0x0000007B" or fails with a

"0x4,0,0,0 error" when installing on an Enhanced IDE (EIDE) hard drive.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbsetup kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntsetup ntdriver

Additional reference words: prodnt 3.51


Windows NT 3.51 LsarLookupSids errors from Big Endian Servers

Article ID: Q134286

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

 ----------------------------------------------------------------------

SYMPTOMS

========

When your Windows NT 3.51 computer running Server Manager accesses the

properties of a "Big Endian" server, such as AT&T's UNIX Advanced Server,

the following error message appears:

   Invalid access to memory location

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: prodnt 3.51


Computers Using QVision Display Driver Lock Up

Article ID: Q134386

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you use the QVision display driver and DLL included with Windows NT

3.51, the computer locks up.

CAUSE

=====

The display driver inadvertently enables the QVision card to respond to

IRQ9. The computer can lock up if another card in the computer attempts to

use IRQ2 or IRQ9.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kb3rdparty kbhw kbbug3.51 kbfix3.51.sp2

KBSubcategory: nthw

Additional reference words: prodnt 3.51 1024 board stop responding hang


Dr. Watson Access Violation Occurs Sending Mail Attachments

Article ID: Q134427

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT operating system version 3.1

 - Microsoft Windows NT Advanced Server version 3.1

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

If you enable "Check spelling of messages before sending" in Windows NT

Mail (MSMAIL32.EXE), exit Mail, and send mail with a file attachment in

File Manager, the following Dr. Watson for Windows NT error message appears

and File Manager closes:

   An application error has occurred

   and an application error log is being generated.

      WINFILE.exe

   Exception: access violation (0xc0000005), Address: <Hex address>

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.1,

3.5, and 3.51. This problem has been corrected in the latest U.S. Service

Pack for Windows NT version 3.51. For information on obtaining the Service

Pack, query on the following word in the Microsoft Knowledge Base (without

the spaces):

   S E R V P A C K

KBCategory: kbtool kbbug3.10 kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntutil ntui

Additional reference words: prodnt 3.10 3.50 3.51 winfile 32-bit 32bit

workgroup


Uninitialized Pointers in DHCPSSVC.DLL Cause Access Violation

Article ID: Q134701

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When a remote procedure call (RPC) tries to determine the size of the

LPWSTR variable in the DHCP_Subnet_Info structure on your Windows NT DHCP

server, DHCPSSVC.DLL causes an Access Violation.

CAUSE

=====

The pointers for the NetBiosName and HostName strings point to random

memory addresses.

Due to a problem in DHCPSSVC.DLL the NetBiosName and HostName strings are

not initialized to NULL, even though they appear to be NULL in the SubNet

information subkey of the Windows NT Registry.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntstop

Additional reference words: prodnt 3.51


Unknown Software Exception When Application Calls OpenGL

Article ID: Q134765

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

An unknown software exception occurs when applications call OpenGL. When

Windows NT attempts to shutdown the computer, a blue

screen appears.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.51 kbfix3.51.sp2

KBSubcategory: nt32ap

Additional reference words: prodnt 3.51


Cannot copy Icons From a Common Group to a Personal Group

Article ID: Q134959

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you log on as anything other than an Administrative, you cannot copy

icons from a common group to a personal group. The "Windows NT System

Guide" states that this should be possible, and it is in Windows NT version

3.5.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbui kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntui

Additional reference words: prodnt 3.51 CTRL drag dragging System Guide

page 46


NetWare Connections Remain Connected After You Log

Article ID: Q134968

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

If you have Client Services for NetWare installed on a Windows NT

Workstation, and use Print Manager to monitor a printer on a NetWare

server, your connection to the NetWare computer is not always disconnected

immediately when you log off. Netware Monitor may show multiple connections

for the same user even if that user is only logged on at a single computer.

When you logging on, the following NetWare Authentication Failure dialog

appears:

   You cannot be authenticated on <netware server name> due to the

   following reason: An attempt was made to establish a session to a

   network server, but there are already too many sessions established

   to that server.

CAUSE

=====

There is a delay between logging off and actually disconnecting from the

NetWare server if Print Manager is run. Logging back on during this time

can result in multiple connections for the same user to the NetWare server.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop

Additional reference words: 3.51 prodnt csnw nwcs gsnw nwgs


Faxing from 16-bit Program Using Separate Memory Space Fails

Article ID: Q134969

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOM

=======

When you load a copy of Winfax and try to print to the fax driver from your

16-bit Windows program that is configured to run in its own memory space,

another copy of Winfax is loaded and the following error message appears:

   MOD / An error has occurred in your application.

       <Ignore>  <Cancel>

Regardless of which option you choose you are unable to get Winfax to work

and your system becomes unstable.

However, if the Winfax software is not set to auto-answer the modem, you

may run another serial program without a problem as the port is not in use

by Winfax. For example, if you run Windows Terminal and then to print to

Winfax from Windows WRITE.EXE, Winfax generates a "port in use" message as

expected.

CAUSE

=====

This problem occurs when the Winfax driver selected in your program tries

to access the serial port and gets confused about which copy of the loaded

Winfax software to use.

The confusion occurs because your program is configured to run in its own

memory space causing the Winfax printer driver to load Winfax because it is

unaware of the Winfax copy that is already loaded.

This problem is unique to Winfax because if you select the Winfax printer

driver in a program and choose to print from that program, the Winfax

printer driver loads Winfax to complete the fax transmission.

RESOLUTION

==========

To work around this problem:

1. Log off and on.

2. In Program Manager, select the program icon of the program you want to

   fax from and press ALT+ENTER.

   The Program Item Properties dialog box appears.

3. Clear the Run In Separate Memory Space check box and choose OK.

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbenv kb3rdparty kbbug3.51 kbfix3.51.sp2

KBSubcategory: nt16ap ntconfig

Additional reference words: prodnt 3.51


Browsing & Other Traffic Incur High Costs over ISDN Routers

Article ID: Q134985

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

Your ISDN TCP/IP router telecommunication connection costs appear to be

very high.

This problem occurs if all of the following are true:

 - Your network spans two or more sites.

 - You use ISDN TCP/IP routers.

 - You use an ISDN service that charges you based on connection time.

NOTE: This problem frequently occurs in Germany where ISDN TCP/IP routers

are popular and the ISDN connection time is measured in time intervals. A

time interval is called Gebuehreneinheit (GBE) and costs 0.23 Deutsche

Marks (DM). The length of the time interval for a GBE shortens with greater

distances between the sites, and vice versa.

CAUSE

=====

The following Windows NT features may cause a lot of traffic between domain

servers on different sites, causing your ISDN telecommunication costs to be

high:

- Domain browsing

- WINS replication

- Directory replication

- User accounts database (SAM) replication

- Printer browsing

- Other (DHCP, etc.)

You can use Network Monitor to check which of these features cause traffic

on your network, including traffic from and to the ISDN router.

How Domain Browsing Causes a lot of Network Traffic

---------------------------------------------------

The Windows NT domain master browser (DMB) exchanges computer browse lists

with the master browsers (MBRs), usually the backup domain controllers

(BDCs), in the other remote networks several times per hour.

In your multi-site company, Microsoft recommends you have at least one BDC

at each site. As a result, your company's domain may span multiple sites.

This causes browsing network traffic across the your ISDN routers.

Twelve minutes after an MBR boots and every twelve minutes thereafter, the

MBR connects to the DMB, that is also the Primary Domain Controller (PDC),

by sending a request to the NetBIOS name <domain>0x1b that is owned by the

DMB. The MBR then sends the local browse list to, and retrieves the global

browse list from, the DMB. This causes the first connection over ISDN and

usually lasts several seconds, so this may take up more than one GBE on the

ISDN line.

Browsing communication uses RPC over a named pipe connection. After the

named pipe connection is closed the logical network connection is still

entertained by the redirector for ten more minutes because that is when the

MBR redirector's KeepConn parameter expires by default. Although, this

logical connection does not incur ISDN router costs, frames sent to

disconnect after the ten minute period cause another ISDN connection to be

established, which incurs costs.

Two minutes later, 24 minutes after booting, the MBR connects again to the

DMB for a browse list exchange. This occurs every twelve minutes.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

To work around this problem, read the sub-section that applies to your

traffic problem:

 - Working Around the Domain Browsing Problem

 - Solving the Domain Browsing Problem with a Fix

 - Configuring Other Features That Cause Traffic

Working Around the Domain Browsing Problem

------------------------------------------

To work around this problem, modify the following parameters in the Windows

NT registry and/or configure your ISDN router to turn off during idle

hours:

WARNING: Using the Registry Editor incorrectly can cause serious, system-

wide problems that may require you to reinstall Windows NT to correct them.

Microsoft cannot guarantee that any problems resulting from the use of the

Registry Editor can be solved. Use this tool at your own risk.

 - To minimize ISDN connections with full availability of the domain browse

   list:

   a. Under the subtree HKEY_LOCAL_MACHINE, locate the following registry

      subkey:

         \SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

   b. Set the KeepConn parameter to a small value, for example, five

      seconds.

      This prevents network traffic between browse cycles to disconnect the

      connection made during the browse list exchange. Set this parameter

      on all domain controllers.

 - To further minimize ISDN connections during idle hours, for example,

   during the night and during the weekend, set a filter option on the ISDN

   TCP/IP router to turn off the ISDN line during the idle hours.

   NOTE: This results in loss of browse listings of computers on remote

   sites.

Solving the Domain Browsing Problem with a Fix

----------------------------------------------

To fix this problem, obtain the fix mentioned below from Microsoft Product

Support Services. This fix adds the MasterPeriodicity and the

BackupPeriodicity parameters to the registry in the HKEY_LOCAL_MACHINE

subtree under the following subkey:

   \SYSTEM\CurrentControlSet\Services\Browser\Parameters

Use the following information to configure these two new parameters.

MasterPeriodicity:

DWORD specifies in seconds how frequently an MBR contacts the DMB. The

default is 720 (twelve minutes), the minimum is 300 (five minutes). This

parameter can be changed dynamically (without rebooting) with the Registry

Editor or REGINI (from the Windows NT Resource Kit). You can schedule

REGINI with the scheduler service to reduce browser traffic during the

night or over the weekend.

The parameter should be set on each MBR. Because another computer can be

elected to be the MBR you should apply the fix to each Windows NT computer

in the domain, because they are most likely to win browser elections. For

additional information, please see the following article in the Microsoft

Knowledge Base:

   ARTICLE-ID:Q102878

   TITLE     :Information on Browser Operation

If you set the parameter on the DMB it affects the frequency it asks WINS

for the domain list (this might also cause WAN traffic).

BackupPeriodicity:

DWORD specifies in seconds how frequently a backup browser contacts the

MBR. The default is 720 (twelve minutes), the minimum is 300 (five

minutes). This parameter is not read dynamically so you have to restart

your computer. This parameter does not affect the WAN, since this traffic

is always on one subnet.

Configuring Other Features That Cause Traffic

---------------------------------------------

To minimize non-domain browsing traffic, modify the following parameters in

WINS Server Admin or the Windows NT registry:

WARNING: Using the Registry Editor incorrectly can cause serious, system-

wide problems that may require you to reinstall Windows NT to correct them.

Microsoft cannot guarantee that any problems resulting from the use of the

Registry Editor can be solved. Use this tool at your own risk.

 - For WINS replication, the interval is configurable in WINS Server Admin.

 - The following services are configurable in the Windows NT registry under

   the subtree HKEY_LOCAL_MACHINE:

   - For directory replication, the interval is configurable with the

     Interval parameter in the subkey:

         \CurrentControlSet\Services\Replicator

   - For SAM replication, the interval is configurable with the

     PulseMaximum parameter in the subkey:

        \CurrentControlSet\Services\Netlogon

   - For printer browsing, the interval is configurable with the

     DisableServerThread parameter in the subkey:

        \CurrentControlSet\Control\Print

STATUS

======

Microsoft has confirmed the domain browsing to be a problem in Windows NT

versions 3.5 and 3.51. This problem has been corrected in the latest U.S.

Service Pack for Windows NT version 3.51. For information on obtaining the

Service Pack, query on the following word in the Microsoft Knowledge Base

(without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv ntregistry

Additional reference words: prodnt 3.50 3.51 Novell sniffer trace


Access Violation in glsbCreateAndDuplicateSection API on PowerPC

Article ID: Q134988

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOM

=======

When you install a OpenGL client video driver on your PowerPC computer

running Windows NT and you run an OPENGL program, for example, the Windows

NT Pipes screen saver, an access violation occurs in the

glsbCreateAndDuplicateSection application programming interface (API).

CAUSE

=====

The assembly dispatch stubs for the GL API do not properly save and restore

the TOC register when they make their call.

If these stubs are only called from a different module then this code works

properly because the other module has code to save and restore the TOC.

However, Windows NT makes several GL calls in OPENGL32 itself, such as

glFlush and a variety of calls in the wgl font routines, and these calls do

not save and restore the TOC because everything is in the same DLL.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbole kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral

Additional reference words: prodnt 3.51


Windows NT 3.51 Hangs on Shutdown

Article ID: Q135065

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If Windows NT 3.51 is installed on a NEC Image P90 with an Adaptec 2940,

Windows NT may hang when you choose to Shutdown and Restart Windows NT.

CAUSE

=====

When you run Windows NT Setup, it detects and reserves the memory address

range where the system ROM resides. Under Windows NT 3.51, the memory where

the system ROM resides on the NEC Image P90 is not being reserved. When the

device driver for the Adaptec 2940 initializes, it allocates a memory

address range to be assigned to the controller. Because the address range

where the system ROM is locate was not marked as allocated, the Adaptec

driver may allocate it. When the system is shutdown, control is eventually

passed to the system ROM, which resides in an address range the Adaptec

driver mapped to the controller. Because of this, the system ROM code never

gets control to reboot the system.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbenv kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntboot

Additional reference words: 3.51 prodnt adaptec reboot


Windows NT Backup : Incorrect Date in "Tape Name" Text

Article ID: Q135275

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

The default "Tape Name" text generated for a tape by Windows NT Backup

(NTBACKUP.EXE) contains an incorrect date if the backup is started close to

midnight on a computer in a southern hemisphere time zone with the

"Automatically Adjust for Daylight Savings Time" option selected.

If Daylight Saving is in effect and the backup is started between 11:00 pm

and midnight, Tape Name shows the following day's date.

If Daylight Saving is in NOT effect and the backup is started between

midnight and 1:00 am, Tape Name shows the previous day's date.

CAUSE

=====

NTBACKUP.EXE does not take the computer's configured time zone into

consideration.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntbackup

Additional reference words: 3.51 prodnt


WINS Records of Multi-homed Computers Do Not Replicate

Article ID: Q135277

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

A Windows NT multi-homed computer registers with one of two Windows

Internet Naming Service (WINS) servers that are replicating with each

other. If you change the IP addresses of the Windows NT multi-homed

computer and register with another WINS server, the previous records on

the first WINS server are not updated. Therefore, the new registration

corresponds to the previous IP addresses.

CAUSE

=====

An active multi-homed unique replica does not replace an active multi-

homed replica in a WINS database if the owner's identifications are

different (the two records are owned by different WINS servers, neither

of them being the WINS server that pulled the replica).

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

To work around this problem:

1. Create a static entry for the multi-homed computer in the first WINS

   server.

2. Enter the new IP addresses for the static entry.

   Inserting a static record is acceptable, because MigrateOn is set by

   default on a WINS server. If the node registers again with a new

   address, assuming the old static address has become obsolete, the new

   registration or its replicas will overwrite the old static entry.

3. Ensure that MigrateOn is set by selecting the WINS server Advanced

   Settings configuration.

After the records are replicated to the WINS servers, the previous

registration records, that are not used, are overwritten.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: nttcp

Additional reference words: prodnt 3.50 3.51 dns replicating


Print Manager: Owner Appears as System Printing from Macintosh

Article ID: Q135291

----------------------------------------------------------------------

The information in this article applies to:

- Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you print from a Macintosh client to a Windows NT 3.51 server, Windows

NT Print Manager incorrectly shows the print job owner name to be System

instead of your Macintosh user name.

Windows NT Server 3.5 correctly displays your Macintosh user name as the

owner.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbinterop kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint ntmac

Additional reference words: prodnt 3.51 wrong MAC


Disk Administrator Corrupts Partitions

Article ID: Q135308

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

 ---------------------------------------------------------------------

SYMPTOMS

========

When you install Windows NT 3.51 and start Disk Administrator for the

first time, Windows NT will write a disk signature to the drives before

opening the Disk Administrator window.

The first time Disk Administrator is opened, drives and partitions appear

correctly, but if you close and reopen it, some of the partitions are lost

and incorrect information is displayed on the others. Alternatively, Disk

Administrator can hang during initialization or the error message, "The

parameter is incorrect" appears.

This only happens if there are more than two logical drives in an extended

partition when Disk Administrator attempts to write a fault tolerance

signature.

This problem will not occur if a signature is already present.

CAUSE

=====

Windows NT Disk Administrator writes a fault tolerance signature to each

physical drive's master boot record, if one is not already present, when it

is run for the first time. Faulty calculations result in the corruption of

logical drives in an existing extended partition.

NOTE: It is possible for a system to remain functional after the partition

table is corrupted. The nature of the corruption is such that partition

table data is written to incorrect locations on the disk which may lie in

the middle of user or file system data. Provided this information is not

overwritten, the partition table entries may still identify the layout of

the drives sufficiently well that Windows NT can continue to access the

drives. However, this is an unstable situation and access to the partitions

will be lost when the table entries are eventually overwritten.

If the table entries overwrite existing data, user data or file system

integrity are compromised immediately.

If you suspect that your partition table is compromised, immediately back

up critical data, then re-partition your disk and restore the backed up

data to the system.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

If Disk Administrator has not been run, you can prevent partition table

corruption by any of these 3 procedures:

 - If there are not already more than two logical drives in an extended

   partition, simply use Disk Administrator normally. The signature will be

   written correctly and no corruption should ensue. If there are more than

   two logical drives, perform a full system backup of data on all drives

   prior to running Disk Administrator. Then be prepared to delete and

   recreate the partition structure prior to restoring the previously

   backed up data.

 - If an earlier version of Windows NT is available, boot that version and

   run its Disk Administrator so that a fault tolerance signature is

   written to the disk. The 3.5 version of WINDISK.EXE may be run directly

   on Windows NT version 3.51 in order to write the initial fault tolerance

   signature, but is not recommended for systems using third-party

   partitioning software to support large IDE drives.

 - If you have the tools and knowledge to edit the disk at the sector

   level, you may manually enter a disk signature so that Disk

   Administrator will not try to do so. The 4-byte signature is located at

   offset 0x1b8 from the start of the Master Boot Record (physical sector

   0). The value written is not important provided that it is non-zero, but

   if there are multiple disks in the system, each should have a distinct

   signature value. If this field is already non-zero, it is not necessary

   to change it.

   CAUTION: Use this option at your own risk. Incorrectly editing physical

   disk sectors can result in corruption of the entire physical volume,

   resulting in loss of data and may require a complete reinstallation of

   the operating system.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntboot ntfault ntfilesys ntutil

Additional reference words: prodnt 3.51 fdisk mbr


Cannot Reconnect to OS/2 Name Space Resources on NetWare Server

Article ID: Q135471

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

If you use Client Services for NetWare (CSNW) to connect to a NetWare

server that has the OS/2 Name Space installed, and the connection is

somehow disconnected, you cannot reestablish the connection.

For example, if you press the F5 key to refresh a File Manager drive window

focused on a disconnected drive on the NetWare server, the message The

Specified Path Is Invalid appears in the right-hand pane of the drive

window. The window is not refreshed, and the connection to the NetWare

server is not reestablished.

This problem does not occur if the OS/2 Name Space is not installed on the

NetWare server.

CAUSE

=====

There is a problem in the reconnection code for OS/2 Name Space resources.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop

Additional reference words: prodnt 3.51 CSNW GSNW NWGS


PIF Editor Reserve Shortcut Keys Settings May Be Ineffective

Article ID: Q135548

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

The Reserve Shortcut Keys options in the Advanced section of the PIF

Editor are ineffective for ALT+TAB, ALT+ESC, and CTRL+ESC, if the PIF also

specifies Full Screen Display Usage.

If an MS-DOS-based application is started in full screen mode using such a

PIF, and the first keyboard input is one of the above combinations, a

switch back to graphics mode is made, and the MS-DOS-based application

appears as a minimized window, even if these shortcut key combinations have

been reserved. If the MS-DOS-based application is subsequently restored to

full screen mode, these shortcut keys are reserved as expected.

CAUSE

=====

NTVDM sets the reserved keys after switching to full screen mode, rather

than before switching to full screen mode.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdosap

Additional reference words: 3.51 prodnt pifedit


IOCTL_NDIS_QUERY_ALL_STATS Causes STOP Msg in Windows NT 3.51

Article ID: Q135553

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If your application querys a Miniport MAC driver from user mode using

DeviceIoControl with the IoCtl Opcode of IOCTL_NDIS_QUERY_ALL_STATS, this

STOP message appears:

   STOP: 0x0000001E (0xC0000005 0x801704a7 0x00000001 0x00000001)

This error occurs sporadically.

CAUSE

=====

The NDIS.SYS driver is referencing an invalid pointer.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: prodnt 3.51 crash blue screen blue-screen


NetWare Transaction Tracking System (TTS) Not Detected

Article ID: Q135621

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

On your computer running Windows NT, when you start a database client

program that connects to a database on a Novell NetWare server, the program

generates a warning message that the Novell NetWare server's Transactional

Tracking System (TTS) is not active, even though it is.

If you use your database application despite the warning, the index tables

in the server's database are destroyed.

This problem occurs if you run Windows NT Client Services for NetWare

(CSNW) and the database client program uses NetWare APIs to detect whether

TTS is available.

CAUSE

=====

CSNW does not correctly interpret the status information returned by the

NetWare server when it checks for the presence of TTS.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kb3rdparty kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: prodnt 3.50 3.51


STOP 1E When Using File Manager and Services for Macintosh (SFM)

Article ID: Q135667

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you use File Manager to drag and drop large files that were created

on Macintosh clients, Windows NT 3.51 Server displays the following STOP

message:

   Bugcheck 0000001e : c0000005 801704a7 00000001 00000001

CAUSE

=====

SFM.SYS does not initialize a structure properly.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv ntstop

Additional reference words: 3.51 prodnt Services for Macintosh (SFM) trap

blue screen


"List Name From" List Box Shows Only 20 Trusted Domains

Article ID: Q135692

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

After establishing more than twenty trust relationships, User Manager and

File Manager do not list all the trusted domains. The Add Users and Groups

dialog box List Name From list box lists only twenty domains plus the

current domain name. Permissions can be successfully assigned by manually

typing in the appropriate user account or group from an unlisted trusted

domain.

CAUSE

=====

When there are many trusted domains in a network, attempts to enumerate

trusted domain names require multiple calls to the LSA API. The LSA API

indicates this by returning ERROR_MORE_DATA as a status code to the calling

routine. In this case, the calling routine overwrites the returned status

code of ERROR_MORE_DATA before it checks the status again to see if

additional calls to the LSA API are necessary.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntsecurity

Additional reference words: 3.50 prodnt


Deleted Disk Space Not Released on Converted NTFS Volume

Article ID: Q135724

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you copy a large file to a nearly full disk, delete the file, and then

copy another large file to the disk, the second copy attempt may fail. This

problem occurs even though the system reports adequate disk space is

available for the second file.

This problem only occurs on computers that were upgraded to Windows NT 3.51

from a previous version of Windows NT, and on which the disk volume was

converted to the Windows NT file system (NTFS) during or after the upgrade

process. This problem occurs on uncompressed volumes, and will not occur on

volumes that were formatted for NTFS prior to installing Windows NT 3.51.

CAUSE

=====

When you copy then remove a large file from a nearly full NTFS partition,

you may create free space between the beginning of the disk and the Master

File Table (MFT). Because NTFS starts looking for free space at the MFT,

NTFS does not see the free space after the file is deleted.

RESOLUTION

==========

To work around this problem, install Windows NT 3.51 in a new directory.

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

MORE INFORMATION

================

When NTFS is looking for free space on the disk, it scans through a bitmap

of the disk that identifies the state of each block on the disk (free or in

use). The scanning process starts at the MFT rather than the beginning of

the disk. If free space exists before the MFT, the space is not found

during the scanning process. If the disk was formatted for NTFS, there are

no files between the start of the disk and the MFT. However, if the disk

was converted to NTFS, then files can exist between the beginning of the

disk and the MFT. Once those files are deleted, free space exists between

the start of the disk and the MFT. Because the scanning process starts at

the MFT, free blocks before the MFT are never be allocated to a file.

For additional information on NTFS and Master File Table, please see the

following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q101670

   TITLE     : Transaction Log Supports NTFS Recoverability

KBCategory: kbhw kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntfilesys

Additional reference words: 3.51 prodnt diskspace


Performance Monitor Counters Produce Unlikely Results

Article ID: Q135774

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

When you use the HALAPIC.DLL hardware abstraction layer (HAL), applications

that query performance counters may produce unlikely results. For example,

Network Monitor Agent counters may produce numbers for network use

that are known to be incorrect.

CAUSE

=====

Applications that query Performance Counters on Intel based symmetric

multi-

processing (SMP) computers may receive incorrect timer information. As a

result, counter values in Performance Monitor, and other programs that are

calculated against this timer, may be incorrect.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral

Additional reference words: 3.50 3.51 prodnt


Unable to Connect Using Cabletron EISA F70XX FDDI NIC

Article ID: Q135777

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If you install both NetBEUI and TCP/IP under Windows NT on a AST Manhattan

P Series 5090 (dual processor) server computer using a Cabletron EISA F70XX

FDDI network interface card (NIC), client computers using the NetBEUI

protocol are unable to connect to the server.

RESOLUTION

==========

To correct this problem:

 - Download F70NT35.ZIP from the Cabletron Bulletin Board Service (BBS) at

   (603) 335-3358 and install the updated Cabletron EISA F70XX FDDI NIC

   driver.

   -or-

 - Upgrade to Windows NT 3.51 (if you have not already done so) and install

   the latest U.S. Service Pack for Windows NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

The third-party products discussed here are manufactured by Cabletron and

AST Research, Inc., vendors independent of Microsoft; we make no warranty,

implied or otherwise, regarding these products' performance or reliability.

KBCategory: kb3rdparty kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntinterop

Additional reference words: prodnt 3.50 3.51 adapter


RIP Table Does Not Update When New RIPX Response Is Received

Article ID: Q135856

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

Windows NT 3.51 sends "Routing Information Protocol over IPX" (RIPX)

updates to routers but the routers fail to update the Routing Information

Protocol (RIP) table. If a router receives a RIPX response for a network

with a hop (tick) count, and then receives another RIPX response with a new

hop (tick) count, it should update the routing table with this information.

NOTE: You need to have Remote Access Service (RAS) installed with NWLink

in order to send or receive RIPX packets from Windows NT 3.51.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: nttcp

Additional reference words: prodnt 3.51


Batch Files Stop Executing with Windows NT version 3.51

Article ID: Q136023

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

Batch files using line feeds, instead of line feeds and carriage returns,

stop executing prematurely with Windows NT version 3.51. The same batch

files execute correctly with version 3.5.

NOTE: Batch files with only line feeds are common in UNIX.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntgeneral

Additional reference words: prodnt 3.51


Tape Hardware Data Compression Disabled After Running NTBackup

Article ID: Q136024

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

After you quit Windows NT NTBackup, tape hardware data compression is

disabled even though it is enabled with a jumper setting on the tape drive.

CAUSE

=====

By default, NTBackup disables tape hardware data compression. When you quit

NTBackup, it fails to reenable tape hardware data compression.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbtool kbhw kb3rdparty kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: nthw

Additional reference words: prodnt 3.50 3.51


Access Violation in LSASS.EXE During User Password Change

Article ID: Q136334

-------------------------------------------------------------------------

The information in this article applies to:

- Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

When your domain password expires and you are prompted to change your

password, an access violation in LSASS.EXE occurs on your domain

controller. As a result, you cannot change your password and log on until

the domain controller is back online again.

This problem occurs intermittently.

CAUSE

=====

This failure occurs because of a problem during the calculation of the

session id used for the password change operation.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntsecurity

Additional reference words: prodnt 3.50


Windows NT Fails Because of an Access Violation in WINLOGON

Article ID: Q136336

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

If an access violation occurs in WINLOGON, an updated DrWtsn32.LOG appears

in the %SystemRoot directory and the following symptoms also occur

sporadically:

 - A STOP 21a message appears on the server screen.

 - The error message "Error 1723 RPC Server too Busy" is returned to client

   requests.

CAUSE

=====

Winlogon fails due to an access violation caused by an RPC length pointer

that refers beyond the end of a data structure (RPC buffer) referenced

during RPC unmarshalling. This occurs if a client program provides an

invalid RPC packet length or the length field gets damaged during the

delivery to the server process.

The STOP 21a message occurs if the security system fails.

The Error 1723 occurs if threads in the SERVICES.EXE block as a result of

the security system failure.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntsecurity ntnetserv ntstop

Additional reference words: prodnt 3.51


NTFS directory corruption with more than 100,000 files

Article ID: Q136375

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Server versions 3.5 and 3.51

----------------------------------------------------------------------

SYMPTOMS

========

If a large number of files exist in a directory on a Windows NT file system

(NTFS) volume, directory corruption may be reported in a File Manager

message box when additional files are copied to the directory. If the COPY

command is used to place the additional files in the directory, the

following error appears:

   The file or directory <dir name> is corrupt, please run chkdsk

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbother kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntfilesys

Additional reference words: 3.50 3.51 prodnt


IniFileMapping for 16-Bit Windows Apps Fail in Windows NT 3.51

Article ID: Q136402

--------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

--------------------------------------------------------------------------

SYMPTOMS

========

When you add a new key to map Windows 16-bit .INI files to user specific

entries in the Microsoft Windows NT Registry using the

Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping key, then

mappings have no effect. Mappings created with previous versions of Windows

NT do not work either.

CAUSE

=====

IniFileMapping does not work if the application calls the Windows Kernel

API function GetPrivateProfileString with a fully qualified pathname (for

example, C:\PROGHRAMS\MYAPP\MYAPP.INI).

This functionality changed in Windows NT 3.51 because applications failed

if they tried to call GetPrivateProfileString with a fully qualified

pathname because they got their information from the Windows 3.1 WIN.INI

entries. The fix mentioned below treats references to WIN.INI as a special

case. If WIN.INI is referenced, the standard WIN.INI file is be used.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: nt16ap

Additional reference words: 3.5 3.51 prodnt HKEY_LOCAL_MACHINE subtree path

name


NE3200 NIC Driver Can Lose Locally Administered Address

Article ID: Q136472

--------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation versions 3.5 and 3.51

 - Microsoft Windows NT Server versions 3.5 and 3.51

--------------------------------------------------------------------

SYMPTOMS

========

This problem occurs on an NE3200 Network card that has had a Locally

Administered Address (LAA) assigned to it.

If an adapter reset is issued to the card, the card will no longer accept

packets sent to its LAA. However, it will still transmit packets using its

LAA and will still process any broadcast/multicast packets that it sees.

CAUSE

=====

This problem occurs because the LAA is not correctly rewritten to the

adapter after an NdisReset is issued.

This problem only occurs with the NDIS 3.0 miniport driver included with

Windows NT 3.5 and 3.51. The non-miniport driver included with Windows NT

3.1 does not have this problem.

RESOLUTION

==========

To correct this problem, upgrade to Windows NT 3.51 (if you have not

already done so) and install the latest U.S. Service Pack for Windows NT

version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT versions 3.5 and

3.51. This problem has been corrected in the latest U.S. Service Pack for

Windows NT version 3.51. For information on obtaining the Service Pack,

query on the following word in the Microsoft Knowledge Base (without the

spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.50 kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntdriver

Additional reference words: 3.51 3.50 prodnt nic mac novell eagle


Layered Drivers Never See WINSOCK IRPs for the TCP/IP Device

Article ID: Q136627

----------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

----------------------------------------------------------------------

SYMPTOM

=======

Filter drivers or layered drivers never receive WINSOCK IRPs destined for

the TCP/IP device.

CAUSE

=====

AFD.SYS builds IRPs using the DEVICE_OBJECT from the FILE_OBJECT, rather

than that returned by IoGetDeviceObjectPointer().

MORE INFORMATION

----------------

If a device driver is designed to layer itself over another driver, it may

do this by calling IoGetDeviceObjectPointer(). This returns a pointer to a

DEVICE_OBJECT structure which should be used when building I/O Request

Packets (IRPs).

If another device has called IoAttachDevice() before

IoGetDeviceObjectPointer() is called, then a DEVICE_OBJECT structure is

returned for the intermediate driver, and not the intended target. Thus the

top level driver does not need to know of the presence of the vertical

driver.

TDI operation requires that ZwCreateFile() is used to open handles on a TDI

Transport to create Connection and Address objects. This returns a handle

for the open object, which can be passed to ObReferenceObjectByHandle() to

obtain a pointer to a FILE_OBJECT structure.

The FILE_OBJECT structure contains a pointer to a DEVICE_OBJECT within it.

If this DEVICE_OBJECT is used when building IRPs, the IRP is not passed to

the filter driver, instead it is passed straight to the TDI Transport.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntnetserv

Additional reference words: prodnt 3.51 file object


WinFax Pro Software Causes 16-bit Applications To Hang

Article ID: Q136780

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

Delrina WinFax Pro uses a 16-bit application to send a fax through the

print services of a WinFax driver. If you have configured the WinFax driver

as the default printer driver, a Delrina WinFax Pro Send dialog box appears

when you print. When you choose a cover page or switch to the 16-bit

application to perform additional work, all 16-bit applications, including

Delrina WinFax Pro, stop responding (hang).

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbui kbbug3.51 kbfix3.51.sp2

KBSubcategory: nt16ap

Additional reference words: prodnt 3.51 ntvdm wowexec


Unable To Connect To AT&T Advanced Server For UNIX Printer Share

Article ID: Q136782

-------------------------------------------------------------------------

The information in this article applies to:

 - Microsoft Windows NT Workstation version 3.51

 - Microsoft Windows NT Server version 3.51

-------------------------------------------------------------------------

SYMPTOMS

========

An attempt from a Windows NT computer to connect to an AT&T Advanced Server

for UNIX printer share fails.

CAUSE

=====

The AT&T Advanced Server for UNIX is a Windows NT server on a UNIX network

environment. Windows NT computers view the print provider of the AT&T

Advanced Server for UNIX as a downlevel print server (for example, a LAN

Manager 2.x print server). The AT&T Advanced Server for UNIX provides full

server functionality except for the print server functionality (SpoolSS) to

Windows NT computers.

RESOLUTION

==========

To correct this problem, install the latest U.S. Service Pack for Windows

NT version 3.51.

STATUS

======

Microsoft has confirmed this to be a problem in Windows NT version 3.51.

This problem has been corrected in the latest U.S. Service Pack for Windows

NT version 3.51. For information on obtaining the Service Pack, query on

the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbprint kbbug3.51 kbfix3.51.sp2

KBSubcategory: ntprint ntinterop

Additional reference words: 3.51 prodnt printman