As bugs go, this one is a beauty. Read, weep, then wonder wtf?

[Screwball]

This entire log, all 340+KB of it, covers the portion of "Old Friends" (DLC2TT2) which takes place in Highpoint Tower. I made a Quicksave having just entered the tower (and exited and reloaded Skyrim) so that's the starting point for the following, omitted the usual startup stuff as it's probably not relevant..

 

Enjoy! (or not, as the case may be).

 

[10/03/2013 - 12:45:33AM] Saving game...
[10/03/2013 - 12:45:34AM] VM is thawing...
[10/03/2013 - 12:46:20AM] Info: *Achievement 24 awarded - a winnar is you!*
[10/03/2013 - 12:46:40AM] Info: *Achievement 36 awarded - a winnar is you!*
[10/03/2013 - 12:46:40AM] Info: *Achievement 24 awarded - a winnar is you!*
[10/03/2013 - 12:46:53AM] Suspended stack count is over our warning threshold, dumping stacks:
[10/03/2013 - 12:46:53AM] VM is freezing...
[10/03/2013 - 12:46:53AM] VM is frozen
[10/03/2013 - 12:46:53AM] Dumping stack 4194315:
[10/03/2013 - 12:46:53AM]     Frame count: 2 (Page count: 2)
[10/03/2013 - 12:46:53AM]     State: Waiting on other stack for return (Freeze state: Freezing)
[10/03/2013 - 12:46:53AM]     Type: Normal
[10/03/2013 - 12:46:53AM]     Return register: None
[10/03/2013 - 12:46:53AM]     Has stack callback: No
[10/03/2013 - 12:46:53AM]     Stack trace:
[10/03/2013 - 12:46:53AM]         [DLC2Pillar (0301C4E4)].dlc2pillarscript.SetBuilderFactionFriendliness() - "DLC2PillarScript.psc" Line 90
[10/03/2013 - 12:46:53AM]             IP: 163    Instruction: 6    Line: 90
[10/03/2013 - 12:46:53AM]             [ActorToSet]: [DLC2PillarBuilderActorScript < (0301843D)>]
[10/03/2013 - 12:46:53AM]             [isSleepBuildTemplate]: True
[10/03/2013 - 12:46:53AM]             [::temp15]: True
[10/03/2013 - 12:46:53AM]             [isInBuilderFaction]: True
[10/03/2013 - 12:46:53AM]             [::nonevar]: None
[10/03/2013 - 12:46:53AM]         [ (0301843D)].DLC2PillarBuilderActorScript.OnPackageStart() - "DLC2PillarBuilderActorScript.psc" Line 18
[10/03/2013 - 12:46:53AM]             IP: 172    Instruction: 5    Line: 18
[10/03/2013 - 12:46:53AM]             [akNewPackage]: [Package < (03032318)>]
[10/03/2013 - 12:46:53AM]             [::temp1]: [Package < (02017004)>]
[10/03/2013 - 12:46:53AM]             [::temp2]: [Package < (02017004)>]
[10/03/2013 - 12:46:53AM]             [::temp3]: True
[10/03/2013 - 12:46:53AM]             [::temp4]: [DLC2PillarBuilderActorScript < (0301843D)>]
[10/03/2013 - 12:46:53AM]             [::nonevar]: None
[10/03/2013 - 12:46:53AM] Dumping stack 4194400:
[10/03/2013 - 12:46:53AM]     Frame count: 2 (Page count: 2)
[10/03/2013 - 12:46:53AM]     State: Waiting on other stack for call (Freeze state: Freezing)
[10/03/2013 - 12:46:53AM]     Type: Normal
[10/03/2013 - 12:46:53AM]     Return register: [Package < (02017004)>]
[10/03/2013 - 12:46:53AM]     Has stack callback: No
[10/03/2013 - 12:46:53AM]     Stack trace:
[10/03/2013 - 12:46:53AM]         [DLC2Pillar (0301C4E4)].dlc2pillarscript.SetBuilderFactionFriendliness() - "DLC2PillarScript.psc" Line 85
[10/03/2013 - 12:46:53AM]             IP: 0    Instruction: 0    Line: 85
[10/03/2013 - 12:46:53AM]             [ActorToSet]: [DLC2PillarBuilderActorScript < (0301843D)>]
[10/03/2013 - 12:46:53AM]             [isSleepBuildTemplate]: False
[10/03/2013 - 12:46:53AM]             [::temp15]: False
[10/03/2013 - 12:46:53AM]             [isInBuilderFaction]: False
[10/03/2013 - 12:46:53AM]             [::nonevar]: None
[10/03/2013 - 12:46:53AM]         [ (0301843D)].DLC2PillarBuilderActorScript.OnPackageStart() - "DLC2PillarBuilderActorScript.psc" Line 20
[10/03/2013 - 12:46:53AM]             IP: 273    Instruction: 8    Line: 20
[10/03/2013 - 12:46:53AM]             [akNewPackage]: [Package < (0303D242)>]
[10/03/2013 - 12:46:53AM]             [::temp1]: [Package < (00016FAA)>]
[10/03/2013 - 12:46:53AM]             [::temp2]: [Package < (02017004)>]
[10/03/2013 - 12:46:53AM]             [::temp3]: False
[10/03/2013 - 12:46:53AM]             [::temp4]: [DLC2PillarBuilderActorScript < (0301843D)>]
[10/03/2013 - 12:46:53AM]             [::nonevar]: None
 

