BUST: 1.1.X Crashes (Your Help Requested!)

[MircoMars]

yeah my line of thought was: if the crashes weren't obvious before releasing 1.1.x because they didn't appear in QA and experimentals, perhaps the testing environment was "too stable" to see that problem. thus the existing testing environment might not be able to check whether the CTD issue is properly fixed or not. claw had a hard time to replicate the bug and could only replicate it in one particular failure mode. who knows what else lies buried in the uncountable lines of code that try to make unity do things no one ever expected it to do? only distributing hotfixes to all players who have the problem and checking back with them how stable the game is now can ensure to have it really fixed on the next official update.

releasing an update that still crashes for no apparent reason would be annoying for us and another big hit on reputation for SQUAD...

[kiwi1960]

On 8/06/2016 at 10:53 AM, Padishar said:

No, ntdll.dll is a fundamental part of the Windows operating system.  This crash basically means that the program passed a dodgy pointer (i.e. a memory address which doesn't actually have real memory behind it or an address the program doesn't have permission to access in the way it is trying to) to an operating system function (probably a memory allocation/deallocation function) and the 0xC0000005 exception code is how the operating system tells the program it has done something very bad.  It is not (usually) sensible for a program to continue running after this sort of exception as it generally means that some of the program's data is in a very dodgy state and it is safer that the program just dies than, e.g. trying to write out a save file and corrupting your save.

This is a promising line of investigation as the problem is very likely to be caused (or, at least, exacerbated) by multi-threaded code.  The VAB/SPH actually do more multi-threading than most other parts of the game.  If the crashes really don't occur when set to a single core then this could be very useful information for the devs to know...

There is always a log.  There may not be a specific "crash" log but the output_log.txt (or player.log on Mac and linux) file is always recreated every time you start the game.

Programs do not magically start losing track of of their data once it gets over 4 GB.  In any case, plenty of people have reported crashes in stock installs which use significantly less than 4 GB.  Assuming that by "garbage cleaning process" you mean the Mono garbage collector, then it certainly isn't deleting things it shouldn't, it simply doesn't work that way.  You have to write some seriously hacky C# to cause the garbage collector to reclaim any memory that is still reachable by the program.  However, the Unity API does provide a couple of potentially dangerous functions (e.g. DestroyImmediate) which, if used incorrectly, can cause the Unity player to crash in nasty ways.  If I had to guess then I would say that some bit of KSP code is probably calling DestroyImmediate on a Unity object which happens to be being used by a background thread at the time and this causes corruption of memory resulting in dodgy pointers being passed to operating system functions and crashing.

Actually.... I think I hit the nail on the head, listen here and look....

https://www.twitch.tv/ksptv/v/71528028

[Padishar]

3 hours ago, kiwi1960 said:

Actually.... I think I hit the nail on the head, listen here and look...

Can you explain why you think a mention of "leaky meshes" supports your "analysis"?  Or was there something else said that you think supports it?

[AlamoVampire]

@Claw more data points sir: 4 runs, 2 of which ended after 2 minutes 18 seconds EACH TIME, <again all times from telling the UAC to proceed>, 1 of which ended abruptly after an alt tab, and 1 lasted 11 minutes while I did some quick testing on a craft for a response to a thread of mine. 

Edited June 12, 2016 by AlamoVampire

[Rob2222]

Does anybody know here, if these (fixed) radial attachment VAB crashes equal the VAB crashes on deleting things?
For me and at least 2 other people the VAB crashes when removing a attached part and deleting it (crash on put it left / hit DEL) are far more common. However, modded installs.
 

[Speadge]

14 hours ago, AlamoVampire said:

@Claw more data points sir: 4 runs, 2 of which ended after 2 minutes 18 seconds EACH TIME, <again all times from telling the UAC to proceed>, 1 of which ended abruptly after an alt tab, and 1 lasted 11 minutes while I did some quick testing on a craft for a response to a thread of mine. 

u know that uac prompt is "just" for admin access to NTFS thingies?

So for memory (& || computation) Issues as this seems to me (allocation, access, pointer & so on) it just cant have any impact at all.

and after all.. u told it urself.. you are crashiong nearly as often as everyone else - or u without admin privileges...

-just saying-

Edited June 12, 2016 by Speadge

[Claw]

I've created a new fix to try. You can download from below. It includes both a fix for the high CPU utilization, and a potential fix for the VAB/SPH crash.

