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

[JoE Smash]

29 minutes ago, Lisias said:

Bill Gates didn't did all of that alone. To tell you the true, a lot of problems and bad practices we atribute to them (Microsoft) was, actually, misdemeanor from their "alies". People found a way to commercially exploit something on the Microsoft eco-system (including the flaws), and them coerced them into maintaining the bug/exploit.

In the 80's and early 90's, Microsoft was not this giant we know nowadays. A big player could manage to hit a serious blow on them, and some of these blows would be unrecoverable at that time.

Do you want to know something that Microsoft did right, but yet everybody else managed to twist it agains them? DPMI.

Here is the full True History of DPMI, directly from the trenches:

https://lists.gnu.org/archive/html/lynx-dev/1998-04/msg00773.html

Now you are "dating" all of us. I don't mean romantically, I mean age. 

I remember trying to clear my first 640K of memory to at least above 591K with Memmaker I believe it was, so Darklands by Microprose would frigging run. 

I grew up playing sierra games on DOS in 1992. I used and sometimes miss the simplicity of Dosshell. I don't need all this stupid crap that is in Windows now. Every new version of Windows that comes out they make it hard and harder to do simple crap like find my damn Device Manager, or Control Panel, or Add and Remove Programs, or even a DOS prompt....

They keep burying everything I need under more and more menus and buttons and searches...

They also keep hardwiring more and more crap I don’t want running in the background at all like frigging Cortana, or Windows Defender or even Windows update.

Everything requires I search Google for how and then I have to use regedit to force crap off that I didn't want on in the first place.

Windows is riduculous now and it's too big, and it has too many moving parts and built in junk and eats too many resources. I HATE IT! But I still hate Apple more and I never took the time for Unix or Linux, so I'm stuck with her like a fat ugly ex-wife...

 

 

10 minutes ago, Lisias said:

 

The main botleneck is CPU. You have "too much memory", and the CPU will be put into its knees on Garbage Collecting.

 

Well I'll have to reinstall Memgraph to cut out some of the garbage collecting and Janitors Closet to prune part files.....both currently maintained by Linuxgurugamer 

Edited July 31, 2018 by JoE Smash

[JAFO]

9 hours ago, Lisias said:

Do you want to know something that Microsoft did right, but yet everybody else managed to twist it agains them? DPMI.

Here is the full True History of DPMI, directly from the trenches:

https://lists.gnu.org/archive/html/lynx-dev/1998-04/msg00773.html

Ahh.. I missed out on the whole early PCs saga, thankfully.. I was into the UNIX-based Amigas back then.. Never touched a Windows machine until Win98SE was a thing. And not long after that, XP was released. My attitude/opinion is that it took Micro$oft until then to get things half-way right.

Edited August 1, 2018 by JAFO

[JoE Smash]

So copying a copy of the 64 bit xinput1_3.dll from Windows\system32 to the KSP_x64_Data\Plugins folder and deleting the 32bit copy already there appears just as stable as the other way around.....as far as multiple crashes to desktop go.

I'm  still no longer crashing to desktop after playing briefly.

However I have now noticed that after changing scenes and reverting flights more and more of my RAM is being used over time and not being released.

Historically there have been threads and bug reports about this situation  (I have done searches). I believe Squad believes they fixed this issue in an earlier release, but I vote they have not.

I don't think this is happening because of my xinput1_3.dll swap, but I'm not positive because back when it was crashing frequently I was focusing all my energy on fixing that, not looking for additional issues. Now that I have the crashing under control I can look for more issues...lol.

Of course I suppose one of the 100 mods I have installed could also be the thing causing me to slowly tie up all my RAM, but to be honest I don't really feel like uninstalling all the mods for a third time to see if I can pinpoint which one might be doing this.

If anyone playing already knows of mods that do this, or can confirm the stock game is still using more and more RAM every time you launch and revert a flight back to the VAB, I'd appreciate the heads up.

You can visualize this by playing the game with Task Manager opened in the background  (by holding down CTRL+ALT+DEL) and ALT+TABbing to take note of how much RAM is being used before and after reverting a flight....

Someone in another thread historically said having tree scatter enabled in graphics settings causes this....I do have tree scatter enabled....I guess I could at least try turning that off at some point and checking on this more....

Edited August 2, 2018 by JoE Smash