And so on for 343KB of log. Entire log attached, note that there are references not just to this location, but to regular Skyrim locations and to Weapon Racks.

 

Papyrus.0189.log.zip

[Sclerocephalus]

How long is it that you get those "Dumping stack messages" in your log ? You're getting stack buffer overflows!

 

And we are wondering where all those "no native object bound to the script object" errors come from which you reported on the tracker, and why there are things happening that actually CANNOT happen. Mystery solved ...

 

You should remove the iMaxAllocatedMemoryBytes tweak from your Skyrim.ini as soon as possible, since it will ruin your game for sure.

Further information can be found here:

http://www.creationkit.com/INI_Settings_%28Papyrus%29#iMaxAllocatedMemoryBytes

[Arthmoor]

Suspended stacks are bad. Very bad. It means you've got so much going on that Papyrus has overloaded itself.

 

It can be for the reason Sclerocephalus just ninja'd me over, or simply a genuinely bad script or scripts that are hogging up time.

 

Unfortunately the stack dump is of little use because it's going to dump everything Papyrus is currently working on and gives no indication of the actual problem scripts that caused it to happen.

[Screwball]

Ok, so one at a time...

 

@Sclerocephalus:-

Those errors have appeared once, as posted. I have never seen them before (though I've not always checked the logs as carefully as I am at present).

Those would be the  "no native object" errors which have already been confirmed and fixed?

Mystery solved? A somewhat premature statement, at this point in time, don't you think?

iMaxAllocatedMemoryBytes does NOT appear in any copy of any .ini file related to Skyrim on my system. I have never, to the best of my knowledge, added it or, if it already existed (which it doesn't) modified it.

 

@Arthmoor:-

I realise they're bad, but I have no idea what could be causing them. I have no "leftover" scripts lying around because I've never installed any mods other than the ones mentioned in my Spoilers.

I also realise that the logs probably don't help much - provided for completeness only. That's why I posted this on the forum rather than creating an Issue which could probably never be directly addressed.

 

Since that one log the game has continued to run normally, logs have dropped back to being a few KB in length. The game doesn't seem either slower or faster. Quests appear to be running and completing as expected (ignoring for a moment the log errors I've already reported) so whatever the cause, it is not fatal, but it is worrying.

 

Update.esm
HearthFires.esm
Dragonborn.esm
SBBasement.esm
Unofficial Skyrim Patch.esp
Unofficial Hearthfire Patch.esp
Unofficial Dragonborn Patch.esp
SBBasementHF.esp
SBBasementDB.esp
No Killmoves, No Killcams, No Killbites.esp

------------------------------------------------------

Dawnguard.esm - installed, not active in this game

Unofficial Dawnguard patch.esp - installed, not active in this game

SBBasement_DG.esp - installed, not active in this game

When Vampires Attack - installed, not active in this game
 

[tyrel68]

if none of the simple answers are correct then there has to be a catastrophic corruption of scripts causing massive spikes in activity and errors.

Sadly i dont think this is fixable if thats the case since its all probably baked into your save

the only thing i can think of is that its something to do with just the dlc2 which is hearthfire so a drastic correction though possibily dangerous

 

Uninstall the

1) Uninstall the SBBasementHF.esp

2) save reload the save

3) Run for 30 days

4) Cross fingers

 

See if that works else try

 

1) Uninstall Hearthfire

2) save reload the save

3) Run for 30 days

4) Reinstall Hearthfire

5) Cross fingers

[Arthmoor]

Uninstalling either of those can only make the problem worse, not better.

 