To install, just unzip in the GameData directory. To uninstall, delete the directory.

For the high CPU utilization in the VAB/SPH, it now uses the stock game settings "Show Space Center Crew" option. If you have that option disabled, then all animated ground crew is disabled (thereby reducing CPU utilization).

https://www.dropbox.com/s/gyyaavynxkwtxhg/EditorCPUFix v00.02.zip?dl=0

 

[reilithion]

 

On 6/13/2016 at 10:06 PM, Claw said:

I've created a new fix to try. You can download from below. It includes both a fix for the high CPU utilization, and a potential fix for the VAB/SPH crash.

To install, just unzip in the GameData directory. To uninstall, delete the directory.

For the high CPU utilization in the VAB/SPH, it now uses the stock game settings "Show Space Center Crew" option. If you have that option disabled, then all animated ground crew is disabled (thereby reducing CPU utilization).

https://www.dropbox.com/s/gyyaavynxkwtxhg/EditorCPUFix v00.02.zip?dl=0

 

I was experiencing the crash in the VAB/SPH quite often - usually after only a few minutes in those buildings. I have installed this fix and have had no crashes in the VAB or SPH during several hours of gameplay. It's not proof, but this is a pretty good indication the patch worked.

[Claw]

4 hours ago, reilithion said:

I have installed this fix and have had no crashes in the VAB or SPH during several hours of gameplay.

Excellent to hear, thanks for the feedback.

[Spandau]

Usually crashed about twice an hour. Been playing for several hours today without a crash. You sir, are a scholar and a gentleman.

[Claw]

1 hour ago, Spandau said:

Been playing for several hours today without a crash.

\o/

Technically not a reaction image, but I'm happy none the less. Only two data points, but on a positive trend so far.

[Speadge]

3rd here: no crash in vab last evening (~5h).

Nontheless two in flight :D.

VAB CPU utilization is around 30% (xeon e3-1245)

[antilochus]

Works well for me - about an hour or so in the VAB with no crashes and I was getting them quite often before. Great stuff.

[tg626]

For me VAB crashes started out of the blue about 3-4 days ago.  Remembering that you posted in some other thread that you had this "experimental patch" available I came here and downloaded it.

Viola no more crashes.

My GameData folder:

[AltFunding]                      [BoulderCo]
[Chatterer]                       [CoolRockets]
[DefaultActionGroups]             [Diazo]
[DistantObject]                   [EditorCPUFix]
[EngineLight]                     [EnvironmentalVisualEnhancements]
[FASA]                            [FP_Custom]
[FP_DPSoundFX]                    [FP_KOAS]
[KerbalEngineer]                  [KerbalKonstructs]
[KerbalSports]                    [Kerbaltek]
[Kosmodrome]                      [KramaxAutoPilot]
[KronalUtils]                     [KSCFloodlight]
[KSEA]                            [KSP-AVC]
[LackMisc]                        [MechJeb2]
[Nereid]                          [RcsSounds]
[RealPlume]                       [RealPlume-Stock]
[SmokeScreen]                     [Squad]
[StageRecovery]                   [StockBugFixPlus]
[TextureReplacer]                 [ToadicusTools]
[TweakableEverything]             [WheelSounds]

 

[Speadge]

add-on: just had a vab crash with the fix:

entered vab, chose okto-core, replaced it, and KSP crashed.

No symmetry or booster. just the core used.

Edited June 17, 2016 by Speadge

[Claw]

On 6/15/2016 at 10:40 PM, Speadge said:

no crash in vab last evening (~5h).

23 hours ago, antilochus said:

Works well for me

13 hours ago, tg626 said:

Viola no more crashes.

Excellent! Thanks for testing.

 

2 hours ago, Speadge said:

entered vab, chose okto-core, replaced it, and KSP crashed.

Did you, by chance, happen to keep the log files?

[Speadge]

Just now, Claw said:

Excellent! Thanks for testing.

 

Did you, by chance, happen to keep the log files?

damn.. u got me...

*deleting "-nolog" parameter*

keep trying
its modded anyway - so there is a chance its not caused by stock

 

[ispeedonthe405]

On 6/13/2016 at 9:06 PM, Claw said:

I've created a new fix to try. You can download from below. It includes both a fix for the high CPU utilization, and a potential fix for the VAB/SPH crash.

Hooray for hotfixes. 

[Speadge]

