Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Troubleshooting AD Replication error 8446: The replication operation failed to allocate memory
Article ID: 2693500 - View products that this article applies to.
This article describes the symptoms, cause, and resolution steps for issues when Active Directory replication fails with error 8446: “The replication operation failed to allocate memory"
1. REPADMIN.exe reports that replication attempt has failed with error “8446” – The Replication operation failed to allocate memory
2. DCPROMO fails with error 1130
3. NTDS Replication, NTDS General Events with the 8466 status are logged in the directory service event log.
4. When you try to manually initiate replication using Repadmin or Active Directory Sites and Services you get the following error message:
5. The domain controller may become unresponsive and a reboot will provide a temporary workaround.
The 8446 (operation failed to allocate memory. This operation will not continue) status can occur when the Active Directory replication engine cannot allocate memory to perform Active directory replication.
These events can occur due to the following conditions:
The following information is important to understand:
Determine if there is depletion of following resources and fix the underlying cause:
o Physical RAM
o Paging File
o Paged Pool or Non-Paged Pool Depletion
· LSASS Virtual memory fragmentation: If the root cause is not memory, then the problem may be caused by a lack of available continuous address space for memory allocation. Due to memory fragmentation, the available address segments are too small to satisfy request.
The fragmentation problem is not apparent on 64-bit systems since it has much larger virtual address space 16TB. Therefore, a solution is replacing 32-bit domain controllers with DC’s running 64-bit hardware and a 64-bit version of operation system.
· Domain Controller Scalability: If there is no apparent memory leak or resource depletion:
Check the size of the NTDS.DIT file on the domain controller; if the size is beyond 2 GB on a
32- bit domain controller, then a likely solution is to move to a 64-bit operating system and hardware.
There are many cases where administrators have moved onto to x64 Bit hardware and not faced a repeat of the 8446 (Replication failed to allocate memory) error.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4948 (Active Directory Performance for 64-bit Versions of Windows Server 2003)
For 32-bit operating systems, depending on the size of the NTDS.DIT, the /USERVA boot.ini switch which increases the virtual mode address space on domain controllers may provide relief, but this might cause kernel mode depletion as this reduces the size of the kernel mode address space. Prior to implementing the /UserVA switch, it is best to consult with a Windows memory performance tuning expert for an analysis of kernel mode and user mode memory usage.
Database cache consume all available virtual memory for the LSASS process
Run Performance Monitor with database counters, review the following counters:
Note: By default you will not be able to view the database counters on a Windows 2003 Domain controller. Please use the following steps to add the database counters on Windows Server 2003. These steps are not needed for Window Server 2008 and later.
Open Perfmon or restart performance monitor if already open.
You should by now be able to view a new performance object in Perfmon called Database
Add the “Database Cache Size” counter. In the following example, the database cache size grows at an increasing trend of Virtual Bytes and Working Set of the LSASS Process eventually consuming all 2 GB of available virtual memory allocated to the LSASS process. You will encounter the 8446 replication failure once this virtual address space is consumed. Please refer to the "LSASS ESE Database cache is not limited by default" section of the article for detailed instructions on how to avoid this condition.
o LSASS ESE Database cache is not limited by default, so if you determine it is the database cache that is consuming memory using performance monitor you can add the following registry value to limit the database cache.
You can use the “EDB max buffers” registry value for limiting ESE cache allocation (number of pages is 8912 bytes) to prevent the conditions.
Value Name : EDB max buffers
Type : reg_dword
Setting : <refer to the values below>
Registry key: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
CAUTION: Ensure that you set an optimal value to the registry value (EDB max buffers), if the cache limit is too low then it might cause performance degradation.
You may apply the following values as start for an optimization, depending is the /3GB boot.ini switch is use or not:
Without /3GB switch: "EDB max buffers", Reg_DWord: 157286 (1.2GB); expected LSASS consumption ~1.5GB
With /3GB switch: "EDB max buffers", Reg_DWord: 235929 (1.8GB); expected LSASS consumption ~2.1GB
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.