This article was previously published under Q166571
This article has been archived. It is offered "as is" and will no longer be updated.
Shortly after you create a Macintosh volume on a partition larger thanapproximately seven (7) GB with a large number of files, the systemmay crash with a STOP 0x24 error in NTFS_FILE_SYSTEM (NTFS.SYS).
The AppleTalk protocol driver Afp.sys, depletes the memory pool allocatedto non-paged pool while indexing a Services for Macintosh (SFM) volume.
This problem may also occur when the Services for Macintosh (SFM) serveris experiencing performance problems, Event ID 12053 errors, or indexingproblems. See the following Microsoft Knowledge Base articles for moreinformation:
ARTICLE-ID: 136300 TITLE : Event ID 12053 or 12054 Caused by Macintosh Client Disconnect
ARTICLE-ID: 147909 TITLE : Troubleshooting MacVolume Creation Errors
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
152734 How to obtain the latest Windows NT 4.0 service pack
For your convenience, the English version of this post-SP3 hotfix has beenposted to the following Internet location. However, Microsoft recommendsthat you install Windows NT 4.0 Service Pack 4 to correct this problem.
To work around this problem, increase the non-paged pool memory availableto kernel or reduce the number of files on the SFM volume. The amount ofnon-paged pool available to kernel is a fixed value that is based upon thetotal RAM in the system. If you increase the RAM you will increase the non-paged pool available to kernel.
This problem will generally only occur on a partition with 100,000 ormore files that take up 7 to 8 GB or more disk space. When a SFM volume iscreated, the service will start indexing the partition. The indexingroutines create memory structures that consume a large amount of non-paged pool memory and if your volume is large enough and has enoughfiles, you will run out of non-paged pool and the system will stopresponding. In most cases, this results in a STOP 0x24 in NTFS, althoughit can occur when another kernel-mode driver attempts to allocateresources that require non-paged pool memory.
The system may simply be slow and unresponsive for the first 20 to 40minutes after creating the Macintosh volume. This is because of the largeamount of kernel memory being used by SFM. If SFM is able to completethe indexing without running out of non-paged pool memory the memorywill be freed and the system will return to normal. There should be noproblems after this unless enough changes occur that a full re-indexing isnecessary. In this case, SFM will have to repeat the procedure.
The simplest way to identify this problem is to run Performance Monitorafter you create the SFM volume and watch the Memory\Pool Nonpaged Bytescounter. If a constant increase in non-paged pool bytes occurs over a 20to 30 minute period of time, resulting in large amount (20 to 30 MB ormore) of non-paged pool, you may be experiencing this problem.
For more information, please see the following articles in the MicrosoftKnowledge Base:
ARTICLE-ID: 172511 TITLE : Stop 0x0000000A w/ Services for Macintosh & McAfee Anti- Virus
ARTICLE-ID: 177644 TITLE : Commenting Macintosh File Changes Date and Time Stamp
ARTICLE-ID: 178364 TITLE : Macintosh Clients See Files on Windows NT Server Constantly Moving
ARTICLE-ID: 180622 TITLE : STOP: 0x0000001E with STATUS_INSUFFICIENT_RESOURCES with More Than 800,000 Files on a Macintosh Volume
ARTICLE-ID: 180716 TITLE : SFM Fails to Accept Associations with Two-Character Extensions
ARTICLE-ID: 180717 TITLE : SFM: File Date and Time Stamp Change with Get Info
ARTICLE-ID: 180718 TITLE : SFM: Disconnect Macintosh Clients before Dismounting Volume
ARTICLE-ID: 185722 TITLE : SFM Rebuilds Indexes upon Restarting of Windows NT
Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.