You are currently offline, waiting for your internet to reconnect

Heap manager change in Service Pack 4 and Windows 2000

This article was previously published under Q195008
This article has been archived. It is offered "as is" and will no longer be updated.
Windows NT version 4.0 Service Pack 4 and Windows 2000 contain changes in the heap manager allocation pattern to provide for better performance and scalability for multithreaded applications, particularly when running on symmetric multiprocessing (SMP) computers. These changes might expose user-mode, process heap allocation bugs in some applications.

If you encounter such a bug after applying Service Pack 4 to Windows NT 4.0, you can add the application to a list maintained in the registry. This will cause Windows NT to revert to the Service Pack 3 and earlier heap allocation patterns for that particular application.

If you encounter a bug after upgrading to Windows 2000, modify your application to manage heap properly.
More information
The Windows NT Service Pack 4 and Windows 2000 heap manager changes may cause blocks of freed or reallocated memory to be reused for subsequent allocations in a different order than with the Service Pack 3 heap manager. This may expose heap-related bugs in some applications when running under Service Pack 4 or Windows 2000 that were previously not seen when running under Service Pack 3 (or earlier).

The symptoms of such an application bug can vary greatly, from a simple access violation to a more obscure loss of functionality or apparently corrupted data.

Consider if an application frees a block of memory and later (errantly) fetches some data from that freed block. With Service Pack 3, that freed block might remain intact and unmodified between the time the application freed it and later fetched data from it, so the problem would not be apparent. With Service Pack 4 and Windows 2000, that same freed block might be reused for another allocation request in the application, which would cause it to be modified before the application fetches the freed heap block data, so the results fetched from that freed heap block might be different.

Another example is reallocating a heap block. With Service Pack 3, reallocating a heap block to a smaller size may not cause the block to move to a new address in memory, but with Service Pack 4 or Windows 2000, that same reallocation request may cause the block to move. If an application assumes the reallocated block will not be moved to a new address when it is reallocated, that may cause problems when running under Service Pack 4 or Windows 2000 that would not be apparent when running under Service Pack 3.

If you suspect an application is encountering such a problem because of this change in heap behavior between Service Pack 3 and Service Pack 4, add the application to the Image File Execution Options list in the registry, according to the directions in the following article in the Microsoft Knowledge Base:
195009 Application access violation or hang after applying Service Pack 4
Adding the application to this list causes the Service Pack 4 heap manager to revert to Service Pack 3 (or earlier) allocation patterns for that particular application.

This workaround does not apply to applications running in Windows 2000. Please update applications expected to run in Windows 2000 to manage heap properly. There are many third party tools on the market that can help you monitor heap usage in your applications. If your application is designed to scale on multiple processor platforms, avoid using HeapValidate or HeapWalk, which will disable Windows NT and Windows 2000 Heaplookaside for that application's usermode heaps.

An application can have one or more enabled processes, meaning the programmer used HeapValidate or HeapWalk or enabled the DisableHeapLookAside registry entry only found in Windows NT 4.0 Service Pack or higher. If any of an application's processes are enabled, then that application is no longer monitored by the heap manager's heaplookaside process. This could have secondary affects on the enabled processes, but cannot affect the heaps of other processes. This can slow down other applications or even cause them to fail.

This will decrease Windows NT performance and prevent your application from scaling properly in a multiprocessor environment. This can be compounded if your application creates multiple processes since each usermode process heap would in turn have the lookaside procedure disabled. The functionality will not be restored until the application is restarted without the system calls.
AV stack hang error compatguidestability

Article ID: 195008 - Last Review: 10/26/2013 01:09:00 - Revision: 5.0

Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Professional Edition, Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows NT Workstation 4.0 Developer Edition, Microsoft Windows NT Server 4.0 Enterprise Edition

  • kbnosurvey kbarchive kbFAQ kbfea kbinfo kbkernbase KB195008