How to debug and troubleshoot

Sooner or later during charting application development user may notice that something is not right. Either chart produce unexpected visualization, show some exception or application even crash. It could be various reasons for those problems and this page describe how to troubleshoot them.

When facing unexpected problem, the first thing user should do is to verify that application's design follow guideline:

• No charting object sharing;
• Correct dispose pattern;
• Chart properties updated in correct thread;
• Graphic drivers are up-to-date;
• Application can access amount of memory required;

ChartMessage event handler

From version 8.4 onwards LightningChart will send messages from the chart to the user through ChartMessage event. The messages can contain notifications about chart performance, incorrect usage, warnings or errors. Define a handler for chart.ChartMessage event to listen to the messages. The event contains a ChartMessageInfo struct, which holds the message’s information.

ChartMessageInfo’s MessageSeverity property tells how severe the message is. Messages can be filtered based on their severity. Possible severity levels for messages are:

• Debug - Debug information which usually is not interesting to the user and no action is required.
• Information – An incorrect usage of a chart, for example using an invalid property setting, has happened which should not impact chart performance. User action is typically not required.
• Warning – Some incorrect usage of chart, for instance using a disposed object, has happened which might cause some minor problems with the chart such as performance loss. User action might be required.
• RecoverableError – An error has occurred from which the chart should have recovered. User must listen to ChartMessage events or messages with this severity will be thrown as exceptions.
• UnrecoverableError – An error has occurred from which the chart couldn’t recover. Might indicate an incoming exception. User must listen to ChartMessage events or messages with this severity will be thrown as exceptions.
• Critical – A critical error has occurred in the chart which will always be thrown as an exception.

MessageType property explains the basic type of the message while Details property has more specific information about it. All the possible message types can be found in MessageType enum located in LightningChart namespace.

Unwanted messages can be filtered out by changing the chart.Options.ChartMessageMinimumLevel property value. The property allows only messages of the set minimum level and higher to be sent through the event system. It is set to MessageSeverity.Warning by default.

Exceptions are thrown as ChartException objects, which contains ExceptionInfo struct with detailed information about the exception similar to ChartMessage events. In some cases, the chart may throw exceptions of other types, such as a rendering engine exception. If user wants the chart to raise an exception on all messages with a severity level of MessageSeverity.Warning or higher, chart.Options.ThrowChartExceptions property needs to be set true (default is false).

It is recommended to always subscribe to ChartMessage event to be notified about errors in the chart and possible exceptions from unlistened messages. In case of having any problems with the chart and support for it is needed, please ensure there is a working message/exception handler in the application, log the ChartMessages and include them in your support request.

Here is the example of event handler:

/// <summary>
/// Check internal message for debugging purposes
/// </summary>
/// <param name="info"></param>
private void _chart_ChartMessage(ChartMessageInfo info)
{
    string msgInfo = info.ToString();
    StringBuilder sb = new StringBuilder();
    LightningChart chart = info.Chart;
    FileStream fs = null;
    string _engineName = chart.GetRenderDeviceInfo().EngineName;

    // save INFO string to Logs =>
    try
    {
        fs = new FileStream("LightningChart_LOG.txt", FileMode.Append, FileAccess.Write, FileShare.ReadWrite);
        using (StreamWriter writer = new StreamWriter(fs, Encoding.Default))
        {
            string dateTime = DateTime.Now.ToString("yyyy/MM/dd HH:mm:ss.f");

            sb.Append(dateTime + "\t" + _engineName);
            sb.AppendLine(msgInfo);

            // write to file
            System.Diagnostics.Debug.WriteLine(sb.ToString());
            writer.WriteLine(sb.ToString());
        }
    }
    catch (Exception ex)
    {
        string message = string.Format("Failed to write to file <LightningChart_LOG.txt> \n Exception: {0} \n ChartMessage: {1}"
            , ex.Message, info.Details);
        System.Diagnostics.Debug.WriteLine(message);
        Dispatcher.BeginInvoke(new Action(() => MessageBox.Show(message)));
    }
    finally
    {
        if (fs != null)
            fs.Dispose();
    }
}

In addition, by enabling CustomMessageOptions. SetChartMessageAsCustomMessage property user can pass all internal ChartMessage to CustomMessage box/property.

OutOfMemoryException

User should make sure that application can access amount of memory required. If user takes away memory from any application, it will freeze and crash. If a lot of points are sent to chart, it may be more than some default settings allows.

