I believe I solved my constant crashing of Kerbal Space Program myself and thought I would share....

[eightiesboi]

3 hours ago, Friznit said:

Thanks for bumping this thread.  I suspect it's very likely the cause for my similar CTD's when entering the VAB (posted a few days ago).  I'll have to give it a go this evening.  Fingers crossed!

I *did* have a crash after installing Restock and Restock+, so I suspect that there may be another 32-bit .dll lurking about, but this out of my area of expertise. 

[Friznit]

Nope.  Crashlogs are all pointing to the same access violation involving that file but unfortunately after swapping in the version from sys_32 I immediately got the same CTD on entering the VAB.  I guess it must be related to something else.  16Gb RAM on this box and it's not even half full when the CTD happens.

[Lisias]

2 hours ago, Friznit said:

Nope.  Crashlogs are all pointing to the same access violation involving that file but unfortunately after swapping in the version from sys_32 I immediately got the same CTD on entering the VAB.  I guess it must be related to something else.  16Gb RAM on this box and it's not even half full when the CTD happens.

Check if if the DLL being used is a 32 or 64 bit one.

God known what WinSXS did on your rig,

I wish I could check it myself, but my Win rig is without a GPU for some months already.

[Friznit]

xinput1_3.dll filesize is 105KB so presumably that's the 64KB one, though the date is 4/4/2007 which seems positively ancient.

I'm also seeing a lot of mono.dll causing access violations.  I guess that's Unity monoheap excrementsting itself cos too many mods or something?  Though I seem to have significantly fewer installed than is typical for modded games.

Edited March 8, 2019 by Friznit

[Lisias]

Can be a debug release. At that time, the MFC had the nasty feature of 'swallowing" Exceptions on the debugging linkage. A lot, and I mean A AWFUL LOT of software developers at that time just linked their products on the debugging version instead of fixing the code.

You need a tool called PE-Explorer to see exactly what such DLL is.

[Friznit]

PE-Explorer says it's a 64bit file but didn't tell me anything more useful.  What's irritating is that despite copying the sys32 file over to KSP, the crashlog is still reporting  Module C:\WINDOWS\SYSTEM32\xinput1_3.dll, which would suggest it's absolutely determined to not use the version in KSP plugins.  I don't even own a console controller.

[eightiesboi]

1 hour ago, Friznit said:

PE-Explorer says it's a 64bit file but didn't tell me anything more useful.  What's irritating is that despite copying the sys32 file over to KSP, the crashlog is still reporting  Module C:\WINDOWS\SYSTEM32\xinput1_3.dll, which would suggest it's absolutely determined to not use the version in KSP plugins.  I don't even own a console controller.

Have you tried JoE_Smash's other idea of swapping the win sys dll? Other than my crashes after installing restock, which could have been unrelated, I am now crash-less for nearly 24 hours again.

[Friznit]

As in, overwrite sys32 dll with the one from KSP plugins?  That seems entirely counter intuitive, so it'd probably work knowing Windoze.  I'll give it a go.

[Friznit]

Well since swapping out C:\WINDOWS\SYSTEM32\xinput1_3.dll with the (32bit) file in KSP, the game is still CTDing but now it's only complaining about steam_api64.dll in the crashlog.  So partial success.

