Wonderware West Tech Note 88_ Trouble-Shooting InTouch Application Corruption – Stand-Alone Applications _ Wonderware West

5/30/13 Wonderware West Tech Note 88: Trouble-Shooting InTouch Application Corruption Stand-Alone Applications | Wonderware West

www.wonderwarewest.com/?q=content/wonderware-west-tech-note-88-trouble-shooting-intouch-application-corruption--stand-alone-a 1/15

Username: Password:

Create new account Request new password

Wonderware West Tech Note 88:

Trouble-Shooting InTouch

Application Corruption Stand-Alone

Applications

Trouble-Shooting InTouch Application Corruption Stand-Alone Applications

Introduction

This Tech Note outlines the four most common types of stand-alone application corruption, gives

insight on identifying corruption in your own application, provides step-by-step instructions on

recovering an application, and contributes tips on preventing future application corruptions.

Types of Application Corruption

There are four common types of application corruption associated with stand-alone applications:

1. Tagname Database Corruption

2. Specific Window(s) Corruption

3. Window Element Corruption

4. History File Corruption

Indentifying Application Corruption

In general, if you have an application that has been operating appropriately for some time that

then begins to display odd behavior, you can suspect application corruption as the problem. This

Upcoming Training

06/04/2013

System Platform-

Application Server

Dallas, Texas

06/11/2013

System Platform-

Application Server

Houston, Texas

06/11/2013

InTouch for System

Platform

Dallas, Texas

06/11/2013

Historian and Historian

Client

Phoenix, Arizona

06/13/2013

Historian Client

Phoenix, Arizona

MOR E. . .

There are no upcoming w ebinars!

TRAINING

WEBINARS



is especially true if no recent changes have been made to the application and/or the application

has not been copied or moved to a new location.

Corruption is also a good educated guess if there has been a recent abnormal shutdown of the

system hosting the application (power outage, system crash, etc.), if there have been

communication hiccups across the network, or if the system is showing symptoms of hardware

problems/failures.

Finally, if you are distributing an application to clients over NAD and one client displays

unexpected behavior while the others operate normally, you can suspect local application

corruption.

Indicators of Tagname Database Corruption

There are several common application behaviors that suggest a tagname database corruption:

1. Cannot open or access the tagname dictionary from within WindowMaker.

2. Opening and/or navigating around the tagname dictionary dialog box causes WindowMaker

to hang or crash.

3. When viewing the tagname dictionary, some or all tags have unusual/garbage characters in

the tag name or description, or tags appear to be mis-assigned (i.e. system tags have the icon for

an alarm group tag).

4. Assertion errors when working within the tagname dictionary.

5. WindowMaker hangs or crashes during an Update Use Count or Cross-Reference

procedure.

6. When attempting to DBDump or DBLoad tags of an application, the operation fails.

7. Pop-up or Log Errors associated with tagname database corruption:

a. Error: Tagname.x is an out-of-date format or corrupted.

b. Error: "Read errors for the tagname dictionary. Corrupted tag database."

c. Error: Warning: Need to run DB.exe.

d. Error: Tagname.x corrupted.

e. Error: "INTSPT Error Reading entry 028A/0141" [the entry numbers may

vary].

f. Error: DB cannot be loaded. Are database files read only? or user has

read-only access?



g. Error: "Not enough Memory for DCT (AVLADD) ".

h. Error: Error reading tagname.ndx.

Indicators of Specific Window Corruption

Behaviors that suggest an InTouch Window corruption include:

1. Application will not open in WindowMaker, WindowViewer or both.

2. Elements in one window are misaligned or overlap, with other windows appearing normal.

3. WindowMaker and/or WindowViewer hangs or crashes only on opening or closing a

particular window.

4. Interaction with elements (animations, buttons, inputs, etc.) within a specific window in

Runtime causes WindowViewer to hang or crash.

5. While viewing a particular window, cannot fast-switch from WindowMaker to WindowViewer,

or InTouch crashes on fast-switch.

6. Data displays do not show appropriate values within a particular window.

7. Cannot import or export a window between applications developed on the same version of

InTouch.

