SpyKer: a breakthrough in debugging embedded systems. Traditional performance-analysis tools would require an application to run under a specially instrumented kernel, or that it be pre-instrumented with special calls.

SpyKer Pro v2.0 PDF brochure (203 kB) 1. What is SpyKer? 2. What does a trace tool do? 3. No kernel rebooting or instrumentation required 4. Reading SpyKer event trace data 5. Remote targeting of event traces you are here > 6. Selective event tracing and buffering for crash analysis     How to order SpyKer

System crashes and postmortem traces

SpyKer™ can help with the difficult job of postmortem system-crash analysis in an embedded system. If event trace data is stored in non-volatile memory in the target system (if it exists), it can be loaded into the SpyKer display tool for analysis following a crash, should there be one.

Developers can instruct SpyKer to save trace buffers to disk, to a network mounted drive, or to continually discard the oldest trace data and use the buffer itself as the sole storage mechanism.

Selective event tracing to minimize interference

Developers specify which system events need to be traced and which do not.

The overhead of a SpyKer trace patch is very low by design, to enable objective measurements and to eliminate timing invasiveness that could keep particularly evasive bugs hidden.

By limiting auto-instrumentation to developer-selected events, the potential impact of trace collection on the target system is reduced to the absolute minimum. At the conclusion of each SpyKer data-collection session, the target system is returned to its original state.