[JPGSP]

On 7/29/2018 at 1:54 AM, JoE Smash said:

copy of the file

What file?

[Lisias]

On 8/2/2018 at 12:14 PM, JoE Smash said:

I don't think this is happening because of my xinput1_3.dll swap, but I'm not positive because back when it was crashing frequently I was focusing all my energy on fixing that, not looking for additional issues. Now that I have the crashing under control I can look for more issues...lol.

[…..]

Someone in another thread historically said having tree scatter enabled in graphics settings causes this....I do have tree scatter enabled....I guess I could at least try turning that off at some point and checking on this more....

There's a thing on 32 bits code: it can handle only 4GB of RAM, and that's it.

So, by using a 64 bit DLL you probably solved the crash as KSP would be trying to give the 32 bit DLL a pointer above his addressing capabilities, and then everything goes kaput. With a 64 bits DLL, you could reproduce on KSP-Win64 an issue that we from MacOS and Linux are complaining for a long time: huge memory leak.

I will give this Tree Scatterer thing a try to see what happens. I'm pretty used to my KSP process growing up to 10 to 12 Gigabytes of RAM as time goes by (I'm running it on a 16Gb RAM MacMini).

In time, would not be 'Terrain Scatter'? There're no "Tree Scatter" on my KSP, only "Terrain Scatter"

[JoE Smash]

9 hours ago, Lisias said:

There's a thing on 32 bits code: it can handle only 4GB of RAM, and that's it.

So, by using a 64 bit DLL you probably solved the crash as KSP would be trying to give the 32 bit DLL a pointer above his addressing capabilities, and then everything goes kaput. With a 64 bits DLL, you could reproduce on KSP-Win64 an issue that we from MacOS and Linux are complaining for a long time: huge memory leak.

I will give this Tree Scatterer thing a try to see what happens. I'm pretty used to my KSP process growing up to 10 to 12 Gigabytes of RAM as time goes by (I'm running it on a 16Gb RAM MacMini).

In time, would not be 'Terrain Scatter'? There're no "Tree Scatter" on my KSP, only "Terrain Scatter"

Hey man, long time no talkie.

Well that makes sense (the part above about memory addresses).

Yeah I think I probably meant terrain scatter. That's what controls the amount of trees or whatever appears on the ground in each biome....

I never came back to the thread after that lol. 

I believe I pinpointed the leak to using EVE with forcing dx11.

I don't have it with EVE when using openGL though....

The problem now is different modders only supporting DirectX or OpenGL with their mods all willie nilly.

Galileo is aware of DirectX causing weird lines and issues with his mods and he refuses to fix it. He says he won't support DirectX with his mods unless the game in general moves to only support DirectX 11.

I made Waz aware of the EVE leak and that so far has resulted in a blurb about it in his OP for EVE. Don't know if he's going to fix it or anything.

The BDArmory mod, which I don't use because I don't play this to shoot at kerbal ships with guns, has a problem with OpenGL.

JLRepo who is a modder AND a dev says to use DX11 with his telescope mods....Tarsier Space Technologies or whatever. I do use that one, so I guess I don't get to have cool reflective mirrors on the James Webb because I ALSO would like clouds in my game and Galileo will only support openGL thus far....

I guess until everyone can get on the same page and support both types of graphics even if doing that is more work, then you have to pick and choose what you can have in your game....

Edited August 16, 2018 by JoE Smash

[JoE Smash]

23 hours ago, JPGSP said:

What file?

@JPGSP, did you come to this thread because you play KSP in 64bit mode and you are having regular crashes?

If so, what solved it for me was copying a copy of xinput1_3.dll from my Windows/system32 folder to the KerbalSpaceProgram/KSP_x64_Data/Plugins folder and deleting or renaming or relocating the copy of xinput1_3.dll that was already in that folder.....because it is a 32bit copy of the dll.

The one you are borrowing from your Windows folder is 64bit and the propper dll if you are playing the 64bit version of the game by using the KSP_x64.exe to launch KSP into 64bit mode....

The regular installation of the game seems to install itself with the wrong version of that file for the 64bit version of the game....

[Lisias]

The thing about this OpenGL/DirectX is Unity's lack of support for a lot of fancy features. So people must go around Unity and do things "the dirty way".

