While the Kerio Control is experiencing issues with non-optimized source code, it might crash. The main processes report the major failure and afterward generate the core dump.
If the crash occurred in the Webadmin, the Report Problem window is being displayed with a "Kerio Control has stopped working" message.
This article provides details on how to gather and analyze such crashing reports.
Previous Linux experience is highly recommended.
If you cannot follow the instructions below, please open a support ticket.
Kerio Control can generate crash dumps in any of the
/var/crash subfolders (depending on the main process responsible for the crash).
The folder will contain the core.PID file, where PID is the process number (i.e. 1002).
If the crashes occur frequently, it is needed to enable the "Crash-reporting configuration" option in Debug logs and wait for the crash re-occurrence.
./kassist -n "description of the problem" -P KWF -e "email@example.com" -N "location_of_core.PID"
As an alternative, you can transfer core.PID file to your local PC using SCP.
Important: the Kerio Control Support is NOT notified for crash reports. It only goes to the Development/QA teams.
The file can be analyzed locally by the GDB debugger tool. The command to be executed from
gdb ./winroute <path_to_crash_dump>
Note: /tmp/core.1002 is just an example file here.
In GDB console, you can execute
bt full command to get extended output. Type "quit" to exit the GDB.
Provide all this information to the Kerio Control Support team together with Support Information file (in Webadmin Status -> System Health) and
Once you're sure the file is being transferred to the Support team, you can delete the core file (
rm <path_to_core_file>) from your system to reclaim space.
Important: the Box crash might be related to hardware issues. For more information, please refer to Diagnosing Faulty hardware boxes.