Heap Manager Change in Service Pack 4 and Windows 2000

ID: Q195008

The information in this article applies to:

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

SUMMARY

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 Internet Explorer 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:

Q195009 Application Access Violation or Hang After Applying SP4

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.

Additional query words: AV stack hang error compatguidestability

Keywords : NT4SP4Fea kbKernBase kbNTOS400 kbWinOS2000 kbNTOS400sp4 kbfaq
Version : WINDOWS:2000; winnt:4.0
Platform : WINDOWS winnt
Issue type : kbinfo