I understand some people avoiding DirectX. A substantial part of KSP players are not on Windows, and using DirectX would alienate these guys - me included.

Interesting news the leak happening on DirectX and not on OpenGL…

[JoE Smash]

13 minutes ago, Lisias said:

The thing about this OpenGL/DirectX is Unity's lack of support for a lot of fancy features. So people must go around Unity and do things "the dirty way".

I understand some people avoiding DirectX. A substantial part of KSP players are not on Windows, and using DirectX would alienate these guys - me included.

Interesting news the leak happening on DirectX and not on OpenGL…

I'm not a leak expert. I was just watching my RAM in the task manager slowly fill up over time while using EVE (and only EVE....no other mods) for clouds with directx11 and it not happening with OpenGL.

It slowly filled up even with the game "paused" with the ESC menu open.

For visual mods that use EVE for clouds (which appears to be all of them) the more complex the cloud layer configs, the faster the RAM gets eaten while in directx11 mode.

So basically if you want a visual mod with clouds and you don't want to excessively leak RAM, I recommend openGL.

Edited August 16, 2018 by JoE Smash

[Tonka Crash]

Just for a point of comparison, my computer is a 2 month old clean install of Windows 10 Pro 1803 with KSP as the only game ever installed by direct download from Squad, Steam has never been installed. 

Searching the hard drive the only result for xinput1_3.dll is the one in the KSP_x64\Plugins directory. No other exist on my computer.

In my output_log.txt there is a line: XInput1_3.dll not found. Trying XInput9_1_0.dll instead...

Searching for Xinput9_1_0.dll I get :

C:\Windows\System32\XInput9_1_0.dll
C:\Windows\SysWOW64\XInput9_1_0.dll
C:\Windows\WinSxS\amd64_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_18785281a71ced90\XInput9_1_0.dll
C:\Windows\WinSxS\x86_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_bc59b6fdeebf7c5a\XInput9_1_0.dll

 

[JoE Smash]

6 minutes ago, Tonka Crash said:

Just for a point of comparison, my computer is a 2 month old clean install of Windows 10 Pro 1803 with KSP as the only game ever installed by direct download from Squad, Steam has never been installed. 

Searching the hard drive the only result for xinput1_3.dll is the one in the KSP_x64\Plugins directory. No other exist on my computer.

In my output_log.txt there is a line: XInput1_3.dll not found. Trying XInput9_1_0.dll instead...

Searching for Xinput9_1_0.dll I get :

C:\Windows\System32\XInput9_1_0.dll
C:\Windows\SysWOW64\XInput9_1_0.dll
C:\Windows\WinSxS\amd64_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_18785281a71ced90\XInput9_1_0.dll
C:\Windows\WinSxS\x86_microsoft-windows-directx-xinput_31bf3856ad364e35_10.0.17134.1_none_bc59b6fdeebf7c5a\XInput9_1_0.dll

 

I did research about what this file is actually for, because when I first discovered the issue I had no idea what was going on at all.

It is a file that is involved in controller support for Xbox game pad controllers, which are now supported for many PC games....

I often use an Xbox or PS4 controller through Steam to play games with....including flying a plane in KSP.

For KSP there is an "advanced fly by wire" mod currently being kept alive by Linuxgurugamer:

I am not sure why you don't have the file in question already on your computer....

I do know that I play A LOT of PC games and I often use a gamepad, so I probably ended up with the file on my computer as the result of an older Steam game requiring me to install an old Directx 9 redistributable.....which probably installed many old directx files that I was missing for backwards compatibility with old games....or something along those lines....

I know newer versions of Windows now updates DirectX through the Windows Update feature. 

Windows hasn't released a distributable copy of DirectX in like a decade. The most recent copy of DirectX that is free to download and install is one from June of 2010 I believe.

If you Google that you will probably find it....I did....

[Tonka Crash]

I installed Forza 7 on my PC and tried the XBox One controller, no problems. I haven't tried AFBW, but I might try it this weekend when I have time. I did another search of my computer and still don't have any more xinput files installed.

I'm not complaining, as I'm not having any problems. I just offer this up for comparison to your system. My relatively clean system doesn't have problems and doesn't have numerous versions of the xinput dll. Your dll problem may be that KSP is actually finding a xinput1_3.dll when it should fail and fall over to using XInput9_1_0.dll. If your solution is working for you, great, but it may not be the best solution.

