1). If you are running version 2.0 or less then goto step 2 as this option was only added in version 2.01 and 1.20. Set [debug] CrashOnError=1 in the Citect.ini file and make sure DrWatson is running. Try to reproduce the error. When this option is set, Citect will generate a protection violation whenever it detects a software error. DrWatson will trap this error and produce a trace. Send the DrWatson trace to Citect Support. Note that after you have reproduced this error, you must remove the [debug] CrashOnError option, because any error found by Citect will cause a General Protection Fault and if DrWatson is not running Citect will be aborted. Goto step 2.

2). In the CITECT.INI file set the option [memory]Segment=0 and try to reproduce the error. This option enables Citect to allocate memory in a protected mode. In this mode, Citect will consume much more memory and if you have a very large project this option may cause Windows to run out of memory and crash. Even on small projects this option will cause memory wastage, and Citect will run slower (so only use this option for fault finding). When a memory corruption occurs in this mode, it will cause a General Protection Fault that will be trapped by DrWatson. Send the DrWatson trace to Citect Support.

3). If you need to get your system running quickly, you may try setting the option [memory] pad=1. This option will cause Citect to allocate extra bytes on the end of every memory allocation. This may mask the problem and you should only do this as a temporary solution. The number you set for the pad option is the number of bytes Citect will add to each memory allocation (pad=2 will add extra 2 bytes). This option will cause Citect to consume extra memory but should not slow Citect down, unless Windows starts to use Virtual memory. If you still get the error with pad=1, try increasing up to 10 until the problem goes away. If it still exists at pad=10 then this option will not mask the problem.