Resolving ProTool Pro Error E3499: Array Protocol Data Failure

Problem Details: ProTool Pro V6 SP2 Compile Failure E3499

Siemens ProTool/Pro V6 SP2 (and the related ProTool V6.0, ProTool/Lite V6.0, and ProAgent V6.0 packages) emits the following internal compiler error when an HMI project containing one or more screen objects bound to array tags is rebuilt:

The three numeric values in parentheses are Siemens-internal token IDs that identify which protocol object, screen instance, and field reference the compiler was attempting to resolve at the moment of failure. The "63" prefix designates a specific protocol driver, "918" is a screen/item index, and "-1" is a sentinel meaning the driver returned no usable protocol descriptor block. Because the error is raised from deep inside the PTKRNL32 runtime library and the ProTool.exe compile engine, the GUI presents no screen-level context, no line number, and no call stack. The user is typically left with three options only: delete the screen, delete the project, or attempt to repair the .pdb / .ldb source pair.

Symptom matrix observed in field installations (Windows XP SP3, Windows 2000 SP4, Windows NT 4.0 SP6a):

Affected Software Versions and Build Numbers

The E3499 defect class has been observed in the following Siemens installation IDs and Service Packs. Service Pack 1a is the last published public update for the V6.0 product line and is available from the Siemens Industry Online Support portal under entry ID 11772575 - Downloads for ProTool/Lite, ProTool, ProTool/Pro V6.x:

The error is platform-agnostic within the V6.x line; it has been reported on OP3, OP7, OP17, OP27, OP37, OP170B, OP270, MP270, MP370, and the early TP170A / TP270 touch panels that ProTool/Pro was licensed to configure. It also reproduces inside the ProTool Integrated Simulation runtime (started from the Start -> Simulation menu) and during the Compile -> Generate Source Files batch mode used by automated build systems.

Root Cause Analysis

The compiler pipeline in ProTool/Pro V6.0 SP2 splits a project build into four stages: (1) tag resolution, (2) screen tree walk, (3) protocol descriptor emission, and (4) panel-specific image generation. Stage 3 emits a binary protocol descriptor per screen object; this descriptor tells the runtime which tag addresses, array indices, and limit values belong to each HMI element. E3499 is raised when stage 3 receives a request for protocol data on a screen instance for which stage 1 produced no tag descriptor, even though a tag symbol exists in the tag table.

The proximate cause is a desynchronization between the tag table (tag.pdb), the screen tree (screen.pdb), and the protocol index (prot.idx). This desynchronization is typically introduced by one of the following operations:

1. Deleting an array tag from the tag table while screens that reference the array element are still open in the editor.
2. Renaming an array tag's symbolic name without using Tag -> Rename (with cross-reference update).
3. Importing a tag table from a CSV / .asc export whose row count does not match the array's declared upper bound.
4. Cutting and pasting a screen object group that contains array-bound fields between two panels with different array index base settings (0-based vs 1-based).
5. A power-loss or kill-process event during a previous Compile pass that wrote a partial prot.idx block.
6. Version mismatch: opening a ProTool/Pro SP2 project on a workstation that still has SP0/SP1 installed and re-saving it.

The token (63, 918, -1) is interpreted as follows in the internal log file %TEMP%\PT_Trace.log (enable with Menu -> Options -> Trace -> Extended):

• 63 — Driver class index for the SIMATIC S7 MPI/DP protocol family.
• 918 — Screen/item table slot; 918 is well past the first 200 slots, indicating the issue is in a screen deep in the project's tab order.
• -1 — Negative-one sentinel: no protocol descriptor was generated for the requested instance. A valid descriptor would carry a non-negative offset into prot.idx.

Pre-Diagnosis: Stabilize the Project

Before isolating the corrupt screen, freeze the project state so the binary search described below is reproducible:

1. Close ProTool/Pro and confirm the WINPROT.EXE and PTKRNL32.EXE processes have exited (check Task Manager).
2. Make a full backup of the project directory: xcopy /E /I /Y "C:\PRJ\<project_name>" "E:\Backup\<project_name>_pre_E3499_YYYYMMDD\"
3. Disable antivirus on-the-fly scanning on the project directory and on %TEMP%; the ProTool build engine opens prot.idx with FILE_SHARE_NONE and any real-time scan will corrupt the file mid-write.
4. Disable the screen saver and standby/hibernation timers on the engineering station. A screen-saver activation during a long compile is a documented cause of stage-3 corruption.
5. Open the project once, perform Project -> Save As to a new folder, and close. This forces ProTool to rewrite every .pdb and may clear the desynchronization without further work. If the resaved project compiles cleanly, the original issue was a transient index corruption and no further action is required.