Firstly, it's just weird that the 32 bit file supplied by Squad appears to work better than the 64bit version but KSP won't actually use it and defaults to the one in Windows Sys32 (maybe that's why Squad only ship the 32 bit version?)

Unfortunately the same trick doesn't seem to be doable with steam_api64.dll

[Lisias]

1 hour ago, Friznit said:

Well since swapping out C:\WINDOWS\SYSTEM32\xinput1_3.dll with the (32bit) file in KSP, the game is still CTDing but now it's only complaining about steam_api64.dll in the crashlog.  So partial success.

That's another new. My understanding was the exactly the other way around!

Mangling with the DLLs on the System32 will cause you trouble with the remaining of the games. There is a system wide access place for DLLs.

Put that DLL in the same directory where your .EXE is. The current directory is (or, at least, it used to be…) the first place where Windows looks for the DLLs.

[Friznit]

@Lisias since you're a genius at interpreting logs, I wonder if you would be very kind and help me see if there's anything in these that might point to a reason for the repeated CTDs.  The crash log indicates our beloved xinput1_3.dll is at fault, but unfortunately trying the trick above doesn't work.    Crash log KSP Log  Ouput Log

I've spent the last week laboriously going through every mod on a fresh install and removing anything that throws nullrefs or looks otherwise error prone, even some which I've been playing with all year without issues. A pure vanilla test install seems to work though I've not really played it long enough to be sure.  Any combination of mods will eventually lead to a CTD.  RAM isn't an issue (I added another 16Gb).  The crash is perhaps a little less consistent but it still happens with irritating regularity.  I'm summoning up the willpower to roll back to 1.5.1 and hunt down compatible mods because this is getting largely unplayable.  Any help would be massively appreciated. 

[Lisias]

2 hours ago, Friznit said:

@Lisias since you're a genius at interpreting logs, I wonder if you would be very kind and help me see if there's anything in these that might point to a reason for the repeated CTDs.  The crash log indicates our beloved xinput1_3.dll is at fault, but unfortunately trying the trick above doesn't work.    Crash log KSP Log  Ouput Log

I'm not exactly a genius on interpreting logs. What happens is that I'm truly prolific on logging borks (not a surprise, I made most of them), and so get used to where to look for things on that mass of data.  

It's like a dog smelling something he doesn't like - we don't know what it is, but hell, it smells like trouble.

(I once detected a way to inject a RESET 00 - a hard reset routine! - from user space into the Kernel on the Windows XP - of course, on a Lab full of stakeholders. Our Bug Report on Microsoft probably helped to rush the SP1!  Honest!)

Well, your box managed to get something that bad, as it appears (put on a spoiler to prevent visual polluting)

Spoiler

  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706922F56)
0x00007FF706922F56 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706922FF8)
0x00007FF706922FF8 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706E15810)
0x00007FF706E15810 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706E1EFF5)
0x00007FF706E1EFF5 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF707006AC7)
0x00007FF707006AC7 (KSP_x64) 
0x0000000039C49BCC (Mono JIT Code) (wrapper managed-to-native) UnityEngine.Object:FindObjectsOfType (System.Type)
0x0000000019F370F6 (Mono JIT Code) SpaceCenterCamera2:Start ()
0x0000000005A575CB (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007FFF54F7601F (mono) mono_set_defaults
0x00007FFF54EC8791 (mono) mono_runtime_invoke
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706E25424)
0x00007FF706E25424 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706E2067A)
0x00007FF706E2067A (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706C9C4D7)
0x00007FF706C9C4D7 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706C9C956)
0x00007FF706C9C956 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706C9EA55)
0x00007FF706C9EA55 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706C9ED49)
0x00007FF706C9ED49 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706A3C007)
0x00007FF706A3C007 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF706C701B9)
0x00007FF706C701B9 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF7067CF40B)
0x00007FF7067CF40B (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF7067CF5BA)
0x00007FF7067CF5BA (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF7067E06D3)
0x00007FF7067E06D3 (KSP_x64) 
  ERROR: SymGetSymFromAddr64, GetLastError: 'Attempt to access invalid address.' (Address: 00007FF7077E4650)
0x00007FF7077E4650 (KSP_x64) 
0x00007FFF69863DC4 (KERNEL32) BaseThreadInitThunk
0x00007FFF6BEF3691 (ntdll) RtlUserThreadStart

 

On the exact moment the Space Center Scene Camera 2 fires up (whatever it is), the Mono's JIT borks beautifully trying to access some memory address.  I took randomly one of them, 0x00007FF707006AC7, that it's 140698951117511 in decimal . Something on the… 127th Terabyte. What's make sense, one of your logs says

134217728 MB user address space [134198310 MB free].

