About ITHistExporter: Memory, Format Tracking, and Whether 32-bit Is Enough

Straight answers to the questions we hear most often

When engineers pick a tool for InTouch LGH export, a handful of concerns about ITHistExporter come up again and again: the 32-bit memory ceiling, whether a small vendor can keep up with AVEVA’s format changes, and how the tool compares against established commercial products. Two more questions often follow: how it handles corrupted files, and what about audit-trail compliance.

These are fair questions, and they deserve a factual, public answer — with numbers.

Concern 1: “InTouch LGH export hits a hard memory ceiling”

This is the most technical of these concerns, so let’s start with a correction, then look at real measurements.

The correction: the ceiling is 4 GB, not 3 GB

ITHistExporter32.exe is indeed a 32-bit (x86) executable — but it is compiled with the LARGEADDRESSAWARE flag. On 64-bit Windows, which is what virtually every plant PC runs today, an LAA-enabled 32-bit process gets a 4 GB user address space, not 3 GB. The 3 GB figure dates back to 32-bit Windows Server with the /3GB boot switch — a scenario that no longer describes modern field machines. The real ceiling for today’s 32-bit process on today’s 64-bit OS is one third higher than that.

Where the memory actually goes

The dominant memory consumer is the load stage: to analyse, preview or export a file, ITHistExporter parses every record of every tag into memory first (the on-disk file itself is read sequentially with buffered I/O). Parsing grows the footprint to roughly six times the file size — that is what the benchmark numbers below measure. The write side is streamed: CSV/JSON lines are written through buffered streams and the output never accumulates in RAM. Preview adds only a small extra copy on top, controlled by the preview limit — whether you preview or not does not change load memory.

The measurements

Our published benchmark results (single LGH file):

Read these numbers carefully, because they support a more nuanced conclusion than either “32-bit is fine” or “32-bit will crash”:

• A 220 MB LGH with 1,400 tags and 10 million records uses 1.45 GB. That is a heavy, real-world file — with every one of its 10 million records parsed into memory — and it still fits comfortably inside 4 GB.
• The 980 MB and 2 GB cases are multi-month, multi-year consolidation scenarios with 20,000 tags — exactly the extreme cases behind this concern. They do exceed any 32-bit process. We don’t pretend otherwise.

Concern 1b: So, is 32-bit enough for InTouch LGH export?

Why we still ship 32-bit in 2026

Because of what industrial plants actually run. InTouch nodes in the field still sit on Windows XP SP1, Server 2003, and 32-bit Windows 7 — machines that cannot run any 64-bit process at all. A 32-bit build is the only build that covers every Windows version from XP SP1 through Windows 11, which is why it remains the primary distribution. A native 64-bit build has been completed and will ship with the next major update, as an addition for extreme-scale workloads — not a replacement.

The real scale of LGH files

InTouch writes history into date-named files (the name carries date and hour fields), typically one file per day. A 220 MB single file already means ~1,400 tags at ~10 million records for that day. Most plants’ daily files are tens of megabytes. Parsed into memory a file grows to roughly six times its on-disk size, so the heavy ~200 MB day lands around 1.4 GB — generous headroom against a 4 GB address space, not a marginal fit.

There is also a hard physical ceiling worth knowing: InTouch itself caps a single LGH file at 2 GB (larger files make InTouch crash, and ITHistExporter rejects them up front). The single file is therefore the natural unit of memory — and its worst case is bounded by design, not unbounded.

When 32-bit does get tight — and what to do

The pressure case is a single file so heavy that its parsed footprint alone approaches 4 GB — several hundred MB on disk with tens of thousands of tags. Three practical answers:

1. Batch exports don’t accumulate memory. Multi-file exports are processed one file at a time — each file is loaded, written out, then released before the next is loaded. Exporting a whole year does not hold a year of data in memory.
2. Preview and filters don’t change load memory — or export completeness. Load memory depends on the file itself, not on the preview limit; limiting preview rows never limits, samples or loses exported data. Time and tag filters narrow the output, not the parse.
3. The 64-bit build is coming for the remaining edge: extreme single files (or full on-screen multi-year merges) whose parsed footprint alone exceeds 4 GB.

Concern 2: “A small vendor may not keep up with AVEVA’s format changes”

This concern is reasonable in the abstract — and it is best answered with the format coverage list:

• InTouch 5.0 (.LOG) — the earliest Wonderware history generation, from the mid-1990s, before the .LGH format existed (added in v3.5)
• InTouch 5.1b – 22.x (.LGH) — the classic 32-character-tagname format
• InTouch 2023 — 128-character tagnames
• InTouch 2023 R2 and later — the newest format

That is close to thirty years of format generations in one tool, from files older than some of the engineers reading this to the current AVEVA release. The track record is the strongest evidence available about how future changes will be handled.

It also helps to understand what kind of format this is. The core .LGH structure was introduced in the mid-1990s (InTouch 5.1b) and has stayed fundamentally stable since; AVEVA has extended it (longer tagnames, a new layout generation) rather than rewritten it. And because ITHistExporter depends on no InTouch runtime, no HistData utility, and no AVEVA components at all, format adaptation is a self-contained parsing task — not a race against someone else’s release cycle.

Concern 3: Corrupted files and compliance

Corrupted files. Field reality includes power cuts, full disks and broken indexes. Recent releases contain a steady stream of hardening fixes precisely for this class of problem: invalid record counts that would overrun arrays, truncated files, files written during InTouch version upgrades. The design principle throughout is: source files are opened read-only; damage is reported, never silently skipped or “repaired” — because silently dropping records in an incident investigation is worse than failing loudly.

Compliance (FDA 21 CFR Part 11 and similar). We will be direct: ITHistExporter is a read-only export utility, not a Historian replacement, and it does not provide an audit-trail system. What it does provide is untouched raw records — the verifiable input that validation and audit work actually needs. Every export tool, from any vendor, sits in this same position relative to Part 11; the honest framing is “lossless, read-only, raw data out,” not a compliance badge.

Concern 4: Commercial comparison — why would I pay for a small tool?

But there is one thing a small, focused vendor can offer that a large one often cannot: you can fully evaluate ITHistExporter free for 7 days — full functionality, your files, your worst case — before spending anything. The recommendation we make is not “trust us,” it is: run your heaviest LGH file through the trial and look at the numbers yourself. If the export completes, lossless, inside the memory and time you can afford, the vendor-size question loses most of its weight.

The bottom line

Impressions and hearsay are not test reports. We believe data beats predictions — so bring your heaviest file, and judge the tool by what it does with it.

Download ITHistExporter from wmkit.com and run it on your own files — free for 7 days, full functionality.

ITHistExporter — InTouch Historical Data Exporter https://www.wmkit.com