INtime SDK Help
Troubleshooting

In case something goes wrong, following guide should help to track down the root cause and provide some hints, how to solve the problem.

Kernel not loading

In case kernel refuses to load, check event log to see, if any useful information is given. To access the event log, you can simply click on INtime status monitor icon and select Event Viewer from popup menu. There are two relevant sections in this logs. First of all, the INtime entries under Applications and Services Logs, which is opened automatically for you by the Event Viewer menu entry. In case you have a license error, an entry from LoadRTK will be present. Memory and configuration problems will be found in System section from Windows Logs entry. Apply an filter to look for errors from source rtif.

For license errors, please apply a correct license or contact license@tenasys.com for assistance. In case there is an error reported from rtif, please contact support@tensays.com and provide the error message as well as your configuration (which can be exported from INtime configuration panel).

HW faults (exceptions)

Some applications might cause HW faults like divide by 0 or page faults. As long as running the application from a PC with installed SDK, you can use any debugger present on your system from a dialog, which is shown on occurrence of HW errors. Select the version of visual studio you want to use and press Visual Studio button. Additionally there is the INtime Spider debugger available, but it is not as comfortable as visual studio. In case no debugger is available, you can select Analyze Exception, which opens the INtime Explorer and lets you examine the threads in the process, which caused the exception. Usually you can see the current program counter and the disassembly at this locations as well as the register content. From the map file of your application, you will be able to find the corresponding source function. An crash report file is generated too, which can be analyzed by INtime explorer. Use View -> Crash Log.. from the menu and select the rtc file with the name of the node (default NodeA.rtc). From the next dialog select the entry with the actual Date/time and the right rta. You will be asked for the location of the rta and if possible the pdb file gets loaded as well. A report is generated and stored as a text file with additional information about the current process state at time of exception, which should help to find the root cause in your software.

Memory errors

There are different memory sections in every application, which can cause runtime errors. First of all the stack needs big enough to store all needed information during function calls. Recursion or unintended stack writes (accessing objects out of bounds) can lead to situations, where the return address is wrong, local variables are overwritten or in best case, the application crashes. So be sure during development to calculate the stack requirements correctly and use appropriate settings while creating threads.

Out of system memory errors occur, if too many applications are loaded at same time and total memory assigned to the INtime node is too low. Many programs do not always check the return values from memory allocations, which results in code just failing to execute. Be sure to always check return values and take appropriate actions (warnings on screen or log entries) in case memory is too low.

Heap is the last memory area, which can cause trouble during long term program execution. Things like fragmentation or write out of bounds are hard to detect and test for, but you might find some usage in the debug heap library.

Timeline problems

Normal program flow can rely on some sequencing in the software. If these sequences are disturbed, the application may fail. One problem might be a spinning thread, which takes all the computation power from the CPU which leaves the remaining system unresponsive. There is a built in tool called Spindoctor available, which tests for spinning threads.

Another, even harder to detect, error could be caused by wrong priorities and deadlocks. A very good tool to track the dynamic execution of an application is INscope. Use this tool to write a trace of thread switches, API calls, interrupts and even user defined events. The tool itself has an help included and there is even an API to control some of the functionality during from within the user code.

See Also

Heaps and Pools

Utilities

INscope