8. Unable to delete a window from within WindowMaker.

9. Assertion or Unhandled Exception errors on window launching or closing.

10. Pop-up or Log Errors associated with a window corruption:

a. Error: Header messed up in FdRdKey....

b. Error: "Cannot open window file winxxxx.win."

c. Error: winxxxx.win file cannot be read.

d. Error: ReadError Unknown object type

Indicators of Window Element Corruption

Window element corruptions usually apply to special elements embedded within a window, like a

trend, .NET control, ActiveX control, etc.. You can suspect an element corruption if the element

does not operate as expected, a window hosting one of these elements hangs or crashes upon



opening, or if interacting with the element in WindowMaker and/or WindowViewer results in an

error, hang or crash.

Indicators of History File Corruption

If you are storing history in LGH files, your applications corruption may be related to one or more

of the LGH files. LGH file corruption can be suspected if trend objects are not working properly, if

LGH files stop being created, if you find LGH files that are 0KB in size or have an unusually large

size, or if one of your InTouch nodes hangs or crashes when connecting to a centralized LGH

storage location.

Some common error messages associated with LGH file corruption include:

1. Error: GPF in HD CBTREEVC.dll

2. Error: Invalid page fault in module: CBTREENT.dll

3. Error: "View caused an invalid page fault in module INTSPT.DLL

One final indicator of LGH file corruption is unusually high CPU usage by the HD.exe process, or a

hang or crash of this process.

Resolving Application Corruption

Some application corruptions are serious enough to require a rebuild of the application, but many

corruptions can be fixed without the need for rebuild. This section covers the various steps that

can be taken to resolve application corruption before resorting to a full rebuild of the application.

1. Perform a Forced Recompile of the application.

Often an application corruption is not inherent to the applications development files, but

instead specific to the compiled version of these files. Deleting the compiled versions of

the development files forces the application to recompile them fresh.

Step 1: Access the directory in which your application files are located. You can find the

location of this directory in the InTouch Application Manager. The path shown in the

following image is the default location for InTouch applications; your application may have

a different location.

Step 2: Once in the directory, delete the following files:

- All *.wvw files

- All retentive.* files



- The tagname.avl file

NOTE: Your application may not have all of these files.

Step 3: Close the application directory and launch the application in WindowViewer. The

application will take longer than usual to open because all of the windows must be freshly

recompiled. Test to see if the corruption behavior persists or has been resolved.

2. Replace the application with a recent backup.

If you are a conscientious developer, you make a backup of your application at regularly

scheduled intervals, as well as each time you make a change. With a stand-alone

application, backing up the application is as simple as making a copy of the entire

application directory and storing it in a safe location. Replacing a corrupted application

with a recent backup of the application can resolve the corruption.



following image is the default location for InTouch applications; your application may have a

different location.

Step 2: Rename the application directory to identify it as the corrupted application. For

example, if your application is named MyApplication, rename it to MyApplication

Corrupt.

Step 3: Browse to the location of your recent backup of the application directory and copy

the entire directory.

Step 4: Return to the location where your corrupted application is stored and paste the

backup directory in the same location. Rename the backup directory to the original

applications name. For example, using the same names in step 2, rename MyApplication

backup to MyApplication.

Step 5: Open the application in WindowMaker, then WindowViewer to see if the corrupted

behavior persists or has been resolved.

Resolving Specific Corruption Types



If the Forced Recompile does not resolve the corruption, and you do not have a viable, recent

backup of your application, there are still procedures that can be followed to fix an application

without resorting to the full application rebuild. The following section covers the resolution of

specific corruptions, based on whether the corruption is in the tagname database, in a window,

with a window element, or a corrupt history file.

Resolving Tagname Database Corruptions

If you have determined that the corruption your application is experiencing is related to the

tagname database, try the following suggestions to resolve:

1. Download and run the Tagname Database Repair Utility.

The Tagname Database Repair utility will fix some, but not all, tagname database

corruptions. The utility sifts through your tagname database and deletes any duplicate

tags, tags with corrupted characters, etc.. You can download this utility from this location:

ftp://ftp.wonderwarewest.com/Wonderware/Wonderware_Utilities/TagDBRepair.zip