Diagnostic Procedure: Binary Search Isolation

If the resave does not resolve E3499, isolate the failing screen with a binary search across the screen list. ProTool/Pro stores screens in display order, and the project file screen.pdb keeps a sequential index. The search exploits the fact that E3499 is a compile-time failure: removing the offending screen makes the error disappear, while keeping it in the project reproduces it.

1. Copy the project folder to <project>_halfA and <project>_halfB.
2. In halfA, open the project, select screens 1 through N/2 in the project navigator, and delete them. Save and close.
3. In halfB, delete screens N/2+1 through N. Save and close.
4. Compile halfA. If E3499 does not appear, the failing screen is in the deleted upper half. If E3499 does appear, the failing screen is in the deleted lower half.
5. Take the half that still contains the error and split it again (1/4, 3/4). Repeat until a single screen is isolated.
6. The isolated screen is the one whose array-bound fields triggered the protocol-descriptor failure.

For a project with 80 screens, this search converges in ceil(log2(80)) = 7 iterations, taking roughly 20 to 40 minutes including compile times of 30-180 seconds per iteration. The process is mechanical, requires no scripting, and is the field-proven workaround that end users discovered before Siemens Customer Support acknowledged the issue.

Recovery Steps for the Isolated Screen

Once the failing screen has been identified, use one of the following recovery options in order of preference:

Option A: Recreate the screen (preferred)

1. Export the tag bindings of the failing screen to a CSV using Screen -> Export Tag List (note: this option is undocumented in the V6.0 manual but is accessible via the right-click menu in the cross-reference editor).
2. Delete the failing screen from the project.
3. Insert a new screen with the same name and number.
4. Re-create the array-bound fields. For each array field, first create the field as a single-element tag, compile, then change the field's Array attribute to point to the array — this two-step write forces ProTool to emit a fresh protocol descriptor for the new instance.
5. Compile incrementally (one screen at a time) to confirm the new screen is clean.

Option B: Strip and re-add array bindings

