What's new in ViewAlyzer

Published releases, compatibility changes, and the steps to take before upgrading your viewer, firmware recorder, or automated tests.

ViewAlyzer 1.4.0 — November 9, 2026

This release includes all changes since the last public release, 1.3.1. Version 1.3.2 was not published; its improvements and compatibility changes are included here. The desktop app, CLI, recorder, and ViewAlyzer VS Code extension are version 1.4.0. The accompanying BKPT Debug extension is version 0.5.0.

Highlights

• Inspect a live recording. Zoom, pan, or pin a time in Timers, Comms, Timeline, and Event Table while capture continues. Return to Live to follow incoming data at your selected time width.
• Find and investigate problems. Search Analyzer findings, filter by recorded object, and navigate from fingerprint comparison findings to the relevant objects and metrics.
• More trustworthy measurements. CPU totals account for nested interrupts without double-counting. Stack sizes use usable bytes; heap measurements distinguish occupancy from capacity. Timer analysis separates requested starts, actual arms, observed expiries, and callback durations.
• Better handling of incomplete traces. Deleted objects cannot retain inferred ownership or complete later operations. Lost events and unknown measurements remain visible instead of becoming misleading zeroes or successful comparisons.
• Smoother inspection and reconnects. Live histories stay bounded, repeated analysis is reduced, and polled values remain available when attaching without reset. Connection configurations retain their ELF, MAP, and SVD selections.

Compatibility at a glance

Missing or invalid recorder clocks, clock changes, and recorder restarts inside a single recording now produce explicit errors. Reattaching within the same recorder session remains supported. A changed result after upgrading can reflect corrected measurement definitions; it does not by itself prove that your firmware became slower.

Firmware integration checklist

Rebuild with the complete matching recorder and RTOS adapter sources. Existing application instrumentation may carry over, but this is not a blanket source-compatibility guarantee for custom hooks or adapters.

• Custom adapters: task and synchronization IDs are now 16-bit. In particular, custom mutex-contention adapters must accept a uint16_t ID. Update code that assumes one-byte IDs or fixed packet layouts.
• FreeRTOS heap tracing: set VA_FREERTOS_HEAP_SCHEME to the heap implementation you actually link. The default 0 and heap_3 retain failure reporting but leave pool usage and capacity unknown. With heap_5, use VA_FreeRTOSDefineHeapRegions() to supply usable capacity.
• Zephyr: recording requires CONFIG_SMP=n. Mutex tracing needs the thread registry for actor identification. Timer tracing also needs task registry metadata for caller attribution.
• Interrupt context: do not call recorder APIs from NMI or HardFault with the default PRIMASK critical section; those writes cannot be serialized safely. ThreadX ISR wrappers ignore these exceptions.
• RAM sizing: VA_MAX_TASKS and VA_MAX_SYNC_OBJECTS size live or retained registries, independently of the 65,535 numeric IDs. More detailed lifetime and timer tracking can add state; review your enabled categories, capacities, and linker map after rebuilding. There is no single RAM increase that applies to every firmware configuration.

Automation migration

• Fingerprints: metric semantics are version 2. New baseline files normally use schema 2; per-option compatibility exceptions use schema 3. These are separate from the CLI envelope's schema 3. Old baselines with earlier or missing metric semantics must be rebuilt, including outside strict CI mode.
• Comparison exit codes: 0 means pass or warn, 1 a command/input error, 2 a metric regression, 3 incomparable provenance, and 4 invalid measurement. query compare --ci requires an explicit baseline policy and usable capture evidence. Treat incompatible or invalid measurements as rejected runs, not passing tests.
• Capture streaming: use the unique channel key and metadata namespace to distinguish equal source IDs. Handle stream_time_shift by shifting previously received samples in the named channels when early polls acquire a recorder-clock offset. The standalone poll stream retains its ID-based contract.
• Hardware observations: native probe read bounds and clock provenance remain distinct from estimated chart coordinates. Update consumers that treated every hardware sample as an exact timestamp on the recorder clock.

Read the fingerprint walkthrough, CI comparison guide, and VADB reference before updating custom automation. Use the capture-stream migration example below when adapting your own live consumer.

Capture-stream migration example

For capture --stream, index metadata and samples by channel, not id or display name. This example handles already-parsed JSON events for a bounded capture. It stores sample coordinates in nanoseconds so delta_ns can be added directly; incoming t_us values must first be multiplied by 1,000. A correction applies only to samples already received, not future samples. Chart coordinates remain estimates.

metadata = {}
samples = {}

def accept_capture_event(event):
    kind = event["t"]
    if kind == "stream_init":
        if event["schema_version"] != 3 or event.get("source") == "poll":
            raise ValueError("This consumer expects the schema-3 capture stream")
        metadata.clear()
        samples.clear()
    elif kind == "stream_meta":
        metadata[event["channel"]] = event  # preserves namespace and source id
    elif kind == "stream_sample":
        samples.setdefault(event["channel"], []).append(
            [event["t_us"] * 1000, event["value"]]
        )
    elif kind == "stream_time_shift":
        if event["scope"] != "previous_samples":
            raise ValueError("Unsupported time-shift scope")
        for channel in event["channels"]:
            for sample in samples.get(channel, []):
                sample[0] += event["delta_ns"]

Reset this state for each capture. A live chart should retain only its needed window and redraw affected samples after a correction. This example does not replace handling the other stream events or checking the capture's final result. The standalone poll stream continues to use id and does not use this handler.

Recommended upgrade order

1. Keep your original recordings, baseline files, and current firmware build.
2. Install ViewAlyzer 1.4.0 and compatible companion tools. Confirm your capture transport and target are supported.
3. If upgrading firmware, apply the integration checks above and rebuild with the matching recorder and adapters.
4. Capture a new reference run, review its measurement health, rebuild fingerprints, and check your scripts and CI exit-code handling.

Download ViewAlyzer · Recorder integration guide

ViewAlyzer 1.3.1 — October 14, 2026

• Runtime Map replay gained play, pause, range-aware restart, and looping, synchronized with the other cursor-linked views.
• Runtime Map added a runtime table, root-focused layout, traffic heat, issue filtering, and object isolation.
• Headless Runtime Map caching and queries became available to CLI users.
• Event search, dense chart rendering, recording saves, and Comms inspection became more responsive.
• The recorder API and capture format remained compatible with 1.3.0; existing firmware integrations required no source changes for that release.

ViewAlyzer 1.3.0 — October 6, 2026

• Added the bkpt-domain helper for BKPT Toolkit to analyze Trace Domain samples with the same engine as ViewAlyzer's CLI.
• The recorder API and capture format remained compatible with 1.2.0.