histsdk/docs/reverse-engineering/wcf-historian-info.md

GetHistorianInfo over 2020 WCF — GETHI is named-value-only (HCAL R1.4)

Status: ⛔ Bounded out on BOTH 2020 WCF and 2023 R2 gRPC (2026-06-20; gRPC live-confirmed 2026-06-21). GetHistorianInfoAsync is not shipped on any transport: the one field that motivates it — EventStorageMode — is not on the wire on either transport (it lives only in the C++ HCAL's in-memory 518-byte struct, filled via a native vtable+648 call — see the §gRPC conclusion below). The version field GETHI does return is already exposed (ProbeAsync, GetRuntimeParameterAsync("HistorianVersion")), so there is nothing new to ship. Note: R1.3 (GetServerTimeZone) — once paired with this as "2023R2-only" — diverged: it returns a real value over gRPC and shipped 2026-06-21 (GetServerTimeZoneAsync); R1.4 did not.

What the capture showed

scripts/Capture-HistorianInfo.ps1 drives the native HistorianAccess.GetHistorianInfo(out HistorianInfo, out error) through the instrumented (instrument-wcf-{write,read}message) current/aahClientManaged.dll. The native call succeeds and returns EventStorageMode = Blocks, ServerVersion = 20,0,000,000, no error.

But the wire tells a different story (scripts/decode-historian-info-capture.py):

• The only GETHI op on the wire is aa/Stat/GETHI(handle, pRequestBuff) with pRequestBuff = 53 67 02 00 (sig 0x6753 + version 2) + uint charCount(16) + UTF-16 "HistorianVersion" — i.e. the named-value request, identical to the GETRP/version shape.
• Its response pResponseBuff is ~30 bytes: uint charCount(12) + UTF-16 "20,0,000,000" (+ a 02 00 01 00 trailer). Just the version — not a 518-byte struct.
• The post-GETHI ops in the same capture are Hist/UpdC3 + a run of Stat/GetSystemParameter (AllowOriginals, HistorianPartner, HistorianVersion, MaxCyclicStorageTimeout, RealTimeWindow, FutureTimeThreshold, AllowRenameTags). None carries a storage-mode value. So the native wrapper's EventStorageMode is derived by the C++ HCAL outside the WCF wire, not fetched over it.

Probe: does GETHI expose storage mode under any name?

StringHandleProbeDiagnosticTests.GETHI_CandidateInfoNames_AgainstLocalHistorian (gated on HISTORIAN_HOST=localhost) issues GETHI for HistorianVersion plus seven storage-mode name guesses. Result on the live 2020 server:

GETHI parameter name	result
HistorianVersion	ok=True, respLen=32 (version)
EventStorageMode, EventStorageType, StorageType, HistorianEventStorageMode, EventStorage, StorageMode, HistorianInfo	ok=False, errLen=5, empty

So GETHI on 2020 WCF is a strict named-value lookup with exactly one known-good key (HistorianVersion). There is no storage-mode key, no full-struct request.

Why the 518-byte struct doesn't apply here

The 2023 R2 decompiled ArchestrA.HistorianAccess.GetHistorianInfo (analysis folder) allocates a 518-byte HISTORIAN_INFO struct, pre-inits int32 @514 to -1, calls native HCAL (vtable+648) which fills it, then reads version (UTF-16 @0) + EventStorageMode (@514: -1=Unsupported, 0=Database, else=Blocks). That is the HCAL-native / 2023R2 gRPC front-door model (StatusService.GetHistorianInfo returns bytes btHistorianInfo). On 2020 WCF that struct is never marshaled across the wire — only the version named-value is. The native client's EventStorageMode therefore comes from C++-internal state the managed WCF replay cannot observe or reproduce.

Conclusion / where it lands

• 2020 WCF: GetHistorianInfoAsync would add nothing over existing surface (version only) and could not report a real EventStorageMode — so it is intentionally not shipped (no hollow Unsupported-returning API; project discipline: don't ship misleading behavior).
• 2023 R2 gRPC — LIVE-PROBED 2026-06-21, also bounded out. The earlier expectation that Status.GetHistorianInfo returns the full 518-byte btHistorianInfo over gRPC was wrong. On the real 2023 R2 server (History iface 12), the gRPC GetHistorianInfo is the same named-value query as 2020 WCF: only HistorianVersion resolves (→ "23,1,000,000" + 02 00 01 00 trailer); EventStorageMode and seven name variants return success=false on both GetHistorianInfo and GetSystemParameter. The 518-byte struct is not on the gRPC wire — the 2023 R2 decompile confirms managed HistorianAccess.GetHistorianInfo fills it via a native vtable+648 HCAL call (IClientCommon* + offset 648), not the gRPC op, so EventStorageMode is derived inside the C++ HCAL outside the wire on gRPC exactly as on WCF. Conclusion: GetHistorianInfoAsync is not shipped on any transport (the only wire-reachable field, version, is already exposed). No HistorianInfo / HistorianEventStorageMode public type was added. Probe: the (now-deleted) GrpcStatusInfoProbeTests; raw dump under artifacts/reverse-engineering/grpc-status-info-probe/ (gitignored).

Tooling kept as RE aids

• tools/AVEVA.Historian.NativeTraceHarness historian-info scenario (drives the native call).
• scripts/Capture-HistorianInfo.ps1 + scripts/decode-historian-info-capture.py.
• StringHandleProbeDiagnosticTests.GETHI_CandidateInfoNames_AgainstLocalHistorian (locks the named-value-only finding; gated).