1. On the failing screen, open every field that references an array tag.
2. Change each field's tag reference to a scalar placeholder tag (e.g., _tmp_scaler) and save.
3. Compile. The compile must succeed with the placeholder references; if it does not, the failing screen also has non-array corruption and Option A is required.
4. Re-bind the array tag to each field one at a time, saving and compiling after each re-binding.
5. The field that re-introduces E3499 on re-binding is the precise element to redesign (typically a limit-value violation, an unsupported array dimension count, or a tag whose Length attribute exceeds the panel's memory budget).

Option C: Send to Siemens Customer Support for repair

Siemens SIMATIC Customer Support operates an internal ProTool/Pro Repair Tool — analogous to the WinCC flexible Repair Tool and the S7-GRAPH Repair Tool that have been made available as public downloads. The ProTool/Pro Repair Tool is not released to end users; it must be invoked by a Siemens support engineer. The standard procedure is:

1. Open a support request at Siemens Industry Online Support (entry category: HMI software -> ProTool/Pro V6.0).
2. Attach the zipped project (use 7-Zip or PKZip — do not use the Windows ZIP handler, as ProTool/Pro is sensitive to \ vs / in archive paths).
3. Include the contents of %TEMP%\PT_Trace.log from a session where E3499 was reproduced with Extended Trace enabled.
4. Siemens will return either a repaired project or a .rep file that can be merged via Project -> Import -> Repair File.

This path is not always practical for field engineers: uploading a 20-200 MB project from a customer site with limited bandwidth is slow, and the round-trip can take 3-10 business days. The binary search + recreation workflow (Options A and B) is the operationally realistic answer for live plant situations.

Verification: Confirming the Project is Clean

After the failing screen is repaired, run the following four-step verification cycle. All four steps must pass before the project is declared site-ready:

If step 1 still raises E3499, the binary search must be repeated — there may be two or more failing screens (compound desynchronization is rare but documented in projects with more than 100 screens).

Project Hygiene to Prevent Recurrence

The most effective prevention is process discipline around three ProTool/Pro build-time operations that are known to trigger E3499:

1. Always use Tag -> Rename with the cross-reference update checkbox enabled. Direct edits to tag.pdb in a text editor (technically possible, since the file is a flat ASCII table in SP2) bypass the cross-reference rewriter and re-introduce desynchronization on the next compile.
2. Decrement the tag table before the screen tree when archiving. When versioning a project, keep the tag table under version control in a separate file (tag.pdb) and the screen tree in a separate file (screen.pdb). A single .zip archive of the project should be the build artifact, not a working copy.
3. Run Project -> Consistency Check after every bulk tag import. The consistency check re-issues stage 1 of the compiler pipeline without generating the panel image, so it is fast (5-30 seconds for 100 screens) and surfaces most precursor E3401 / E3491 / E3498 errors before E3499 is raised.
4. Disable Windows file-system compression on the project directory. ProTool/Pro V6.0 SP2's prot.idx writer assumes the file is uncompressed; NTFS compression changes the cluster size and produces intermittent E3499 errors that look like array bugs but are actually storage-layer corruption.
5. Match the engineering station's ProTool/Pro SP level to the project's history. If a project was last saved on SP0, do not open it on SP3 without first installing SP3 and running Project -> Save As in a clean SP3 environment. The reverse direction (SP3 project on an SP0 station) is a guaranteed E3499 trigger.

Migration Path: From ProTool/Pro to WinCC Flexible and TIA Portal

ProTool/Pro V6.0 SP2 is a legacy product. The successor toolchain is WinCC flexible 2008 SP5 (the last release of the WinCC flexible line) and then TIA Portal WinCC (TIA V19 / V20). Siemens provides a migration utility — ProTool/Pro -> WinCC flexible Migration Tool — that converts a ProTool/Pro project into a WinCC flexible .hmi project with the following caveats for array-bound screens:

• Array tag definitions are preserved 1:1, but the array element type in ProTool/Pro is WORD by default; WinCC flexible expects an explicit INT or REAL. The migration tool will silently upcast WORD to INT, which can change the panel memory budget.
• Screen objects that were the original E3499 trigger in ProTool/Pro typically compile cleanly in WinCC flexible because WinCC flexible's compiler uses a different protocol-descriptor layout (the E3499 class does not exist in WinCC flexible). However, the underlying array binding problem may resurface as WinCC flexible warning W0942: Tag array has no matching PLC address.
• For TIA Portal, arrays are handled by PLC tag consistency checking rather than by the HMI compiler. The E3499 defect class is therefore eliminated at the architecture level when migrating to TIA Portal, provided the project uses the PLC tag table as the single source of truth rather than a separate HMI tag table.

For a 100-screen ProTool/Pro project with array tags, plan a 2-4 week migration window including the time to re-validate every array-bound field on the panel.

Related Internal Errors and How They Differ

E3499 is rarely the first error raised. The compiler stops at the first E-code it encounters, so the engineer must distinguish E3499 from its precursors:

If E3401 is present, fix it first and recompile — E3499 may vanish, because the stage-3 walk is skipped when stage-1 errors are unresolved.

Field Commissioning Checklist for E3499-Resilient Builds

Use this checklist on site before any on-line change to a ProTool/Pro project that contains array tags:

1. Confirm the engineering station runs the same ProTool/Pro SP as the one that last saved the project offline.
2. Copy the existing online project to the engineering station via File -> Transfer -> Backup -> to PG rather than from the project archive.
3. Enable Extended Trace and capture PT_Trace.log from the session that produced the field bug report.
4. Run Project -> Consistency Check and record the warning count.
5. Run Project -> Compile -> All and record the warning count.
6. Compare the engineering-station prot.idx MD5 hash to a known-good baseline; if the hash differs without intentional change, treat the project as suspect and do not download.
7. Perform the binary search procedure on the engineering-station copy, not on the live on-line project. Never delete screens on a live panel.
8. After repair, run the four-step verification cycle (clean compile, cross-reference, simulation, transfer dry-run) before connecting to the panel.

Frequently Asked Questions