Username: customer

Password: support

If errors are found and fixed by the Tagname Database Repair utility, close the utility and

run the application in WindowMaker, then WindowViewer, to see if the corrupted behavior

persists or has been resolved.

2. Replace the tagname.x file with its associated backup file.





Step 2: Once in the directory, locate the tagname.x and tagname.xbk files.



The tagname.x file is the flat file in which all of your tagname configuration information

is stored. Each time an application launches successfully, a backup of this file - titled

tagname.xbk - is created or updated. You can use this backup file to replace the

corrupted database with the last working version of the database.

Step 3: Rename tagname.x to tagname.xold.

Step 4: Rename tagname.xbk to tagname.x.

Step 5: Launch the application in both WindowMaker and WindowViewer to see if the

corruption has been resolved.

Resolving Specific Window Corruptions

Generally if you have a corruption of a specific window(s), the first step is to identify which

window(s) is problematic. The most efficient way to do this is to use the ww_wdws.ndx file to limit

which windows are pre-loaded into WindowMaker, then through a process of elimination determine

which window is corrupted.





Step 2: Once in the directory, locate the ww_wdws.ndx file.



Step 3: Right-click on the ww_wdws.ndx file and select Open With. You will then be

presented with a dialog box to select the program with which you want to open the

ww_wdws.ndx file. Select Notepad.

Step 4: Once opened in Notepad, you can see that the file shows a list of all windows

associated with your application, giving the window number and window name. Use the

File > Save As menu option to save a backup of this file in a safe location.



Note that these windows correspond to the windows listed in WindowMaker for your application,

though not necessarily in the same order. Based on the list in the ww_wdws.ndx file, each window

is pre-loaded into WindowMaker so it is accessible should you want to work with it.

Step 5: Make sure WindowMaker and WindowViewer are closed. In the original

ww_wdws.ndx file, delete approximately half of the windows listed and save the changed

file.



Now if you opened WindowMaker, you would see that the windows you deleted in the

ww_wdws.ndx file are no longer in the windows list. This is because those windows are

NOT pre-loaded into WindowMaker. The window files still exist in the application directory,

but they are not loaded into WindowMaker.

Step 6: With only half of the windows preloaded into WindowMaker (which also means only

those windows will be pre-loaded into WindowViewer), try to reproduce the corrupt

behavior. If the behavior persists, you know that the problematic window is one of those

left in the ww_wdws.ndx file. Now you can reduce the windows pre-loaded by half again

and repeat this process as many times as needed to narrow down to the exact window

causing the problem.

If the behavior does NOT persist, then you know the problematic window is one of those

that you eliminated from the ww_wdws.ndx file. Add those window entries back to the

ww_wdws.ndx file, delete the window entries you know are good, and repeat this process

until you are able to narrow down to the exact window causing the problem.



Once you have determined which window is corrupted, you can now either delete the window

entirely and rebuild it from scratch, delete the window and import the corresponding window from a

recent application backup, or if it will open in WindowMaker start incrementally copying and

pasting elements and scripts associated with the corrupted window into a new window, testing the

new window after each change, until you determine exactly which element/script is the source of

the corruption.

Resolving Window Element Corruptions

Sometimes the source for corruption in a window is corruption of a special element, like a trend

control or other ActiveX control. You can test for this by dropping the suspect control into a new

window, configuring it like the original then testing to see if it works. For example, if you have a

window with a trend that was working, but now does not, create a new test window and drop in the

same trend control, configure it how the original is configured, and see if it trends correctly. If the

test trend works, you then know you can resolve the corruption by simply replacing the control in

the original window and reconfiguring it.

Resolving History File Corruptions

You can confirm that your applications corruption is related to a corrupt LGH file by temporarily

moving all LGH files from their storage location and testing to see if the corrupted behavior

persists.

Locating your LGH Files

Open your InTouch application. In the top menu, go to Special > Configure > Historical Logging

to open the Historical Logging Properties dialog box.



If Store Log Files in Application Directory is selected and there is no node specified in the Name

of Logging Node input field, your historical LGH files are located in your LOCAL InTouch