@Screwball: If the incident only happened once, don't worry about it. Though it could be an indicator your game is close to the breaking point. Just keep an eye out for it to happen again. Unless that Companions script has really clogged up that much stuff.... horrid thought, but who knows.

[Screwball]

 DLC2 is Dragonborn, not Hearthfire. Everything Hearthfire is BYOH.

 

Removing mods would likely have either no impact or even make things worse. I'll probably start over when USKP 2 is released anyway which should help due to all the corrections in there.

 

Probably the only way to be certain is a complete uninstall of Skyrim followed by a clean install.

 

Does make you wonder how many other people have had this error but never seen it either through not turning on the logging or not checking the logs when they have.

 

[edit]

@Arthmoor:- I'm still getting the CR06 stuff in the logs, periodically, despite completing the Companions questline and not going anywhere near Jorrvaskr for quite some time due to playing Dragonborn at present.

I think I'll notice if I get a log that large again

[/edit]

[Screwball]

Heck of a bump, but this has just happened again - the "Suspended stack count is over our warning threshold, dumping stacks:".

This was a new game started after the release of USKP 2.0.0a. It has to be being caused by that DLC2PillarBuilderActorScript - there are over 800 references in that log just for that 1 script. There are a few other "normal" errors, mostly already logged issues, not related to the stack dump.

I've done a few manual stack dumps over the life of this game and the largest number of items in the dumps were 4 or 5, mostly critter-related.

Load Order:-

Update.esm
USKP (2.0.0a)
Hearthfires.esm
UHFP (2.0.0)
Dragonborn.esm
UDBP (2.0.0)
SBBasement.esm
SBBasementHF.esp
SBBasementDB.esp
no killmoves, no killcams, no killbites.esp

[edit]

This is just weird. Loaded Skyrim and loaded the savegame made immediately prior to the log with the stack dump in it. Manually dumped the stack - log had 5 stacks in it. One related to a dead dragon, 3 for Firelies, one related to WIDeadBodyCleanupScript.

Did the same again and went back to Solstheim. Guess what? It dumped the stack again, this time with over 850 instances of DLC2PillarBuilderActorScript.

This is not good...

[/edit]

 

[NightStar]

I couldn't find a bug report for the DLC2PillarBuilderActorScript from the tracker, so if you haven't yet made one, you should. This issue definitely deserves an entry.

[Screwball]

Done - #14304.

[Arthmoor]

I went back up to your first post and noticed something fishy that doesn't jive with the load order.

 

[10/03/2013 - 12:46:53AM]             [::temp1]: [Package < (02017004)>]
[10/03/2013 - 12:46:53AM]             [::temp2]: [Package < (02017004)>]

Don't know if it's a factor or not, but I'm puzzled as to how you could be getting temp values like this that point up to the USKP when 02017004 is not even a valid form ID from the USKP.

[Arthmoor]

Further checking:

It appears as though all of the stack dump errors for DLC2PillarBuilderActorScript.OnPackageStart() are being generated by a single ID: 0301843D. When adjusted for load order in TES5Edit, this comes back as the placed reference record for Drovas Relvi. Whatever the problem is seems to be entirely his fault.

It's probably not helping things that your stack dump also has a ton of Firefly spam mixed in, all pointing to a Wait() function that's probably poorly done and is getting locked into a loop or something.

Basically, Drovas is making Papyrus shit itself and the fun will be figuring out why.

[tyrel68]

That bug doesnt even make sense aside maybe a ghost in the machine.....

 

Id probably do a test to see if disabling him stops it or the bug merely jumps to somone else

[Arthmoor]

If it were going to jump to someone else, they would have been all over that stack dump. So it seems something unique to him is setting it off and Papyrus was already close to the tipping point because of the critter stuff on the stack.

[Screwball]

I went back up to your first post and noticed something fishy that doesn't jive with the load order.

 

Don't know if it's a factor or not, but I'm puzzled as to how you could be getting temp values like this that point up to the USKP when 02017004 is not even a valid form ID from the USKP.

 

USKP wasn't mod 02 at that time - see the 4th post in this thread. OP was on Oct 3rd - before the release of USKP 2. Load order was different then.

Yesterday's post relates to a new game (my current one) started on Oct 29th with USKP 2.0.0a and therefore a different load order due to the "false esm" change.

 

I've now completed "The Reluctant Steward" and "Cleansing the Stones" so we'll see if this happens again - I've a suspicion that it won't, but you never can tell.

[Arthmoor]

What was 02 at the time then? That ID doesn't match anything in Dragonborn either.

[Screwball]

The load order in Post 4 above was correct at the time. I maintain a list of savegames vs the installed mods. This is that list for that game.

 