First, it maybe good idea to check amount of physical memory and the dynamic of its usage with user's application running. The easiest way to do it is to use Task Manager. User can get even more information with Process Explorer. Things to check:

• how much free memory available in system,
• how much is used by charting application.
• how memory-usage grows when data is loaded to the LightningChart?

Checking for memory leaks during prolonged running of application is also important.

info

Note about memory leakage. .NET memory is managed by Garbage Collector (GC) automatically. However, the activity of GC is not straightforward: user cannot be sure will it make final cleaning in next second or next minute. It all depend on intensity of application, available computer resources etc.

If user constantly sees memory utilization close to 100%, then it is sign that computer don't have enough free memory. For smooth interaction with application user should install more RAM memory. Otherwise it will always be freezing. Optimizing chart/application (to use less memory) is another path.

Next step is to estimate the maximum amount of memory required by app. If application is somewhat demanding, then project’s build target can not be x86. This will limit applications memory to 1-2 GB, which may be not enough. For memory hungry app, it should be 'Any CPU' or '64-bit' build target (checkbox ‘prefer 32-bit’ is cleared).

Project properties in Visual Studio

Finally, user should be aware that .NET has default limits: single array size could not be bigger than 2 GB or maximum number of elements in an array is UInt32. MaxValue (2,147,483,591). Fortunately this is could be solved with .NET Framework 4.5 (and above) and configuration attribute (here is the description). The following app.config file snippet shows how to enable this feature for a .NET Framework application.

<configuration>  
  <runtime>  
    <gcAllowVeryLargeObjects enabled="true" />  
  </runtime>  
</configuration>  

Other debugging tools

Task Manager or Process Explorer would be good starting point for the any investigation.

Process Explorer screenshot

Process Explorer is very diverse tool, which allow to explore many aspect of application in question. For example, it can show CPU and GPU load, RAM and GPU memory utilization, .NET assemblies loaded for process and much more. Therefore, it is a good tool for identifying bottleneck of app (e.g. freezing due to 100% load of CPU or GPU, excess memory usage etc.) as well as for understanding how much computer resource app needs (and should hardware need to be upgraded).

Visual Studio comes with Performance Profiler - profiling and diagnostics tools help you diagnose memory and CPU usage and other application-level issues. With these tools, you can accumulate performance data while you run your application.

There are more specialized tools for profiling application.

Graphic drivers issue

LightningChart allows variety of GPU choices, even virtual/simulated once. However, rendering does rely on graphic drivers (DirectX support) and their quality maybe not always perfect. Bad graphic drivers may manifest as wrong line size, missing or extra object in the chart, extreme memory utilization or even crash of application.

note

The example how severe graphic drivers issue could be described here.

There are ways to safeguard application from unexpected graphic drivers issue. Basically end-user of application should have possibility to switch between graphic drivers - similar way like following testing is done.

But first step is to establish that problem seen in charting application is due to graphic drivers issue. Different GPU may have different problem, but universal way to check is to change Chart. ChartRenderOptions. DeviceType (in WindowsForms Chart. RenderOptions. DeviceType) property (compare between HardwareOnlyD11, HardwareOnlyD9, and SoftwareOnlyD11 options). If user sees that application is working with one rendering device but not other (especially if it is working with SoftwareOnlyD11) – then it is good indication of graphic drivers problems.

note

DeviceType SoftwareOnlyD11 uses Windows Advanced Rasterization Platform (WARP).

Obviously solutions for such problem:

• check and update graphic drivers from manufacture page;
• install another graphic card;
• set LightningChart to use another graphic card with chart. ChartRenderOptions. GPUPreference property (in WindowsForms Chart. RenderOptions. GPUPreference)

note

If you verified that problem is graphic drivers, but update does not solve the issue, please let us know. In the report please include test application and also DxDiag (DirectX diagnostic tool) output as TXT file. If graphic hardware is still supported, we maybe able to request the fix from manufacture, if many user face same problem.

How to report error to LightningChart library developers

If none of above helped to resolve your problem please contact us.

It is good idea to check is LightningChart .NET Demo (Interactive Examples App) behave similar and problem could be reproduced there. Find similar example in Demo and change properties to reproduce problem you see. If it is not enough, try extracting example as standalone application and modify code.

Send the detailed description of your problem, test application and replication steps to us. This helps in the resolution of the problem in the fastest way possible.