application directory.

If Store Log Files in Application Directory is selected and there is a node specified in the Name

of Logging Node input field, your historical LGH files are located in the InTouch application

directory on the specified node.

If Store Log Files in Specific Directory is selected, the LGH files will be found in the directory

specified. This can be either on the local node or a remote node, depending on whether a node is

specified in the UNC path of the storage location or in the Name of Logging Node input field .



Testing your LGH Files

Once you have determined the location of your historical LGH files, now you can use a process of

elimination to determine which files are corrupted.

Step 1: Access the directory in which your LGH files are stored.

Note the naming convention for these files, based on the date for the information being stored

yymmdd00.lgh. Each LGH also has an associated index file yymmdd00.idx

Step 2: Select all of the LGH and associated IDX files and move them to another location. For

example, move them into a folder on your desktop.

Step 3: Test your application to see if the corrupted behavior persists. If the problem is resolved,

you can be relatively sure the source is a corrupted LGH file. Move on to step 4. If the problem is

not fixed, the issue is likely not related to the LGH files and you should consider other origins.

Step 4: Incrementally begin re-adding the LGH files, always with their associated IDX files, back



into the storage directory, a few at a time and` testing the application after each move. When the

corrupted behavior returns, you know one of the LGH files last moved into the storage directory is

corrupted.

Step 5: The corrupted LGH file and its associated IDX file should be removed from the storage

directory permanently.

Rebuilding Your Application

If none of the above procedures resolve the corruption of your application, a full application

rebuild is indicated. You can get instructions on rebuilding a corrupt, stand-alone, application from

a Tech Note viewable at the following link:

http://www.wonderwarewest.com/content/tech-note-112-recovering-corrupted-intouch-application

NOTE: The above-linked Tech Note applies to STAND-ALONE applications only. For

instructions on rebuilding a MANAGED application, refer to the following Tech Notes:

Rebuilding a Corrupted InTouch Managed Application (for versions prior to InTouch

10.0 SP2)

Rebuilding a Corrupted InTouch Managed Application for InTouch versions 10.0 SP2

(for versions later than InTouch 10.0 SP2)

Preventing Application Corruption

A good way to prevent corruption of your application is to have a Best Practices document

distributed to all developers and operators that outlines proper procedures for handling your

application. This document should include the following:

1. Application Backup Procedures. It is recommended that you schedule backups of your

application on a regular basis, in addition to making a backup each time the application is

changed.

2. Tagname Database Backup Procedures. In addition to backing up the application files, it is

a good idea to run a DBDump procedure on your application each time changes are made to the

tagname database. Tags are the heart of your application. Take care of them!

3. Shutdown Procedures. Often corruptions occur as a result of improper system shutdowns.

While these cant always be avoided (system crash, power outage, etc.), users of your application

should know to never shut down the application via the Task Manager or by rebooting the

machine.



Copyright 2008 - 2013 Wonderware West

4. Computer Maintenance Procedures. Corruptions can occur as a result of failing hardware.

It is important to have a thorough computer maintenance policy.

5. Procedures for copying/moving an application. An application and all of its files should

always be treated as a single entity. It is never recommended to move individual files from one

applications directory to another, even if they are copies of the same application. For example, if

your tagname dictionary is irretrievably corrupted, you cannot move just the tagname.x file from a

backup into the corrupted application directory. You must replace the application as a whole with

the backup application.

Also, it is a good practice when moving an application between computers (i.e. from the

development system to a runtime system) to have the computers as similar as possible with regard

to regional settings.

6. Application Maintenance Procedures. Changes should never be made to an application

through the application directory. For example, if you wish to delete a window, you should open

the application in WindowMaker and delete the window through the WindowMaker interface. You

should never delete a window by simply deleting the window files in the application directory. The

only supported method for deleting, modifying or adding to the application is through

WindowMaker.

Written by: Tonya Welch

7/2/2010

Terms of Use Privacy Statement Contact Us Sitemap

Documents

Wonderware West Tech Note 88_ Trouble-Shooting InTouch Application Corruption – Stand-Alone Applications _ Wonderware West