Summary

Iguana log files locked or corrupted causing Iguana to crash or misbehave
Iguana log files missing
Crash dumps may or may not be produced
ServiceErrorLog may or may not contain details regarding the crash
Sometimes in ServiceErrorLog:
database disk image is malformed SQLite return code: 11
Sometimes in ServiceErrorLog:
disk i/o error Extended err code: SQLITE_IOERR_WRITE SQLite return code: 10
Sometimes when you start Iguana:

Troubleshooting and Possible Solutions

Ensure no vulnerability scans are performed while the Iguana service is running
Ensure that the log directory is whitelisted from any antivirus or backup software process (see help doc Prevent Antivirus and backup software locking Iguana index files - iNTERFACEWARE Help Center )
Change the Iguana log purge time to a different time than when your backup program runs, ideally during a time of day with low-volume traffic
Ensure only "*.log" files that are older than one day are backed up.

Check the log usage statistics <iguana_url>:<web_serv_port>/log_usage_statistics
Ensure you have enough space on the drive for your log files
Better to store log files on a separate partition

In HA environment, after failing over to WK2, log files were missing
ServiceErrorLog may or may not have details regarding the crash
Workflow: From LLP - Filter - Queue
Unqueued messages were seen in the source channel (LLP - Filter - Que) and appear to be processed properly by that channel's filter, but do not make it into the next channel's logs/queue (Direct Sender channel)
If messages are shown in the Iguana log browser, they have been committed to the log files
It's possible that the internal pointer used to indicate which log message to process got corrupted, which is why the destination channel was unable to process any messages
In order to mitigate this issue, a full rebuild of the index/meta files is recommended