Save 2 - no patches or mods - should be "clean"
Save 4 - USKP added immediately AFTER this save
save 13 - SBBasement.esm added immediately AFTER this save (before USKP in the load order)
Save 21 - No Killcams.esp added immediately AFTER this save (after USKP in the load order)
Save 78 - Hearthfires, UHFP and SBBasementHF added immeately AFTER this save. Update, HF, SBB, USKP, UHFP, SBB_HF, Killcams
Save 143 - Dragonborn, UDBP and SBBasementDB added immediately after this save. Update, HF, DB, SBB, USKP, UHFP, UDBP, SBB_HF, SBB_DB, Killcams

 

Save 143 was made on Oct 1st, 2 days before I started this thread on Oct 3rd. The order agrees with that in Post 4 above. If Update, being the 1st mod, is "01" then "02" has to be Hearthfires.

 

Those details are all for the game being played at the time - not for my current game!

[Arthmoor]

So Hearthfires.esm it is then. That's what I was trying to work out, but couldn't, because there's too many distinct situations being discussed here

 

02017004 in Hearthfires.esm is a collision box inside one of the houses. So why that's even showing up as a temp variable is disturbing enough. That Papyrus didn't seem to care, beyond reporting it in stack dumps, is even more worrisome.

 

Still, this all seems to be restricted to one NPC. So hopefully when the time comes we can find out what's wrong with this guy.

[Screwball]

Here we go again

 

[09/27/2014 - 10:47:33AM] Suspended stack count is over our warning threshold, dumping stacks:
[09/27/2014 - 10:47:33AM] VM is freezing...
[09/27/2014 - 10:47:33AM] VM is frozen
[09/27/2014 - 10:47:33AM] Dumping stack 2671259:
[09/27/2014 - 10:47:33AM]     Frame count: 0 (Page count: 0)
[09/27/2014 - 10:47:33AM]     State: Waiting on other stack for call (Freeze state: Freezing)
[09/27/2014 - 10:47:33AM]     Type: Normal
[09/27/2014 - 10:47:33AM]     Return register: None
[09/27/2014 - 10:47:33AM]     Has stack callback: No
[09/27/2014 - 10:47:33AM]     Stack trace:
[09/27/2014 - 10:47:33AM]         [ (0301843D)].DLC2PillarBuilderActorScript.OnPackageStart() - (requested call)
[09/27/2014 - 10:47:33AM]             [param 0]: [Package < (03032318)>]
 

Log is 9.5MB, 150,000 lines. Damn Drovas to hell for all this

 

Load order:-

Update.esm
USKP (2.0.6)
Dragonborn.esm
UDBP (2.0.6)
SBBasement.esm
SBBasementDB.esp
no killmoves, no killcams, no killbites.esp

[Arthmoor]

Still have no idea what could be causing that. Sucks that it's still happening obviously, but until something presents itself, I doubt we'll be able to find what's doing that.

[Screwball]

I'll have a play with some earlier savegames (from the same overall game) and see what happens as I discover more of the Stones. IIRC the stacks start showing up in the logs (with a "DPS" console cmd) almost as soon as you first set foot on Solstheim.

It doesn't really seem to affect gameplay too badly, for the most part, though odd things do seem happen during the session which causes the real stack overflow (delayed footsteps, switch sounds after the switch has moved - things like that). It recovers after a save/close/load cycle.

Would someone hold Drovas still so I can stab him in the back. Please?

[icecreamassassin]

I figured I would post since I too am having this issue it seems. Though I don't know nearly as much about some of this as you do, I too have narrowed it to a memory issue involving repeated calls to the DLC2PillarBuilderActorScript.

 

I've been developing a mod for some time now which is VERY script heavy to be frank, and I've learned the hard way that things need to be trimmed down. I have a couple of SKSE functions that check for Container closure but are conditioned out to only run when the particular container is activated. I had the script set up on a quest handler and one container, but then had 2 other handlers doing essentially the same thing via Alias scripts on the same container, and then 3 other addons basically doing the same thing. I trimmed down to 1 handler in the main mod and 2 others in the addons and it seemed to fix the problem, however it seems to have cropped back up for me as well and the one thing in common with every crash was this dragonborn script. This is the line I keep getting repeated:

 

[10/14/2014 - 09:17:33PM] [DLC2PillarBuilderActorScript < (070177DB)>]OnPackageStart()

 

which based on my load order points to DLC2Talvas "Talvas Fathryon" [NPC_:07017777]

 

so don't know if that will help give any more leads as to a common cause