[JoE Smash]

37 minutes ago, Tonka Crash said:

I installed Forza 7 on my PC and tried the XBox One controller, no problems. I haven't tried AFBW, but I might try it this weekend when I have time. I did another search of my computer and still don't have any more xinput files installed.

I'm not complaining, as I'm not having any problems. I just offer this up for comparison to your system. My relatively clean system doesn't have problems and doesn't have numerous versions of the xinput dll. Your dll problem may be that KSP is actually finding a xinput1_3.dll when it should fail and fall over to using XInput9_1_0.dll. If your solution is working for you, great, but it may not be the best solution.

Yeah I have a ton of xinput files...

Xinput1_1.dll, xinput1_2.dll, xinput1_3.dll, xinput1_4.dll, xinput1_5.dll  and the xinput9_whatever.dll you mentioned....

I actually updated my solution to moving the file from Windows to the appropriate KSP Plugins folder.

Obviously your version of the game is still looking for it, but it isn't present so it is defaulting to a totally  different version of xinput.

I wonder what would occur if you copied the version you DO have to KSP_x64_Data/plugins and renamed the xinput1_3.dll there to some other name....what your log would then say instead....

If that broke the game you could always revert the change.

I'm just curious at this point....as a scientist....

KSP is looking for xinput1_3.dll by default because that is what the developers included with the installation of the game. The problem is they included a 32bit file in a 64bit installation folder....with several other dlls that are all 64bit

Edited August 17, 2018 by JoE Smash

[Kowgan]

That's one long discussion, but I'm glad I arrived before it became necro.

First of all, thanks for the workaround, @JoE Smash. I've replaced my KSPx64 plugin with the one from system32 and will check if the crashes stop.

Now, what doesn't make sense to me is how this is even fixing the problem.
- If KSP is using the dll from system32, how is placing that file in the KSP folder gonna result any differently?
- If KSP tries but fail to use the KSP Folder version of the dll, then imports the version from system32, why does the game even crash to begin with (since it's importing the 'good' version')?
- Most amazingly, how did your KSP stop crashing when you removed the (good?) dll from system32 and replaced it with the (bad?) dll file from the KSP folder?

It just doesn't make sense that replacing either File 1 with File 2, OR File 2 with File 1 simply fixes the issue.
Then again, it's Windows, so, go figure...

[JoE Smash]

35 minutes ago, Kowgan said:

That's one long discussion, but I'm glad I arrived before it became necro.

First of all, thanks for the workaround, @JoE Smash. I've replaced my KSPx64 plugin with the one from system32 and will check if the crashes stop.

Now, what doesn't make sense to me is how this is even fixing the problem.
- If KSP is using the dll from system32, how is placing that file in the KSP folder gonna result any differently?
- If KSP tries but fail to use the KSP Folder version of the dll, then imports the version from system32, why does the game even crash to begin with (since it's importing the 'good' version')?
- Most amazingly, how did your KSP stop crashing when you removed the (good?) dll from system32 and replaced it with the (bad?) dll file from the KSP folder?

It just doesn't make sense that replacing either File 1 with File 2, OR File 2 with File 1 simply fixes the issue.
Then again, it's Windows, so, go figure...

Yeah.....I still don't completely understand how or why this helps....I think @Lisias, has a better understanding of why and how.... and it was some really long winded explanation about dll files...lol

There is some sort of explanation in this thread from him if your read through it....we discussed it after I reported it....

All I know is I was crashing all over the damn place before I discovered this issue....and now magically I am not....

I have at least one confirmed report of this helping someone else (I think) from @JPGSP, we were writing back and forth via forum mail a day or two ago. I asked him to report back here if it definitely helped....either it did help and he forgot to mention it here, or it didn't and he gave up....lol....

[Kowgan]

Yeah. Well, unfortunately for me, my crashes didn't stop. I'm trying to reproduce the issue under stock KSP and will create a thread soon™.
In any case, thanks for the thread. This issue has been going on for a long time, and I'm sure many other players have experienced it. Hopefully this will help most of them.

[JoE Smash]

1 hour ago, Kowgan said:

