Known issues

  • Kanzi Monitor disables the local console of the Command Processor when running in Kanzi Studio Preview. You can use the remote console in Kanzi Studio Preview.

  • Kanzi can load plugins from dynamic libraries in an unpredictable order. If other plugins depend on Kanzi Monitor during their initialization, explicitly load Kanzi Monitor from the application during startup. This lets the application make sure that the Kanzi Monitor plugin loads first.

  • When you enable the remote console, Kanzi Monitor attempts to open a remote console and bind to a socket port. This can fail if another application or another Kanzi Monitor instance already uses that port. To resolve this issue, choose a different port number, or avoid running another Kanzi Monitor instance with the remote console enabled at the same time.

  • When you enable the serial console, Kanzi Monitor attempts to open the configured serial port. This can fail if the port does not exist, another application uses it, or it requires elevated privileges. On Windows, virtual COM port drivers (such as com0com) can require test-signed driver mode.

  • On Android, Kanzi Monitor writes trace files to the host application’s internal files directory, which it resolves at startup from the engine-held Android Context (falling back to a reflective lookup). If Kanzi Monitor initializes before any Java entry point has run, no files directory can be resolved; in that case the file trace writers (chrometrace, perfetto) are not activated and the log records an error naming them, rather than failing later with Unable to open file. The refusal also holds at runtime: overwatch.activatewriter does not activate them, and a file writer that was already active is switched off. overwatch.activatewriter answers Writer unavailable with the reason, and overwatch.writers lists the writer with "available": false and the same reason. Stream traces with the perfetto-producer writer, which needs no output directory, or ensure a Java entry point runs before Kanzi Monitor initializes.

  • The perfetto-producer trace writer requires the plugin to be built with -DKZMONITOR_PERFETTO_PRODUCER=ON (pre-built Android binaries already are) AND a platform tracing daemon (Android traced or Linux perfetto). On Windows and platforms without a daemon, the writer is silently a no-op — use the in-process capture mode via PerfettoProducerCaptureSeconds to drive a session yourself, or stay on chrometrace / perfetto for offline output.

  • Android Studio Profiler (Iguana 2023.2 and later) does not expose the Perfetto track_event data source in its “Capture System Activities” task. As a result, a System Trace captured from inside AS Profiler does not show the kanzi.* tracks even when Kanzi Monitor is streaming them through the perfetto-producer writer. Workaround: capture the trace externally with cat kanzi.pbtx | adb shell perfetto --txt -c - -o /data/misc/perfetto-traces/kanzi.pftrace (feed the config on stdin and write into /data/misc/perfetto-traces/ — the on-device perfetto sandbox rejects /data/local/tmp for both with errno 13), then open the pulled file in AS Profiler with File → Open — the kanzi.* track-event categories render normally. Android Performance Analyzer (a separate tool) does expose track_event configuration and works as expected. See Using the Profiling Trace service for an example perfetto config.

  • The GPU timings that overwatch.gputimestamps dumps can be wrong on the OpenGL backend. When affected, render passes report start 0 and the durations are meaningless — exactly 0, tens of hours (an absolute clock reading, around 1e14 nanoseconds), or close to 1.8e19 nanoseconds (end before start, wrapped around) — and the per-frame Frame line is affected as well. The cause is a defect in the Kanzi OpenGL backend (RENDERING-3141), where the GL query pool shared one query object across all of its slots so per-slot result reads raced. No |k| 4.1.x release contains a fix, so it is present on every Kanzi 4.1.x this Kanzi Monitor line supports. Whether it shows depends on the GPU driver’s tolerance of the race — NVIDIA and AMD were unaffected, Intel was — so neither the graphics backend nor the GPU vendor tells you whether the numbers are usable, and the engine’s TimestampQuery capability flag reports supported on the affected path too. Kanzi Monitor does not check the values for you: overwatch.gputimestamps reports "valuesValidated": false, so read the dump lines back and check the durations before relying on them: working values are in the microsecond-to-millisecond range. The Vulkan backend is unaffected.

  • On Kanzi 4.1.0, material types and shader programs report keepAlive as false even when the Kanzi Studio project asks for them to be kept alive, for example through the project-wide shader keep-alive behavior. The report is accurate: it is the flag the Kanzi engine resolved at load time, and Kanzi 4.1.0 does not apply the setting to these resources, so overwatch.purge reclaims them like any other unreferenced resource. This is a Kanzi engine defect (KANZIUX-841), fixed in Kanzi 4.1.1: there, the same project reports true for every material type and shader program. Keep-alive set on an individual resource of another type, such as a texture, is applied and reported normally on both versions. On Kanzi 4.1.0, read false on a material type as “unknown” rather than as a Kanzi Monitor defect.

See also

Release notes

Migration guides