Hi to all. I have an intermittent problem with some of my Windows XP boxes that are running an Intouch 9.5 SP3 application. The actual error has a header of Internal Error and the message is wwHeap /wwHeap_Lock (21170000, 00000000) Continue? The error box appears to repeat multiple times on the screen. Has anyone else experienced these issues?? Possible resolutions??
HEAP Internal Errors in Intouch 9.5 SP3
- Thread starter CalfeMic
- Start date
wildswing
Member
I've been having the same issue since upgradeing from 9.0 about a month ago. My Intouch nodes are P4 3.2 Ghz machines with 1Gb of ram, running XP Pros SP2 and IT v9.5 P3 and WW's DASABCIP DAServer v3.0 P1. IT v9.0 ran fine on the same machines. The only way to recover is a hard boot.
Have you contacted WW tech support? Do you have access to the WW tech support web site?
I've been dealing with my vender's tech support guys. Here's my understanding of the issue. It seems to be a memory allocation error. Something in Intouch called wwHeap needs a large congiguous block of memory. If that block gets filled or overflows you get the heap error.
Here's what we've gone through...
Their first suggestion was set the "load windows from disk" setting in the WindowViewer config (found in WindowMaker). This did not work. I still got heap errors.
They then suggested running WW's VMFinddHole.exe utility. Here's the tech note (topic t001058)...
http://www.wonderware.com/support/mmi/comprehensive/kbcd/html/t001058.htm
and the utility download itself...
http://www.wonderware.com/support/mmi/comprehensive/kbcd/Apps/VMFindHole.zip
If you can't get to those, ask your vender for copies. Here's a part of my vender's email message talking about the utility...
After doing the registry edit I could see the change in the SMC logger as Intouch started up...
FYI, one of the unedited machines crashed this morning. I was able to open Task Manager before rebooting to find that it's memory usage was about 460 Mb. After editing the registry and restarting, thememory usage was around 180 Mb. I don't think it's the registry edit that casued the lower memory usage, just the restart.
I need to follow up on something. When talking about the VMFindHole utility he mentioned the SmartHeapStartAddress in the alarmMgr key. In his 2nd mention of registry editing it talks about the MemoryRange value (an others) in the wwHeap key. I need to find out what the difference is. I'll report back.
Have you contacted WW tech support? Do you have access to the WW tech support web site?
I've been dealing with my vender's tech support guys. Here's my understanding of the issue. It seems to be a memory allocation error. Something in Intouch called wwHeap needs a large congiguous block of memory. If that block gets filled or overflows you get the heap error.
Here's what we've gone through...
Their first suggestion was set the "load windows from disk" setting in the WindowViewer config (found in WindowMaker). This did not work. I still got heap errors.
They then suggested running WW's VMFinddHole.exe utility. Here's the tech note (topic t001058)...
http://www.wonderware.com/support/mmi/comprehensive/kbcd/html/t001058.htm
and the utility download itself...
http://www.wonderware.com/support/mmi/comprehensive/kbcd/Apps/VMFindHole.zip
If you can't get to those, ask your vender for copies. Here's a part of my vender's email message talking about the utility...
the VMFindHole app will locate the start of a memory block that can be used by SmartHeap. It will then register the starting location (in hex) with the total memory found in the section I referred to earlier. If the section is not found the default value for the version will be used.
On my machine the location for the smart heap is as follows:
my Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wonderware\alarmMgr
with a setting of
SmartHeapStartAddress REG_DWORD 0x60000000 (1610612736)
If it does not exist add the DWORD 'SmartHeapAllocation' to the registry key HKEY_LOCAL_MACHINE/Software/Wonderware/AlarmMgr.
The value for this DWORD is the size of memory which SmartHeap will allocate. For 7.11 the default is 0x2000000 hex (= 32 MB). As mentioned earlier this can be increased to 1024 meg.
It didn't work for me, but I now think I was using it wrong. I probably wasn't asking it to reserve enough memory. It defaults to 32 Mb. I don't think I changed that. Had I asked for a large enough chunk it may have worked. I reported back that it didn't work. They replied with this...On my machine the location for the smart heap is as follows:
my Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wonderware\alarmMgr
with a setting of
SmartHeapStartAddress REG_DWORD 0x60000000 (1610612736)
If it does not exist add the DWORD 'SmartHeapAllocation' to the registry key HKEY_LOCAL_MACHINE/Software/Wonderware/AlarmMgr.
The value for this DWORD is the size of memory which SmartHeap will allocate. For 7.11 the default is 0x2000000 hex (= 32 MB). As mentioned earlier this can be increased to 1024 meg.
I have done a couple more searches through the closed calls (presumably support issues that have been addressed) to locate any references to wwheap. I found the following items:
1. How to create the memory Create a DWORD registry entry with the value 'MemoryRange' under the following key:
HKEY_LOCAL_MACHINE:Software\Wonderware\wwHeap
And set it to the maximum number of megabytes (MB) you want the Wonderware Memory Manager to allow.
The default value of 256 will be used if no registry value is present or the registry value is set to 0.
2. For some instances you may also have to put in a value in the InTouch.ini file as follows:
[InTouch]
MaxTimers=200
3. The InTouch 9.5 patch3 readme file has the following information:
Modifications to wwHeap capabilities:
1. You can configure range of the Wonderware Memory Manager (wwHeap) in 1 MB increments up to 1024 MB. If you set the range to less than 32 MB, a warning is written to the Log Viewer. Any value greater than 1024 MB is set to 1024 MB. wwHeap has a memory range default of 256 MB. This range is configured by a registry entry. You cannot change the range until wwHeap is completely reset, which means that all programs using wwHeap have been stopped.
2. You can choose whether wwHeap should start its search for free memory maps at the zero index or the most recently used index. This allows programs with smaller memory requirements to 'conserve' memory addresses, while those with larger memory requirements can be optimized to find available memory more quickly. The default behavior is to start the search at the zero index each time, as this is the original wwHeap behavior. You configure the setting is using the registry. You cannot change the value until wwHeap is completely reset, which means that all programs using wwHeap have been stopped.
3. When wwHeap is first started, it can read an optional .INI text file containing a list of reserved memory addresses into which it should never allocate memory. This helps to avoid heap share allocation errors with third-party modules that are not necessarily loaded at system startup. The .INI file's path is read from the registry.
The wwHeap configuration information is always written to the Log Viewer at least once when wwHeap is first accessed by any program. This provides a record of the wwHeap configuration for diagnostic purposes.
The default settings for wwHeap:
Memory range: 256 MB
Starting address: 0x21000000
Memory Conservation: Enable - Search for free memory starting at the beginning of the memory range
Memory reservation .ini file: DO NOT process .ini file
The settings for wwHeap:
Memory range: Create a DWORD registry entry with the value 'MemoryRange' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set it to the number of megabytes (MB), from 1 to 1024
Starting address: Create a DWORD registry entry with the value 'BaseOffset' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set it to the desired memory base offset. The start and end memory addresses are written to the Log Viewer.
Memory Conservation: To enable the efficient free-memory search algorithm, create a DWORD registry entry with the value 'ConserveMemory' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set the value to:
0 - efficient free-memory search (to cycle through the list)
1 - conserve memory (always start search at beginning of list)
Memory reservation .ini file: To enable the memory reservation, create a REG_SZ (string) registry entry with the value 'ReserveFilePath' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set the value to the full file path of the .ini file containing the desired memory reservation entries.
Create an .ini file with any name with the following content:
Any entries lower than the memory range or greater than the memory range are ignored.
[ReserveMemory]
; reserve memory range from 0x25000000 to 0x33450000
MEM00001=0x25000000-0x33450000
; reserve memory range starting at 0x45000000 for 8 - 64K blocks
MEM00002=0x45000000;8
; reserve memory range starting at 0x50000000 for 16- 64K blocks
MEM00003=0x50000000;16
; stop list processing
MEM00004=DONE
I did the MemoryRange registry edit only on half my Intouch runtime nodes. I had to create both the wwHeap key and MemoryRange value. I'm going to let them run for a while to see if it helps. It seems to take about 2 weeks for them to choke. If they're ok, then I'll do the rest.1. How to create the memory Create a DWORD registry entry with the value 'MemoryRange' under the following key:
HKEY_LOCAL_MACHINE:Software\Wonderware\wwHeap
And set it to the maximum number of megabytes (MB) you want the Wonderware Memory Manager to allow.
The default value of 256 will be used if no registry value is present or the registry value is set to 0.
2. For some instances you may also have to put in a value in the InTouch.ini file as follows:
[InTouch]
MaxTimers=200
3. The InTouch 9.5 patch3 readme file has the following information:
Modifications to wwHeap capabilities:
1. You can configure range of the Wonderware Memory Manager (wwHeap) in 1 MB increments up to 1024 MB. If you set the range to less than 32 MB, a warning is written to the Log Viewer. Any value greater than 1024 MB is set to 1024 MB. wwHeap has a memory range default of 256 MB. This range is configured by a registry entry. You cannot change the range until wwHeap is completely reset, which means that all programs using wwHeap have been stopped.
2. You can choose whether wwHeap should start its search for free memory maps at the zero index or the most recently used index. This allows programs with smaller memory requirements to 'conserve' memory addresses, while those with larger memory requirements can be optimized to find available memory more quickly. The default behavior is to start the search at the zero index each time, as this is the original wwHeap behavior. You configure the setting is using the registry. You cannot change the value until wwHeap is completely reset, which means that all programs using wwHeap have been stopped.
3. When wwHeap is first started, it can read an optional .INI text file containing a list of reserved memory addresses into which it should never allocate memory. This helps to avoid heap share allocation errors with third-party modules that are not necessarily loaded at system startup. The .INI file's path is read from the registry.
The wwHeap configuration information is always written to the Log Viewer at least once when wwHeap is first accessed by any program. This provides a record of the wwHeap configuration for diagnostic purposes.
The default settings for wwHeap:
Memory range: 256 MB
Starting address: 0x21000000
Memory Conservation: Enable - Search for free memory starting at the beginning of the memory range
Memory reservation .ini file: DO NOT process .ini file
The settings for wwHeap:
Memory range: Create a DWORD registry entry with the value 'MemoryRange' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set it to the number of megabytes (MB), from 1 to 1024
Starting address: Create a DWORD registry entry with the value 'BaseOffset' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set it to the desired memory base offset. The start and end memory addresses are written to the Log Viewer.
Memory Conservation: To enable the efficient free-memory search algorithm, create a DWORD registry entry with the value 'ConserveMemory' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set the value to:
0 - efficient free-memory search (to cycle through the list)
1 - conserve memory (always start search at beginning of list)
Memory reservation .ini file: To enable the memory reservation, create a REG_SZ (string) registry entry with the value 'ReserveFilePath' under the following key:
HKEY_LOCAL_MACHINE\Software\Wonderware\wwHeap
Set the value to the full file path of the .ini file containing the desired memory reservation entries.
Create an .ini file with any name with the following content:
Any entries lower than the memory range or greater than the memory range are ignored.
[ReserveMemory]
; reserve memory range from 0x25000000 to 0x33450000
MEM00001=0x25000000-0x33450000
; reserve memory range starting at 0x45000000 for 8 - 64K blocks
MEM00002=0x45000000;8
; reserve memory range starting at 0x50000000 for 16- 64K blocks
MEM00003=0x50000000;16
; stop list processing
MEM00004=DONE
After doing the registry edit I could see the change in the SMC logger as Intouch started up...
WWHEAP Base Address 0x21000000 End Address 0x41000000
WWHEAP Memory Range 512 MB (8192 Maps) Conserve Memory 1
whereas it used to say...WWHEAP Memory Range 512 MB (8192 Maps) Conserve Memory 1
WWHEAP Base Address 0x21000000 End Address 0x31000000
WWHEAP Memory Range 256 MB (4096 Maps) Conserve Memory 1
As an aside, after restarting the nodes where I did the registry edit, I wrote down the memory usage once Intouch and the daserver had started. All were around 180 Mb. I'll go back occassionaly and check to see if it's increasing. If it is, I may try that "load windows from disk" option again on a couple machines to see if it has any affect.WWHEAP Memory Range 256 MB (4096 Maps) Conserve Memory 1
FYI, one of the unedited machines crashed this morning. I was able to open Task Manager before rebooting to find that it's memory usage was about 460 Mb. After editing the registry and restarting, thememory usage was around 180 Mb. I don't think it's the registry edit that casued the lower memory usage, just the restart.
I need to follow up on something. When talking about the VMFindHole utility he mentioned the SmartHeapStartAddress in the alarmMgr key. In his 2nd mention of registry editing it talks about the MemoryRange value (an others) in the wwHeap key. I need to find out what the difference is. I'll report back.
Last edited:
Thanks for all the valuable information. After posting the question I got to reading the Intouch 9.5 SP3 information and it discussed the registery edits. I am planning on taking a test machine and try the registery edits to see what the results are. The environment that you described is almost identical to my situation with the exception of running the DASABCIP 3.0 P1. I have it installed on the machine as a generic build image, but am not communicating to any I/O with it for use in the applications in question. Thanks for keeping me up to date on your findings. I will do the same on my end as well.
Another thing that sometimes helps is to force View to recompile the windows and tag directory. For some reason, these will occasionally become corrupted and make the app start doing stupid things... I haven't seen this as much since about version 8, but prior to that it was a fairly regular occurence.
Close the application, then delete all *.avl and *.wvw files. These are the "working files" used during runtime. When you restart view, it will recompile them. It's also a good practice to occasionally go through and delete all *.??k files, too -- those are just backups of changed screens, scripts, etc. They're just excess baggage...
Close the application, then delete all *.avl and *.wvw files. These are the "working files" used during runtime. When you restart view, it will recompile them. It's also a good practice to occasionally go through and delete all *.??k files, too -- those are just backups of changed screens, scripts, etc. They're just excess baggage...
wildswing
Member
Here'a an update...
Raising the memory range did not help. It just took longer to crash. Changing to "load windows from disk" did not help. It turns out there's a memory leak in v9.5 if you enable the secondary source for an access name aka IO failover. WW has a hot fix. I haven't received it yet.
Raising the memory range did not help. It just took longer to crash. Changing to "load windows from disk" did not help. It turns out there's a memory leak in v9.5 if you enable the secondary source for an access name aka IO failover. WW has a hot fix. I haven't received it yet.
sundida
Member
You said there was going to be a hotfix. Do you know if this was included in patch 3 or sp1?
I have the same problem with computers crashing over time and lot's of blue screen of death errors. I'm running version 9.5 patch 3. The wonderware tech support has not been very helpfull on this issue. We have found there is a problem with some of the newer model Dell computers onboard soundcards (drivers) and playing wav files with wonderware. We had to replace sound cards and the blue screens have stopped. But I have computers that I see wwheap errors also. Your post just caught my eye because we are running secondary source for all access names.
Thanks
Darryl
I have the same problem with computers crashing over time and lot's of blue screen of death errors. I'm running version 9.5 patch 3. The wonderware tech support has not been very helpfull on this issue. We have found there is a problem with some of the newer model Dell computers onboard soundcards (drivers) and playing wav files with wonderware. We had to replace sound cards and the blue screens have stopped. But I have computers that I see wwheap errors also. Your post just caught my eye because we are running secondary source for all access names.
Thanks
Darryl
wildswing
Member
Hi Darryl,
Yes I installed the hotfix and it worked. I would assume that it's included in the next level patch. I have not upgraded yet.
To add to my prevoius note, I checked memory usage every day and it went up each time. After the patch there were no increases. Remember that this hotfix is only for the specific issue of a memory leak when using secondary access names. If you're not using them, it's not the same issue.
To get the hotfix you must sign a liability waver before they'll send you a copy.
Yes I installed the hotfix and it worked. I would assume that it's included in the next level patch. I have not upgraded yet.
To add to my prevoius note, I checked memory usage every day and it went up each time. After the patch there were no increases. Remember that this hotfix is only for the specific issue of a memory leak when using secondary access names. If you're not using them, it's not the same issue.
To get the hotfix you must sign a liability waver before they'll send you a copy.
Similar Topics
I want to monitor a couple signals in a place where there is no PLC but there is ethernet. I know I can use an AENTR or Flex I/O and a module but...
I thought it would be fun to ask what everyone's favorite cheap-er HMI is and favorite features. My favorite features are how easy are 1)...
Does anyone know of a cheap USB to ControlNet or USB to DeviceNet adapter (I'm looking for both).
I thought PLC Cable would have one but I did not...
I have Real PLC but I dont have a real system to have PID Control- any recommendation how can I build such a system- there are some PID trainer...
Cheap PLC that can read Data from its SD card or USB Flash Drive?
I'm looking for something in the price range of a Productivity 1000 ($180 for...