Backup w/ OFM event log failed allocate sufficient resources in OlvCacheInit (4047530)

Date:07/06
Affected NV Version: All
OS Version: Windows
Plugin version: n/a
Application version: n/a

Description: Can not get OFM to sync drives in order to backup your open files on a windows server.

Problem comes in when you have too many resident drivers in nonpaged memory

OFM failing to allocate memory for its cache. This is not uncommon. The condition shown is simply that there was insufficient nonpaged pool memory available for OFM to support as configured. OFM must create 3 bitmaps for each local, non-removable volume on a system, plus it will use some additional nonpaged pool for subsequent caching operations. The dialog below is specifically during the initialization of the cache, which occurs at the beginning of a backup when OFM sync's the volumes.

The solution to the allocation issue is to configure OFM to use less memory for its bitmaps. This is accomplished by modifying the AllocationThreshold DWORD value in the registry. This value represents all of the nonpaged pool that OFM will be allowed to use in order to maintain a synchronized state for all the volumes. If all volumes can't be sync'd within this value using the default bitmap size, the bitmaps will automatically be reduced to a value that will work.

The following registry values can be modified to limit the amount of non-paged pool memory OFM uses: "HKLM\SYSTEM\CurrentControlSet\Services\OFMLvDrv\Parameters\AllocationThreshold". This value is set in MB and is the maximum amount of non-paged pool memory that OFM will use under any circumstances. The default value is around 75% of the minimum non-paged pool a system can have. This is typically 96 MB for systems with more than 128MB if physical memory. The maximum amount of non-paged pool memory available to NT systems is limited (128MB for NT 4.0 and 256MB for Win2k and above) so it's ossible that using 96 MB can run the system critically low on non-paged pool. This configuration parameter is offered for this reason. The customer may wish to reduce the AllocationThreshold to 60-80MB if there are other drivers using a fair amount of non-paged pool...and, there is a risk of running out. If OFM hits the threshold during an allocation attempt, the volume that it's attempting to allocate the resource for will unsync, and any memory used for managing the volume will be released.. The rest of the volumes will remained sync'd. OFM creates 3 bitmaps per volume and the bitmaps are stored in nonpaged pool. The size of the bitmaps is automatically determined by the AllocationThreshold discussed above. The formula is, in broad strokes, the AllocationThreshold divided by the total number of volumes on the system multiplied by 3, with a 5% margin. It's possible to configure the MaxBitMapSize to override the calculate, but it's then up to the
user to determine the value that will allow all of the volumes to sync without hitting the AllocationThreshold. "HKLM\SYSTEM\CurrentControlSet\Services\OFMLvDrv\Parameters\MaxBitMapSize" Using the radio-button configuration in the Control Component, essentially reduces the MaxBitMapSize to 3MB. The MaxBitMapSize should not be set directly.

Changes to the setting will take effect during the next sync attempt.