Causes of CTDs

Crashes to desktop (CTDs) can be difficult to track down, this page describes methods of debugging, and potential causes and workarounds.

Much of the information on this page should be viewed as just worthwhile lines of investigation when debugging, sourced from personal experiences, not as proven causes.

Debugging

The console command SCOF can be used in game, or via a script with Con_SCOF to write all console output to a text file in the fallout game directory. This is very useful as it allows you trace output to the point of CTD back in Windows.

; within game console, type:
scof "mydebuglog.txt"

Infinite loops

The most common cause of CTDs is probably infinite loops, caused when a loop condition never becomes false. With NVSE, it is good practise to replace all usage of Label with Foreach or While. Where possible, putting condition modifiers at the beginning of the loop is recommended, to avoid them potentially being skipped by conditional usage of Continue or Goto. Indentation of any loop block is highly recommended.

Looping quest stages may also be potentially non-terminating.

Removing an object whilst its script is in progress

If you have an object whose script calls a User Defined Function, and that UDF removes the object this will cause a CTD. This may be because the calling script for the UDF has been destroyed with its parent object, so its execution can not continue following the UDF call. It is better to use RemoveMe within the object's script, based on a return value for the function.

Nested function calls

If using the Script Compiler Override, it is possible to nest multiple function calls on a single line, rather than use intemediary variables. Sometimes this causes a CTD, which is avoidable by using multiple lines.

Single line And/Or conditions

Using And/Or (&& / ||) to evaluate too many conditions on a single line has been noted to cause a CTD when testing multiple UDFs or NVSE string comparisons. Separating the condition into multiple lines, or changing to a single UDF call, which itself checks all the conditions on single lines works around this.

Note also that the GECK does not short circuit and/or conditions when they become proven, all conditions on the line are always evaluated.