在scripts文件夹下，一般会有4个Papyrus.N.log，N为0123.
假如你现在刚刚开启log记录功能，你进游戏，玩到退出游戏，这期间的所有log都记录在Papyrus.0.log里面。然后第二次玩，上一次的Papyrus.0.log会变成1，新的记录还是保存在0里面....然后1变2,0变1....3以后就没了。
唔.....从哪里讲起呢？你现在玩的很开心，突然游戏闪退了，怎么办？
去Papyrus.0.log里看末尾部分。

每一条错误都有时间。假如你最后一条错误是11秒发生的，那就看11秒的内容，直到上次读档的时间，之间的全部内容，这些内容对你解决ctd会有帮助......

log里面的warning，是可以无视的。warning不会造成任何逻辑bug，也不会导致ctd，它只是稍微提醒你，你的mod环境可能存在一些问题，但这些问题已经被老滚自行解决了....当然，机器的解决方式还是有可能不靠谱的。
然后是error，error也有无关紧要的，比如寒霜之秋会检测所有相关mod，比如wetandcold...如果你没有，就刷一条error，但寒霜之秋依然会正常工作。
还有一种是引起逻辑性bug的。比如某条任务代码出错了，可能导致你任务卡住。这可能是mod导致的，也可能是cpu没处理完脚本....分辨这两个的办法只有一个，那就是多次读档。
最后一种error是直接导致ctd的。我举个例子
[03/01/2014 - 06:13:05PM] warning: Assigning None to a non-object variable named "::temp24"stack:
[ (2B00EBFA)].WeaponRackActivateScript.PlaceItem() - "WeaponRackActivateScript.psc" Line 268
[ (2B00EBFA)].WeaponRackActivateScript.HandlePlayerItem() - "WeaponRackActivateScript.psc" Line 329
[ (2B00EBFA)].WeaponRackActivateScript.RunPlayerActivation() - "WeaponRackActivateScript.psc" Line 188
[ (2B00EBFA)].WeaponRackActivateScript.OnActivate() - "WeaponRackActivateScript.psc" Line 84
这个ctd发生于进入某场景ctd。首先看开头，[03/01/2014 - 06:13:05PM] 是错误时间。
[ (2B00EBFA)]这个是错误的id。前两位是发生错误的mod十六进制排序，在nmm里就可以看到。如果多次ctd报错都是那一个mod，你应该考虑那个mod的去留，以及卸载完mod如何处理你的存档！
"WeaponRackActivateScript.psc"这个是发生错误的脚本文件，psc是源码，你可以打开它看一看里面的内容....当然看不懂.....好吧我在说废话。
WeaponRackActivateScript这个是发生错误的脚本，这个名字存在于你的存档内，也就是说这个是存档内的脚本。
OnActivate()这个是发生错误的脚本的函数。
综上，我解释一下这个ctd发生的原因。你的某mod给某场景加入了过多了武器架。在你读档的时候，老滚要给每个武器架绑定物品。但是因为你cpu太渣，或者其他原因，导致物品和武器架绑定失败。老滚不断给none的refid的物品placeitem，但老滚检查武器架的时候发现并没有武器，循环，但目标还是none，继续循环....ctd。

刚刚那个例子代表一个类型，就是本身正常的脚本，因为某种原因而无限循环或者出错，让游戏崩溃。
某种原因大概可以分为这几种：cpu硬件原因。这里不是说你cpu渣，而是脚本量大。例如多随从，例如实验室的欲望系统，例如头部跟随mod....等等。这些mod在读档的时候需要处理的脚本很多，尤其是场景内npc多的时候。在读档 过程中，给你处理脚本的时间不是无限的，所以没处理完的可能会被放弃，释放内存。 存档内存在垃圾脚本，这多是由于不正当卸载mod造成的。表面上看，你卸载mod之后并没有出现立即坏档，但这比立即ctd可怕的多，它不断在你存档内积累更新onupdate（）脚本，每次读档的时候都要进行几次，占用cpu处理周期，影响其他正常脚本的运行....
大概原因就这两种吧。

这个是头部跟随mod的psc源码。初步观察，可以看到它要对场景内每个npc进行判定，并且判定很频繁。有人叫这个伪脚本。虽然看起来很坑，但如果你存档内没有垃圾脚本，单靠mod坑，基本坑不出脚本错误的，而且这个mod作用不可替代，所以......
其实，读档期间，对脚本处理的时间，是可以通过修改skyrim.ini修改的，但修改也是有限度的。如果你给脚本的资源太大，会导致材质无法载入完全，这会导致紫色材质出现。模型载入不完全，会导致虚幻模型，你可以通过那里掉到场景之外。或者直接ctd了，这需要技巧。
给出ank猴子大神关于参数的介绍。

Error: (000844A5): cannot enable an object with an enable state parent.
stack:
[ (000844A5)].lvlpredatorscript.Enable() - "<native>" Line ?
[ (000844A5)].lvlpredatorscript.OnCellLoad() - "LvlPredatorScript.psc" Line 25
这条脚本对于早期玩老滚的玩家会很熟悉，这是著名的lvlpredatorscript错误。这是原版老滚存在的bug。这个bug轻则刷log坑cpu重则直接ctd！uskp可修复。
这种可以归类为原版老滚自带的脚本错误。原因非常简单，b社程序员脚本写的渣。类似的情况还有很多，有引起ctd的，有逻辑bug的。后者偏多，例如冰上之血。那个任务的制作本意很好，多阶段，可选择性，有一种侦探的感觉....无奈脚本判定写的太渣了.....
对于这种error，解决办法有两个。一个是uskp，一个是下修复的脚本，覆盖原版文件。

Cannot open store for class "cluxShrinesEnabler", missing file?
这种相对来说比较常见。这就是不正当卸载mod导致的直接ctd。因为读档过程中，要对存档内存在的脚本进行处理，你那个脚本对应的pex文件已经不在了，也就没办法处理了，只能抛错误。
上面那个脚本是这个mod带的CLARALUX - More and Brighter Lights RUS v3.a，当你装完这个mod，进入游戏，存档，然后退出来，把mod删了，再进游戏读档，就可能ctd了。
对于这种ctd。你需要看那个mssing file对应的脚本属于哪个mod。然后......我也不知道怎么办。谁让你乱卸mod的？