hey @Claw,

i managed to crash it again. Just this time with a lil big larger craft. around 80parts

u can find output_log.txt and KSP.log here

hope that helps.

 

[ispeedonthe405]

So far so good. Really good. I've been running the same session for about three hours now, in and out of the VAB, launching, back to the VAB, not a single crash. Windows x64 w/ RO & RSS and some other mods installed (~5GB mem usage). CPU usage is about 28% in the VAB, or 18% in the VAB with the building turned off (mod, the name escapes me). If I had three thumbs they would all be up.

Edited June 18, 2016 by ispeedonthe405

[kcs123]

I have few two-three hours session in sandbox game and several within one hour without crashes. I just started career game with few additional mods and have several CTD in row.

It might be related to SPH/VAB building level, since it is career start, but again it also might be misleading. Last CTD happened when I deleted one part from craft and just picked another one. Sorry, I don't have 100% reliable reproducing steps and log does not show anything unusual.

Here is just few last lines that should be relevant:

Spoiler

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Voxelization Time (ms): 83
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

deleting part adapterSmallMiniTall
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Crash!!!
SymInit: Symbol-SearchPath: '.;E:\Kerbal Space Program;E:\Kerbal Space Program;C:\Windows;C:\Windows\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'kruno'
OS-Version: 6.1.7601 (Service Pack 1) 0x100-0x1
E:\Kerbal Space Program\KSP_x64.exe:KSP_x64.exe (000000013F6C0000), size: 20312064 (result: 0), SymType: '-exported-', PDB: 'E:\Kerbal Space Program\KSP_x64.exe', fileVersion: 5.2.4.2391

 

I have preserved full from that session, it is moded game, so don't know if full log will be useful at all.
Forgot to mention, it happened with applied fix from "EditorCPUFix v00.02.zip"

Whole CTD thing have high degree of randomness, it is hard to track down each step that lead to CTD.

[Auriga_Nexus]

Claw, I have no clue what the actual foxtrot your little fix did, but it WORKS. Finally managed to build a decent sized rocket after an hour in the VAB, and another hour flying it to the Mun and back, all on 64-bit KSP. Given. my normally library-sized collection of mods were not installed, but at least now I can get somewhere in the game without it crashing every 15 minutes.

You, sir, are doing the Lord's work. I salute you.

Edited June 20, 2016 by Auriga_Nexus

[kcs123]

I on the other hand don't know what to say, does it properly fixed or not. After having several CTD in short time frame I also got few sessions for more than 1-2 hours without issues. I was having fix applied in both cases.

[Auriga_Nexus]

Ok, maybe I spoke too soon. I started getting CTD's again after installing mods. It does seem that it managed to dump the files in. memory after the last crash into the output logs, which is a bit of an improvement.

I will do a fresh reinstall and try to gather some data points. While I didn't spend too long in the VAB with the unmodded install, it was long enough that I would have experienced a crash based on how long I was in the VAB in the modded install, but it didn't crash. Seeing as before it would crash regardless of mods, that tells me that there is at least an improvement.

If I can pin it down to a specific mod I will take that up with the mod author, otherwise it could also merely be related to volume (this was all on KSP 64 so that shouldn't necessarily be the case but it's a good avenue to investigate). In the meantime I will likely copy my vanilla install of KSP out of my Steam folder and have that separate for additional testing.

Oh and before I forget here's my log file.

 

EDIT: After re-installing KSP and unzipping Claw's fix file, I read the readme and came to a realization, so I just have to ask - when installing the fix, do we merely unzip the file, or do we have to insure that the .dll is at the top of the GameData directory? Because this is what I had previously:

 

C://.../KerbalSpaceProgram/GameData/EditorCPUFix/EditorCPUFix.dll

and THIS is what I'm thinking I should have had
 

C://.../KerbalSpaceProgram/GameData/EditorCPUFix.dll

can anyone confirm?

Edited June 20, 2016 by Auriga_Nexus
Possible Idiot Ball scenario

[Claw]

9 hours ago, Auriga_Nexus said:

After re-installing KSP and unzipping Claw's fix file, I read the readme and came to a realization, so I just have to ask - when installing the fix, do we merely unzip the file, or do we have to insure that the .dll is at the top of the GameData directory?

It should work in either location. The fix might not be comprehensive for all cases, but seems to take care of one of the common places. There are some other fixes in the works that are harder to do via an add-on.