Yeah. Well, unfortunately for me, my crashes didn't stop. I'm trying to reproduce the issue under stock KSP and will create a thread soon™.
In any case, thanks for the thread. This issue has been going on for a long time, and I'm sure many other players have experienced it. Hopefully this will help most of them.

That sucks. Do you have error logs and stuff?

Usually if you zip the error log, KSP log, and Output log and upload them to like Dropbox and share the link in the appropriate technical support thread people will try to help.

Amazingly it seems like almost NO Squad staff help though.....I always thought the point of game forums was to get help with the game from people involved with the inner workings of the game....not just bored people....

If you look in this thread, there is like one staff response and it was  basically, "that's not my department...."

Edited August 22, 2018 by JoE Smash

[Kowgan]

Yes, here's the thread: https://forum.kerbalspaceprogram.com/index.php?/topic/177761-crashes-upon-reloading-vabsphlaunch-excessively/

What confuses me is that the error seems to be related to lack of available RAM. Although I have 16GB of RAM, KSPx64 only uses about 4GB - including during the time of crash - and I still had about 50% RAM free during the crash reported there. So I have no clue why it says I've ran out of memory.

But this is unrelated to this thread, so I'll stop the offtopic here.

Edited August 22, 2018 by Kowgan

[Lisias]

8 hours ago, Kowgan said:

What confuses me is that the error seems to be related to lack of available RAM. Although I have 16GB of RAM, KSPx64 only uses about 4GB - including during the time of crash - and I still had about 50% RAM free during the crash reported there. So I have no clue why it says I've ran out of memory.

I run KSP on a Mac machine, and it's usually eats up 10 to 12G of RAM.

If your KSPx64 is consistently dying at 4GB of memory allocated by the process, I definitively would bet on some 32 bits DLL somewhere in the System being used by KSP, and getting killed when KSP reaches that memory limit and the get shoot on the feet when it calls that DLL using a memory pointer above that.

If the XInput trick didn't helped you, there's a good change that something else on your system is getting into this.

Another thing is VRAM memory. Each texture you add to KSP via mods eats VRAM from the GPU Card. When you exhaust your VRAM, Unity also crashes without any clue about the reason.

[Kowgan]

@Lisias That's really good info, thank you.

Although my KSP goes a bit over 4GB (4.1, 4.2) without crashes, I guess it makes sense that it only crashes when a 32bit DLL is called.

About the GPU Card. I got 2GB on my GPU, and I was wondering if running out of memory on it could cause a crash, but since I've never seen it mentioned before, I thought it would be stupid to think so.
Now that you've mentioned it, I guess KSP's (or Unity's infamous) garbage collector might be causing that GPU memory overload, and thus, leading it to a CTD. If that's the case, there's not much I can do.

Still, it's good to know the probable causes.

Edited August 23, 2018 by Kowgan

[Lisias]

1 hour ago, Kowgan said:

@Lisias Now that you've mentioned it, I guess KSP's (or Unity's infamous) garbage collector might be causing that GPU memory overload, and thus, leading it to a CTD. If that's the case, there's not much I can do.
 

You can increase the texture compression (I use x2 on my rig), or delete one or two less needed Mod. I have 4 installments for KSP here, each one specialized on a Mission exactly due that.

[Gordon Dry]

The xinput1_3.dll in Kerbal Space Program\KSP_x64_Data\Plugins\ still is the 32 bit version ...

[Gordon Dry]

^ @SQUAD some interesting fact here regarding xinput1_3.dll

[eightiesboi]

Spoiler

 

I too noticed an immediate improvement after subbing the xinput1_3 file from the windows directory into my KSP directory. I have a fairly robust system (Core I7, Nvidia 1060, 32 GB of RAM) on my modded (160+) install. I was crashing randomly after about 2 hours of play. Crash logs showed my memory utilization to be generally low, yet it was the same access violation and same files as the OP. Since subbing out xinput1_3, I have been able to leave KSP running in flight, tracking station, and space center scenes for over 24 hours (each) AND resume playing at irregular intervals (whenever KCT finishes building the next rocket or KAC sets off an alarm). My goal is to run KSP in real time full time on a dedicated system, which now seems possible. I have not experienced any issues with the file substitution.

If someone has Squad's ear and can ask them to look into this, I think @JoE Smash may have fixed this particular crash cause.

[Friznit]

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!