Giving us exactly 128Tb of addresses to your program (and yeah, you only have 32Gb of physical RAM,  a small fraction of that - it's a virtual memory thingy, you can ignore this for now).

Knowing how C compiles code, I known that the TEXT segment (where compiled cpu instructions 'lives") is on the beginning of the process' address space - you can see that on the "Mono JIT Code" lines - Mono is written in C/C++ - and the later address us for the HEAP, a place we use to store data on runtime (as text, sounds, images, meshes, etc).

Do you know what? Everything is fine here. The problem is somewhere else. I did all of that to make it perfectly clear that this is not Squad's fault - Squad may have borked when things borks inside that memory space above (as it's there where anything they do "lives", as they develop in Mono, not C++ - and Mono byteodes are just data for a C++ program). If you care to check my past posts, you will understand why I found relevant to talk about.  

Well. Let's try again.  So I got back to the stacktrace, and your Stack Dump starts with something really interesing:

Crash!!!
SymInit: Symbol-SearchPath: '.;C:\Users\Alex\Desktop\KSP 161;C:\Users\Alex\Desktop\KSP 161;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;'

You see that "Search Path" thingy? If the order in which looks for DLLs. "." is the same directory as the KSP_x64.exe being executed. Now tell me; how many "xinput1_3.dll" are present on your system, and where they are? Just to get this of the way. You may be loading the wrong xinput — your crash logs says you are using "C:\WINDOWS\SYSTEM32\xinput1_3.dll" . I suggest you find a "good" xinput.dll and shove it in the same place KSP_x64.exe is, so it's found first and you don't take risks running it from somewhere else.

I'm assuming that you are using the "right" xinput from now on.

I found an interesting post on it here from Skyrim forum

Quote

I removed xinput1_3.dll from the system but it kept reporting the prob as xinput1_3.dll still. It was because I was using the 4gb memory fix. Without the 4gb memory fix the crashes all report FalloutNV.exe.

Yet, another interesting thing. Skyrim uses a 3D Engine called "Creation Engine", proprietary from Bethesda - completely unrelated to Unity. However, this hints that my previous guess about the issue were correct, at least for KSP 1.5.x - there's, indeed, an issue while handling XInput when your process is 64 bits! (Microsoft being Microsoft). Worse, we learnt that XInput is not only a source of the problem, but also the unhappy idiot that accepts the blame when it's not. Otherwise, that guy from that post would not had received the second crash.

Right now, I have two propositions to you:

• Delete GameData\Squad\Plugins\KSPSteamCtrlr.dll from your Plugins directory and see what happens. If this thingy uses xinput too, it would have the same issues!
  • Since we are on the mood, get frenzy and delete also KSP_x64_Data\Plugins\steam_api.dll. One less thingy to care about.
  • Of course, make backups
• Delete all the xinput1_3.dll from your system (make backups), and see what happens.

Something, somewhere, appears to be still tied to that 4Gb stunt. It's too much information mentioning this to be just a coincidence (besides not being impossible).

Humm… Just to be sure, run this on your system: https://www.memtest86.com

 

[Friznit]

You've been more help than I could have possibly hoped and beautifully explained too, thank you.  The 4Gb thing sort of make sense - my naive hypothesis is that something is filling up, hits a 4Gb limit and KSP piles in.  I guess this tends to happen when entering the VAB because it's loading a whole lot of stuff.

What I have done to date:

1.  New RAM (I bought four new sticks and replaced the old stuff, and ran memtest as always with new RAM - no issues)

2.  Reinstalled DirectX

So next steps are:

3. I'm running a search to dig up any and all instances of xinput1_3.dll

4.  Ensure I have only one xinput1_3.dll (and hopefully a good one)

5.  Try removing KSPSteamCtrlr and steam_api from KSP folder.

I'll let you know how I get on and once again, thank you for your kind support - I really appreciate it.

[Chel]

Removing steam_api and KSPSteamCtrlr, or removing any actual game files, can be dangerous. Are you sure you want to do this?

[Friznit]

It can't break it anymore than it already is.  I have two test installs (a vanilla control and a modded test environment) so can't hurt to try.

grep pulled up the following instances of xinput1_3.dll.  The 80Kb are the 32 bit version; 105Kb is the 64 bit version, which as we've seen above is rather oddly shipped by Squad in KSP_x64 plugins.  NFC what the 68Kb version in Steam is.

While I'm OK with removing files from KSP, I'm rather loathe to start deleting stuff from Windows or Steam folders because it tends to break other things.  I might just do it for the sake of Science™ though (with backups, restore points, mirrors and things in place of course).

Spoiler

 

xinput1_3.dll C:\Program Files (x86)\Steam\bin\                                                      08/06/2018   68 KB

xinput1_3.dll C:\Program Files (x86)\Ubisoft\Ubisoft Game Launcher\                12/12/2017   80 KB

xinput1_3.dll C:\Windows\SysWOW64\                                                                      04/04/2007     80 KB

xinput1_3.dll C:\Users\Alex\Desktop\KSP 161\KSP_x64_Data\Plugins\              09/03/2019   80 KB 

xinput1_3.dll C:\Windows\System32\                                                                         04/04/2007   105 KB

 

 

[Lisias]

On 3/17/2019 at 7:37 PM, The_Cat_In_Space said:

Removing steam_api and KSPSteamCtrlr, or removing any actual game files, can be dangerous. Are you sure you want to do this?

No, it's not dangerous. KSP comes without it, these are things that Steam install itself. Non Steam users doesn't have such files - and since @Friznit published his logs, I could compare them with the others people sent me (all the two of them  ), and they all have downloaded KSP from Steam. Long shot, but it makes sense.

The worst that can happen is KSP not running, and all you have to do is to copy the files back.

 

A bit of historical background:

On 3/17/2019 at 7:55 PM, Friznit said:

  Hide contents

 

xinput1_3.dll C:\Program Files (x86)\Steam\bin\                                                      08/06/2018   68 KB

xinput1_3.dll C:\Program Files (x86)\Ubisoft\Ubisoft Game Launcher\                12/12/2017   80 KB

xinput1_3.dll C:\Windows\SysWOW64\                                                                      04/04/2007     80 KB

xinput1_3.dll C:\Users\Alex\Desktop\KSP 161\KSP_x64_Data\Plugins\              09/03/2019   80 KB 

xinput1_3.dll C:\Windows\System32\                                                                         04/04/2007   105 KB

 

SysWow64 is "System for Windows 32 over Windows 64", and it's where they put 32 bits DLLs for 32 bits EXEs running on Windows 64.

System32 is where they put 64 bits DLLs to for 64 bits EXEs.

Don't ask. It's Microsoft - they always were this way.  

— — — — And yet more historical background — — — — 

I just remembered something -I should had studied for Paleontology or something like that.  

A long time ago, in a 16bits addressing space away, 640Kb was enough to anybody.  I'm talking 1981 and IBM PC-XT here, 640Kb RAM and 386Kb of available ROM space, 1Mb of addressing space.

Of course, for years every device drive ever written (we called them TSR - Terminate and Stay Resident) was made with the 8088/8086 in mind. Sooner, 640Kb was not enough anymore, and someone came with a stunt called GATE A20 - they took one sparing pin from the keyboard controller and used it to simulate a 21th address pin (1MB is addressed with 20 pins, 2^20). With that stunt, they allowed some special cards to shove 64K more memory above the top memory (where usually was the BIOS). They used this place to store some device drivers, and so free up the base memory (that first 640Kb thingy).

Nice. So what? Why I'm telling this?

Well… Some device-drivers were buggy, and sometimes forgot to change the A20 line before jumping into there - and then that memory wasn't enabled and the system crashed.

Sometimes, they forgot to disable the damn thing before returning, and then some code using some old tricks of that era ended up overwriting that memory by accident, and then the system crashed. (at that time, we were used to save every possible byte of RAM on the routines, and so sometimes we relied on some hardware properties to induce the desired behaviour, saving some 3 or 4 bytes by omitting the ASM equivalent of a "IF").

All that 4Gb frenzy I saw here made me remember this stunt - we are talking Microsoft, anyway.

When you make a "far call", you push into the CPU's stack the current address so the CPU can RETurn to it later. When you are in 32 bits mode, of course you are using 32 bits memory address.

But now consider that when you are in 64 bits mode, the CPU needs to PUSH a 64 bits address pointer, so it can RETurn to ir later.

If you PUSH a 32 bits and later RETurn in 64 bits mode, you would ending up POPing two unrelated 32bits values and the CPU would ending up RETuring to God Knows where in the memory addressing space.

Likewise, if by accident you made a FAR CALL from 64 bits to a 32 bits routine, if you mess up something, you end up POPing just half the address you really needed, and God knows where in the first half of memory would the CPU ending up RETuring to.

Do you remember that JIT thingy? It's a routine that "recompiles" CIL bytecodes (what C# uses for compiling source code into) into native X64 machine instructions. This happens everytime a CIL code is executed by the first time (on demand) or when the DLL is loaded (on loading), it depends hw the VM implementor decided to do. I think that Mono uses on demand, as it appears.

By analysing the source code for Hyperspace, I learnt that the Mono's VM has also TWO MODES, a 32bits and a 64 bits, being the 32bits locked down on that 4Gb limitation. And now I think you guys are realizing what I have in mind!

Unity is the thing responsible for handling HMI (Human Machine Interface) devices, and Unity needs to cope with 32bits and 64bits environments. So it appears to me that Unity, somehow, is utterly borking on something on Space Center, that in essence, is a scene change from Main Menu to Space Center. The problem described on the OP explained that on 1.5.x (and previous), the crashes were happening while transiting from Flight to Space Center - sometimes, a lot of transitions were needed before the crash.

Knowing KSP as I know today, I learnt that on 1.6.x KSP is doing some optimizations preemptively, and using more memory in advance on loading. Essentially, mimicking the problem we had before, but way sooner.

At that time, I had postulated that, since it's usual that in each Scene we are transitioning from we close the devices we opened at start, and just reopen the devices we will need on the newly loaded Scene, things were crashing on xinput due a buffer or something that suddenly were relocated to a higher memory position after being reopened- it made sense at that time. But I was also thinking that CIL would be handling that 32/64 bits jump stunt in a somewhat smarter way - or I didn't knew that CIL was so dumb on handling 32/64 bits pointers, what is just another way to say the same thing.  

THIS log file, however, makes me wonder that perhaps we are handling a 32 bits FAR CALL from Mono to the XInput DLL, and once the memory use grows up enough (exceeding the 32 bits addressing limits), that FAR CALL cannot reach the native code from XInput anymore.

Since JIT is involved, it's not impossible that Mono itself is causing the problem - but once I learnt that in C# the CIL program needs to handle itself 32 bits and 64 bits address pointers, it may be also another nasty bug on Unity (it's not a bug from Mono if Mono just doesn't have the feature, right?).

t just happens that it's another bug than before, but with the same root causes. Again, it makes sense - a code that doesn't cope with 64 bits memory points will not cope with 64 bit address jumps.

Being this the reason we are not being able to fix the damn thing this time by switching DLLs.

Anyway, I just typed this Thesis here so I can remember this later, when someone else hits here with another similar issue.  

 

Edited March 20, 2019 by Lisias
I'm a I.T. paleontologist! =D (and a tyops adidct!)

[Friznit]

The mind boggles.  I cannot pretend to understand all of that but I do remember messing around with Himem.sys and emm386 in the bad old days, trying to squeeze a few more Kb of RAM out of DOS so I could play Eye of the Beholder!  I'm at work all day but will test the outcome of your hypothesis tonight.  Fingers crossed!

[Friznit]

Some progress at least.  The game is still crashing though I think possibly less often.  Maybe.  Removing the files above has eliminated them from the mix but the crashlog is still reporting xinput1_3 .dll. On a hunch I've tried a variety of different 64 bit versions of the file in the KSP folder but to no avail.  I don't think this file is the root cause of the problem.  Right now I'm entirely at a loss for what to do next other than put up with it.  The game is playable, as long as I don't mind reloading every other time I want to build a ship in the VAB but it's getting mighty tedious.  Maybe 1.7 will fix everything....

Crash log KSP Log  Ouput Log

[Lisias]

1 hour ago, Friznit said:

Some progress at least.  The game is still crashing though I think possibly less often.  Maybe.  Removing the files above has eliminated them from the mix but the crashlog is still reporting xinput1_3 .dll. On a hunch I've tried a variety of different 64 bit versions of the file in the KSP folder but to no avail.  I don't think this file is the root cause of the problem. 

Things changed!

37573 MB paging file [15935 MB free].
134217728 MB user address space [134198049 MB free].
Read from location 1d830008 caused an access violation.

Whatever has crashed this time, it was a different code than the last time. Previously, your KSP were borking by reading from location "0x80" (it has a lot more of zeros to the right.  ), at the very beginning of the addressing space. Now, the thing is capsizing on the location "0x1d830008", where I expect to be C/C++ code (that first half for TEXT, last half for HEAP thingy) - and assuming I remembering it correctly from my C times… It was some time already.

It's kinda weird, but it's an improvement. And I think that there is another test to be tried: put a 32 bits X-Input DLL on your "C:\Users\Alex\Desktop\KSP 161\". It's a long, crazy and perhaps stupid shot - but at this time, there's few to loose. Someone above mentioned fixing the problem by doing exactly this stung  (and I should had paid more attention to him, as it appears - but, well, this is kinda weird...).

I'm sorry I can't help you more on this - I don't have a working Windows machine for KSP,  and I'm pretty sure if I could reproduce the problem on my box, I could try a VisualDebugger session and perhaps get some insight from the guts of the problem.

This is intriguing, this stirred my curiosity (old dog, old tricks - I started my professional career solving these stunts!)

 

1 hour ago, Friznit said:

Maybe 1.7 will fix everything....

It may. Your problem is similar, but also different from the OP, and we were using 1.4.5 or 1.5.x at that time (don't remember precisely now).

Edited March 19, 2019 by Lisias
Entertaining Grammars. :)

[Friznit]

I think that was possibly me in another thread!  I can't recall if I already tried it but I think the 32 bit x_input file in KSP root folder simply gets ignored and Windoze defaults to the x64 version in Sys32.  The only way I can force KSP to use the 32bit version is by replacing the file in Sys32.  It's a temporary workaround at best, because it clearly prevents most other games from working (...there are games other than KSP??  ).  However, I remember that it did eliminate it from the crashlog, so I'll try it again tonight and see what else crops up.

[Friznit]

So I went for the brute force option and copied over the x_input file in Sys32 with the 32 bit version of the file in KSP.  Still CTD'd although no dll's are mentioned in the logs anymore - I guess this rules them out.  Basically, it's FUBAR and I'm out of ideas.  I can't thank you enough for you help but I guess we'll just have to put this one down to bad luck and hope 1.7 fixes the issue.  Sad panda 

FWIW: Crash log KSP Log  Ouput Log

[Lisias]

9 hours ago, Friznit said:

So I went for the brute force option and copied over the x_input file in Sys32 with the 32 bit version of the file in KSP.  Still CTD'd although no dll's are mentioned in the logs anymore - I guess this rules them out. 

I agree. We ruled the DLLs out. Things changed again in a interesting way, apparently:

37573 MB paging file [15752 MB free].
134217728 MB user address space [134198600 MB free].
Read from location ef3e2008 caused an access violation.

The crash is happening again from that "upper memory", where C/C++ data lives and where, probably, CIL code is (as it's data for the C/C++ virtual machine program - sorry being repetitive, but there're more people reading this).

However, I found this on your logs too:

<RI> Initializing input.

XInput1_3.dll not found. Trying XInput9_1_0.dll instead...
<RI> Input initialized.

<RI> Initialized touch support.

-- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- CUT -- 

C:\WINDOWS\SYSTEM32\xinput9_1_0.dll:xinput9_1_0.dll (00007FFF66430000), size: 28672 (result: 0), SymType: '-exported-', PDB: 'C:\WINDOWS\SYSTEM32\xinput9_1_0.dll', fileVersion: 10.0.17134.1

Stubborn code, this thingy. It appears to be committed to crash KSP no matter what. 

An hypothetical next step is obvious, restart the stunt fest on xinput9_1_0.dll .But, frankly? In the next few days 1.7 is will be on the wild, and I bet you are getting pretty "liquided" with all this thing.

 

9 hours ago, Friznit said:

 Basically, it's FUBAR and I'm out of ideas.

I have some, but all bad ones.  Sooner or later I will shove a new GPU card on my Windows rig, and let me tell you - I will see the bottom of this.  

What makes me a "waterfall" of angriness on the subject is that this damned problem doesn't happens on MacOS (and I have no knowledge of the problem on Linux neither). This stunt is happening on Windows, thats just the flagship version of any game - and, as we could see from my previous post, this is not plaguing only KSP (and, who would have thought, Unity appears to be innocent on this one? That would be a new!).

 

9 hours ago, Friznit said:

I can't thank you enough for you help but I guess we'll just have to put this one down to bad luck and hope 1.7 fixes the issue. 

My pleasure. Let us know if things works fine on 1.7.

Best of luck!

 

 

[Raptor42]

Oh, I will definetly try this method, my game started crashing in situations like you are saying, even though I have more than enough RAM to run the game on the max settings, 16GB of RAM to be exact. I will let you know if this helps!

*edit* What you recommended didn't solve my problem, but at least moved it somewhere else. Crash log no longer says KSP_x64.exe caused an Access Violation (0xc0000005) in module KSP_x64.exe at 0033:e88bc559. but it now says
mono.dll caused an Access Violation (0xc0000005) in module mono.dll at 0033:88c334d0. Now I need to solve how to fix that mono.dll crashing, also with the old xinput1_3.dll replaced with the one from system32 folder my RAM usage went up noticeably (from 5GB to 7,5GB), is that something unusual?

Edited March 21, 2019 by Raptor42

[Lisias]

This thread apparently talks about the very same problem, this time on 1.7.

[not exactly. it's either a new problem, or the old one decided to peek another victim! This is different!]

@Friznit, how is 1.7 behaving on your rig?

Edited April 11, 2019 by Lisias
MOAR INFO!

[Friznit]

Not tried it yet.  One thing I've noticed after long and tortuous testing is that any planet packs tend to cause the issue far more regularly.  The exact same mod pack running without a planet pack is remarkably stable.  Although I do still get the occasional CTD when entering the VAB, it's about once a (real time) day rather than every time.

If that's the case I won't be able to repro the issue until Kopernicus is updated for 1.7

Edited April 11, 2019 by Friznit