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

[JoE Smash]

Hello,

I have been reading everything I can find about Kerbal Space Program and crashing. There are NUMEROUS threads about it over the last FOUR years, but nothing in any of the threads here, or on Steam, or various reddits have done anything to fix the problem.

I run the 64bit version. I have 64bit Windows 10 Home Edition. I have an Intel Core i7 2.6Ghz CPU. I have 16GB of 1600mhz RAM. I have an NVIDIA Geforce GTX 980M with another 4GB of RAM.

My rig can run Skyrim or Fallout 4 with pretty much maximum graphical settings without regular crashing and with smooth gaming.

The graphics in KSP are nothing to write home about, so the total lack of stability is pretty sad.

Now, I DO run about 100 mods, but I get them through CKAN and they are installed properly and with very few exceptions they are of the appropriate version to match the 1.4.3 KSP version I am running. The handful that are a for an earlier 1.4.x, I asked in the corresponding thread if they are compatible and the answer was yes.

Despite this my game was regularly crashing after trying to return to or exit the VAB/SPH after a flight. After leaving and entering the ship building buildings several times my game would crash. Since the game takes about 10 minutes to load with a lot of mods, waiting for it to load over and over to play for about 5 minutes is pretty damn tedious. I was spending more time watching the loading screen than playing the game.

I have about 20 crash.dmp files that I have no way to open or read myself and taking the time to zip them with the Output_log, error log, and KSP log files and then uploading them to dropbox to post a link here... and then get no response from any of the Devs is obviously not worth anyone's time.

So I did my best to try to solve this on my own....

Out of all of the Error reports generated with the crash.dmp files my RAM was averaging 50%-60%, but despite this Linuxgurugamer suggested I was running out of RAM or my RAM was bad. I put Memtest86 on a USB drive and ran multiple passes.....my RAM is not bad and has no errors. Since more then half of it isn't being used by the game or the mods, I don't understand how I could be running out of it. I don't have anything else running in the background. I disabled all my Windows startup processes.

I've tried forcing OpenGL, DirectX11, and DirectX12. It crashes with all of them. When I use OpenGL I get an additional module/file listed in the error report:

Spoiler

Module 3
C:\WINDOWS\System32\DriverStore\FileRepository\nvami.inf_amd64_bab342ed51c72a38\nvoglv64.dll
Image Base: 0x6cc50000  Image Size: 0x024f8000
File Size:  38516152    File Time:  2018-05-08_172236
Version:
   Company:    NVIDIA Corporation
   Product:    NVIDIA Compatible OpenGL ICD
   FileDesc:   NVIDIA Compatible OpenGL ICD
   FileVer:    24.21.13.9764
   ProdVer:    24.21.13.9764

When I don't force OpenGL I get the same two modules listed typically:
 

Spoiler

 

Module 1
C:\WINDOWS\SYSTEM32\xinput1_3.dll
Image Base: 0x00400000  Image Size: 0x0001e000
File Size:  107368      File Time:  2007-04-04_195422
Version:
   Company:    Microsoft Corporation
   Product:    Microsoft® DirectX for Windows®
   FileDesc:   Microsoft Common Controller API
   FileVer:    9.18.944.0
   ProdVer:    9.18.944.0

Module 2
C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\steam_api64.dll
Image Base: 0x6cc10000  Image Size: 0x0003e000
File Size:  235600      File Time:  2018-07-05_233110
Version:
   Company:    Valve Corporation
   Product:    Steam Client API
   FileDesc:   Steam Client API
   FileVer:    3.42.61.66
   ProdVer:    1.0.0.1   

 

The one thing that is consistent in EVERY crash I have had is I get KSP_x64.exe caused an Access Violation (0xc0000005), and Xinput1_3.dll is involved.

I then did a file search for xinput1_3.dll and noticed it is located in several different places in my C drive. I also noticed that it came in different file sizes. So I Googled about it on the Internet. I learned that there is a 32bit and 64bit version of it. The 64 bit file size is about 105KB and the 32bit version is about 80KB. As you can see from my second spoiler above it is using the larger file size which makes sense because I am running the 64bit version of KSP.....I also learned that System32 is the 64bit program folder for Windows and Syswow64 is the 32bit folder.....that doesn't make sense to me and seems counter-intuitive....

What also doesn't make sense to me after doing my file search for that file, is WHY Kerbal Space program comes with two copies of it, one in KSP_Data\Plugins and one in KSP_x64_Data\Plugins and when I run the game with the KSP_x64 shortcut on my desktop it uses NEITHER of them? If you look at what is says in the error above it is using MY Windows copy of it in C:\WINDOWS\SYSTEM32\xinput1_3.dll. Why is it using the one in my windows folder when the game comes with it's own two copies?

Then I noticed BOTH the copies installed with KSP are of the 80KB variety, which as I stated is most likely the 32bit version of the file....WHY would the 64bit version of the game come with a 32bit .dll file....one it isn't even utilizing...

So I tried something crazy. I went in my windows\system32 folder and renamed the xinput1_3.dll there xinput1_3_fail.dll, and then I copied and pasted a copy of the file from the KSP_x64_data\Plugin folder into my windows\system32 folder.....which is something REALLY stupid to do, and I REALLY need to remember I did that, because it will probably break every other 64bit game I try play.

So far my game hasn't crashed once and I intentionally went in and out of the VAB and SPH buildings like 20 times each and launched and reverted flights like 20 times.....something I could normally get away with like 4 times and the game still hasn't crashed. So now the 64bit version of the game is most likely utilizing a 32bit dll located my 64bit Windows folder....

People say KSP 64bit version is unstable....maybe it would run better if the game actually utilized the files that are installed with it....

I noticed there are several other .dll files listed in the Plugin folders.....is KSP not actually running those files either?

How do I direct the KSP executable to run the actual dll files that come installed with the game?

I don't think that is something I can do on my end without learning programing language and Unity and rewriting the game myself....

Could one of the Squad Devs please patch the game to actually utilize the dll files that come installed with the game, and ensure they are the ones in the correct corresponding plugin folder in one of the future updates please?

This is a list of all the .dll files in the plugin folder that MAY not be being utilized by KSP but probably should be: (I am basing this assumption on the fact it wasn't using the xinput1_3.dll in the plugin folder.....but maybe it is.....how can I tell? Maybe this was all because the 64bit plugin folder has the 32bit dll and windows 64bit is running the 64 bit version and this was some kind of mismatch error.....and now that I have the same file in both places they match now....I really don't know what's happening for sure. All I know is doing this made my game MUCH more stable in general)

CSteamworks

DIWrapper

lingoona.grammar.kerbal

xinput1_3

XIWrapper

Hope this helps someone else suffering from frequent crashing......!

JoE Smash

NOTICE: FOR THOSE OF YOU JUST READING MY ORIGINAL POST, I FOUND A BETTER FIX....

Go to your Windows/system32 folder and find xinput1_3.dll and copy it.

Go to your KerbalSpaceProgram/KSP_x64_Data/Plugins folder and delete, rename, or relocate the copy of xinput1_3.dll that is already in that folder.

Copy the copy from your Windows/System32 folder to the plugins folder I just directed you to.

This also seems to fix the issue and you do not have to mess with your Windows files....which is never smart....

Edited August 16, 2018 by JoE Smash
Typo

[4x4cheesecake]

Interesting, I'm quiet curious if it is a long term solution or just some coincidence.

1 hour ago, JoE Smash said:

The graphics in KSP are nothing to write home about, so the total lack of stability is pretty sad.

Well, graphics and stability are not correlated. You can crash a console application without any graphics just by trying to devide by 0

1 hour ago, JoE Smash said:

get no response from any of the Devs is obviously not worth anyone's time.

That's a bit unfair. You run 100 mods, what do you expect the devs to do? If you cannot recreate the issue in a stock install, it is not an issue SQUAD has to care about and if it is a specific mod or combination of mods, you have to find the mod or mod combination on your own and report the issue to the mod dev(s).

1 hour ago, JoE Smash said:

xinput1_3.dll. Why is it using the one in my windows folder when the game comes with it's own two copies?

I don't know it, but take a look at the minimum system requirements of KSP for Windows:

• OS:Windows Vista SP1
• Processor:Core 2 Duo
• Memory:3GB RAM
• Graphics:DX10 (SM 4.0) capable, 512MB VRAM
• Hard Drive:4 GB HD space

(copied from steam)

DirectX is NOT required to run KSP but 'xinput1_3.dll' is a (redistributable) part of DirectX (If DirectX is required for any game, there is a separate sub-point in the list). So I have to assume, that if your system does not provide this file, KSP will use the one delivered with the game itself.
 

If you are curious, you can try to reinstall DirectX to see if the issue got fixed by a fresh 'xinput1_3.dll' as well

[JoE Smash]

1 hour ago, 4x4cheesecake said:

 

That's a bit unfair. You run 100 mods, what do you expect the devs to do? If you cannot recreate the issue in a stock install, it is not an issue SQUAD has to care about and if it is a specific mod or combination of mods, you have to find the mod or mod combination on your own and report the issue to the mod dev(s).

I don't know it, but take a look at the minimum system requirements of KSP for Windows:

• OS:Windows Vista SP1
• Processor:Core 2 Duo
• Memory:3GB RAM
• Graphics:DX10 (SM 4.0) capable, 512MB VRAM
• Hard Drive:4 GB HD space

(copied from steam)

DirectX is NOT required to run KSP but 'xinput1_3.dll' is a (redistributable) part of DirectX (If DirectX is required for any game, there is a separate sub-point in the list). So I have to assume, that if your system does not provide this file, KSP will use the one delivered with the game itself.
 

If you are curious, you can try to reinstall DirectX to see if the issue got fixed by a fresh 'xinput1_3.dll' as well

A lot of people run a lot of mods, that's why they have a modded technical support. Also this is a reference to another situation where I requested assistance almost a month ago and got no response from anyone. In that thread that is still the case.

It also crashes stock, it just takes slightly longer. All you have to do to recreate it is play the game....it eventually crashes to desktop it's just a matter of time. When I tried to solve my last issue no one helped me with, I uninstalled all my mods a few at a time and then eventually uninstalled the whole game, and then deleted everything left behind. I reinstalled the game stock and it still crashed. It's probably because of this issue I found.

If that is a link of the requirements, it says DX10....DX10 IS DirectX. You can't really have a game with graphics that runs at this point without it (well there's OpenGL...). Directx 9 has been installed with games for the last two decades. Directx12 is supplied automatically by Windows now, and there is no stand alone redistributable for it. It updates via Windows update. The most recent distributable version of Directx is from June of 2010.

The game doesn't fully support dx11 or 12 which is ridiculous for a game from this decade seeing as DirectX 11 came out in the first quarter of 2011.

This still doesn't answer the question of why the game installs with two copies of a directx file that it doesn't seem to utilize, yet it is running the one from my Windows folder. Or why both copies it supplies are of the 32 bit variety, even though one of the folders with the file is for the 64bit version of the game....

Edited July 29, 2018 by JoE Smash
Commas

[4x4cheesecake]

5 minutes ago, JoE Smash said:

A lot of people run a lot of mods, that's why they have a modded technical support.

I know and usually people post their log and other people tell them which mod causes an issue. Sometimes it is possible to present a solution like 'you missed a dependency' or 'that's an old version, get the new one' and sometimes all you can say is 'contact the mod creator of mod xyz'. This is just possible if the log contains distinct errors. But sometimes there are no distinct errors in the log, than all you can do is removing mod by mod until the issue does no longer appears. It is a tideous task, so it is unlikly some will do it for you.

15 minutes ago, JoE Smash said:

Also this is a reference to another situation where I requested assistance almost a month ago and got no response from anyone. In that thread that is still the case. 

I saw the thread recently and I actually posted an answer, so this is not true anymore You may not like the answer, but there is one.
Usually, when no one answeres to a question, these reason is pretty simple: no one got an idea or solution. You cannot blame people for not knowing something. And if you really want a response from a SQUAD member, you can always ping one of them.

17 minutes ago, JoE Smash said:

It also crashes stock, it just takes slightly longer. All you have to do to recreate it is play the game

I'm not playing the game for years like other, I found it just recently and started with KSP 1.4.1. I had not a single crash in a stock game and just a few with mods installed, so I'm confident to say: I cannot recreate the issue in a stock game.

21 minutes ago, JoE Smash said:

If that is a link of the requirements, it says DX10....DX10 IS DirectX

"Requires DX10" and "requires a DX10 capable graphics card" is not the same. The first one uses the whole install of DX10, the latter one uses just parts of it.

24 minutes ago, JoE Smash said:

Directx12 is supplied automatically by Windows now and there is no stand alone redistributable for it.

This accounts for win 10, but not for win vista, which is the minimum requirement.

27 minutes ago, JoE Smash said:

This still doesn't answer the question of why the game installs with two copies of a directx file that it doesn't seem to utilize, yet it is running the one from my Windows folder. Or why both copies it supplies are of the 32 bit variety, even though one of the folders with the file is for the 64bit version of the game

I already told you my idea about the first part but I have no answer to the question why both files seem to be the 32bit version.

[JoE Smash]

1 hour ago, 4x4cheesecake said:

I know and usually people post their log and other people tell them which mod causes an issue. Sometimes it is possible to present a solution like 'you missed a dependency' or 'that's an old version, get the new one' and sometimes all you can say is 'contact the mod creator of mod xyz'. This is just possible if the log contains distinct errors. But sometimes there are no distinct errors in the log, than all you can do is removing mod by mod until the issue does no longer appears. It is a tideous task, so it is unlikly some will do it for you.

I saw the thread recently and I actually posted an answer, so this is not true anymore You may not like the answer, but there is one.
Usually, when no one answeres to a question, these reason is pretty simple: no one got an idea or solution. You cannot blame people for not 

"Requires DX10" and "requires a DX10 capable graphics card" is not the same. The first one uses the whole install of DX10, the latter one uses just parts of it.

This accounts for win 10, but not for win vista, which is the minimum requirement.

I already told you my idea about the first part but I have no answer to the question why both files seem to be the 32bit version.

Yeah it pretty much is the same....

I think you are just one of those annoying people who likes to argue for arguments sake....

DirectX 10 comes with Windows Vista. Learn to Google...

Shader Model 3.0 was first supported with DirectX 9.0c....which was released in like 2004....

Edited July 29, 2018 by JoE Smash

[4x4cheesecake]

11 minutes ago, JoE Smash said:

I think you are just one of those annoying people who likes to argue for arguments sake....

Indeed, I like to argue..it is am opportunity for both sides to learn something. But I don't want to annoy you...well, bye then

[Gargamel]

24 minutes ago, JoE Smash said:

I think you are just one of those annoying people who likes to argue for arguments sake....

I believe you are quite wrong in this case.  @4x4cheesecake is a very helpful and learned poster on this forum, and to discredit them with such a banal response is an insult to everybody on here.  

This forum is primarily community driven.  We have chosen to take our personal time to help others as we can.  When we are presented with an issue we do not know the answer to, usually we keep our nose out of the issue.  The dev's are under no obligation (I believe) to come here and provide support, yet they still do when needed.   If you need dev support in particular, then a bug tracker is usually required, yet I see no bug tracker link.  When your install is loaded with mods, there is not much a dev can do anyways.  So to try to drop the burden on them is also quite an insult. 

Edited July 29, 2018 by Gargamel

[JoE Smash]

5 minutes ago, Gargamel said:

I believe you are quite wrong in this case.  @4x4cheesecake is a very helpful and learned poster on this forum, and to discredit them with such a banal response is an insult to everybody on here.  

This forum is primarily community driven.  We have chosen to take our personal time to help others as we can.  When we are presented with an issue we do not know the answer to, usually we keep our nose out of the issue.  The dev's are under no obligation (I believe) to come here and provide support, yet they still do when needed.   If you need dev support in particular, then a bug tracker is usually required, yet I see no bug tracker link.  When your install is loaded with mods, there is not much a dev can do anyways.  So to try to drop the burden on them is also quite an insult. 

Well that's unfortunate....why have threads for technical support if the people who designed the game and are the most qualified to offer technical support don't do so?

As far as him being helpful, he has offered no solutions in my two threads requesting solutions. All he has done is taken my posts and deconstructed them into statements and then did his best to refute or say something contrary to each statement I made. I call that the opposite of helpful and it is why there is an ignore function on most forums.

In the how to get help thread it tells you how to go about finding and uploading files in order to receive any help. I don't recall it saying "You must file a bug report or no one will help you."

My issues are not being caused by the mods as both are present without them, you would know that if you actually took the time to read my posts instead of jumping on the fanboy wagon to defend the devs and your forum buddies.

Lastly as I told your buddy, why have a modded technical support if this is a burden and an insult to the devs?

Wow two ignores in a day! To think all I had to do was ask for assistance. What a crew...

[Lisias]

2 hours ago, JoE Smash said:

 why have a modded technical support 

Because there're people in need of such support.

Squad is responsible only for the Stock game. It's what they sold you, and it's what (theoretically) was approved by their Q/A team.

Nobody in their right mind would give support for other's works. One can only support what he can control.

But yet, modded game are an important niche on the eco-system. So these specific forum was created to allow people willing to help each other to find themselves. 

 

[Superfluous J]

3 hours ago, JoE Smash said:

Well that's unfortunate....why have threads for technical support if the people who designed the game and are the most qualified to offer technical support don't do so?

Because 99% of the time the community does it for them, and the other 1% it's a bug that gets posted to their bug reports and then they (eventually, presumably) fix it. That (and the new features) is what they do and what they should do.

[Lisias]

Well… Now that the reentry-plasma appears to be calmed down, let's talk about the issue at hand.

20 hours ago, JoE Smash said:

I have been reading everything I can find about Kerbal Space Program and crashing. There are NUMEROUS threads about it over the last FOUR years, but nothing in any of the threads here, or on Steam, or various reddits have done anything to fix the problem.

There're numerous different problems that leads to a crash, and yours is only one more of them. Until now, 70% (more or less) are directly related to Unity's lack of resilience when anything, absolutely anything goes slightly different from the ideal - not to mention the performance problems.

But your crash is caused by something in the other's 30%, congrats.  

In a way or another, you are right about Squad being responsible for a answer, but are wrong about thinking they are "guilty" on the issue. They are being screwed up by a vendor. In this case, by two of them!

 

20 hours ago, JoE Smash said:

I have about 20 crash.dmp files that I have no way to open or read myself and taking the time to zip them with the Output_log, error log, and KSP log files and then uploading them to dropbox to post a link here... and then get no response from any of the Devs is obviously not worth anyone's time.

So I did my best to try to solve this on my own....

And that's is the irony of the thing: you detected and solved the problem by yourself. Really, impressive work. Kudos!

You don't have the slightest idea about the reason (I have, I will explain below), but yet you nailed it down marvelously. Really, congrats. You keep doing this, and you will have a job on any place I have some word about (assuming we could afford you!).  

 

20 hours ago, JoE Smash said:

I then did a file search for xinput1_3.dll and noticed it is located in several different places in my C drive. I also noticed that it came in different file sizes. So I Googled about it on the Internet. I learned that there is a 32bit and 64bit version of it. The 64 bit file size is about 105KB and the 32bit version is about 80KB. As you can see from my second spoiler above it is using the larger file size which makes sense because I am running the 64bit version of KSP.....I also learned that System32 is the 64bit program folder for Windows and Syswow64 is the 32bit folder.....that doesn't make sense to me and seems counter-intuitive....

Well… Welcome to Windows DLL Hell. Take a nice seat, you are staying for long.  

Originally, in the late 80's and early 90's (I know what I'm talking - been there, done that), the C:\WINDOWS\SYSTEM was the place where you put system wide DLLs. DLLs are a good thing, it's a way to share functions between clients - but as time passes, new versions with fixes for old bugs and new bugs to be fixed by new versions are created - and a bug that doesn't screws up with a new program can crash an older one (and vice versa). And Microsoft did nothing to prevent that, besides this being a well-known (and already fixed) problem on any decent Operating System of the era (yes, I'm talking about UNIX).

To make things "worse", Windows didn't tell .EXE from .DLL on a thing called "search path", that it's a mechanism to allow programs calling each other without having to know exactly where they are.  So, if you put a utility on your "search path", you also allow all its DLLs to be reached as they were a system wide one.

So, people started to have a copy of the DLL they know for sure it's working fine to them on the same directory of the program, that is the place where it's supposed to be the DLLs that were made by the program maker and is not meant to be system wide. This defeated the very purpose of using a DLL, but whatever. This is Windows, and they are the Microsoft - don't expect too much.

And then Windows 95 came, a 32 bit system build from a 16 bit infrastructure, with support for legacy Win16 programs - they need to do that, otherwise they simply would not sell. But Win16 programs can't handle [well] Win32 DLLs, and Win32 EXEs can't handle [well] Win16 DLLs. Worse, MS also had the brilliant idea of allowing system data and configuration to be stored on C:\WINDOWS\SYSTEM , messing everything. What they could do at the time to cope with their own mess is to create the C:\WINDOWS\SYSTEM32 directory, and store there the DLLs for Win32, and leaving the Win16 DLLs on the C:\WINDOWS\SYSTEM. And everybody continued to look for configurations and data on C:\WINDOWS\SYSTEM.

If a Win16 program is started, the kernel would put C:\WINDOWS\SYSTEM on the end of its Search Path. If the program was a Win32 one, Windows puts C:\WINDOWS\SYSTEM32 in the front of the C:\WINDOWS\SYSTEM - so, yeah - if a Win32 program starts and invokes an DLL those 32 bits was not installed, then the 16 bits one will be provided. And yeah. **BOOM**.

Looks familiar?  

 

20 hours ago, JoE Smash said:

I also learned that System32 is the 64bit program folder for Windows and Syswow64 is the 32bit folder.....that doesn't make sense to me and seems counter-intuitive....

Yes. When Win64 arrived, nobody had to deal with Win16 anymore, but all that code was still there being compiled in 32 bits. Worse, people didn't had learnt anything from the past, and the new programs were hardcoded into the c:\Windows\System32 (we finally had lower/upper case support and long filenames as default! hurray!  ). 

So, using c:\Windows\System64 for the new 64 bits DLL would need to revise and recode everything. So... The damned stand-up guys just recompiled everything in 64 bits and put them all on the System32 and that's it. Since Win32 support would be kind of a sandbox (a "light container" would be a better definition) and so, having differentiated handling, they could be in anywhere else. So they had the "brilliant" (please note the quotes) idea of naming this place "System for Windows 32 on Windows 64", or SysWoW64.  

Oh, yes. Do you remember that "Search Path" thingy? They are still there. But now, in three different ways to screw you up! Four, to tell you the true, because they cooked up a way to allow Win64 EXEs to call Win32 DLLs.  It works some times.  

 

20 hours ago, JoE Smash said:

What also doesn't make sense to me after doing my file search for that file, is WHY Kerbal Space program comes with two copies of it, one in KSP_Data\Plugins and one in KSP_x64_Data\Plugins and when I run the game with the KSP_x64 shortcut on my desktop it uses NEITHER of them? If you look at what is says in the error above it is using MY Windows copy of it in C:\WINDOWS\SYSTEM32\xinput1_3.dll. Why is it using the one in my windows folder when the game comes with it's own two copies?

At this point, you already know the reason. There're a DLL for each directory in which there're an EXE that needs it, to prevent exactly the problem that is bitting you in the SAS.

However, and this is the inherent problem, some dumb-SAS mangled with the Search Path. I don't know if it's something that was done on your machine by some utility/program/whatever, or if it's something that someone on Microsoft implemented on the new Windows versions. In a way or another, this stand-up guy screwed up royally the way programs load their DLLs. Now, you are being forced to use the System Wide DLL, and not the one the program vendor (Squad, in this case) intended.

 

20 hours ago, JoE Smash said:

So I tried something crazy. I went in my windows\system32 folder and renamed the xinput1_3.dll there xinput1_3_fail.dll, and then I copied and pasted a copy of the file from the KSP_x64_data\Plugin folder into my windows\system32 folder.....which is something REALLY stupid to do, and I REALLY need to remember I did that, because it will probably break every other 64bit game I try play.

So far my game hasn't crashed once and I intentionally went in and out of the VAB and SPH buildings like 20 times each and launched and reverted flights like 20 times.....something I could normally get away with like 4 times and the game still hasn't crashed. So now the 64bit version of the game is most likely utilizing a 32bit dll located my 64bit Windows folder....

As I said before, welcome to DLL Hell:

Spoiler

And… Yeah, the newest approach from the Microsoft "Gurus" for this problem is a thingy called WinSXS - Windows Side By Side. This is another excrescence they had to do to make things work for while. Every installed program (using the Windows Installer subsystem) owns a copy of the current System Wide DLLs it uses there. So if the System Wide DLL changes, that program would still use the one it knows about.

Now try to realize every single program you installed on your system having its own private copy of the DLLs. Yes, the WinSXS directory grows up until it's some times bigger than the original Windows Installation.

SSD users really appreciate it (not!). Nowadays, 320GB SSDs are not enough due exactly this thing.

 

20 hours ago, JoE Smash said:

Hope this helps someone else suffering from frequent crashing......!

Dude, it did. You really could had nailed down a reason for the Win64 instability.

Now we need to check if what I said before about the "Search Path mangling" is valid for everybody else or just for you.

This is something that the Dev Team should be aware too. @Vanamonde what you suggest? I don't know for sure if this is a bug, so I don't know if a ticket should be opened on the bug track.

Edited July 29, 2018 by Lisias
misquoted the guy. fixed. also I misremember a thing about DLL. fixed too.

[Vanamonde]

I'm a forum guy but not a tech support guy. If it's reproducible, then I'd say file a bug report. Other than that, I got nothin'.

[JoE Smash]

20 hours ago, Lisias said:

Well… Now that the reentry-plasma appears to be calmed down, let's talk about the issue at hand.

There're numerous different problems that leads to a crash, and yours is only one more of them. Until now, 70% (more or less) are directly related to Unity's lack of resilience when anything, absolutely anything goes slightly different from the ideal - not to mention the performance problems.

But your crash is caused by something in the other's 30%, congrats.  

In a way or another, you are right about Squad being responsible for a answer, but are wrong about thinking they are "guilty" on the issue. They are being screwed up by a vendor. In this case, by two of them!

 

And that's is the irony of the thing: you detected and solved the problem by yourself. Really, impressive work. Kudos!

You don't have the slightest idea about the reason (I have, I will explain below), but yet you nailed it down marvelously. Really, congrats. You keep doing this, and you will have a job on any place I have some word about (assuming we could afford you!).  

 

Well… Welcome to Windows DLL Hell. Take a nice seat, you are staying for long.  

Originally, in the late 80's and early 90's (I know what I'm talking - been there, done that), the C:\WINDOWS\SYSTEM was the place where you put system wide DLLs. DLLs are a good thing, it's a way to share functions between clients - but as time passes, new versions with fixes for old bugs and new bugs to be fixed by new versions are created - and a bug that doesn't screws up with a new program can crash an older one (and vice versa). And Microsoft did nothing to prevent that, besides this being a well-known (and already fixed) problem on any decent Operating System of the era (yes, I'm talking about UNIX).

To make things "worse", Windows didn't tell .EXE from .DLL on a thing called "search path", that it's a mechanism to allow programs calling each other without having to know exactly where they are.  So, if you put a utility on your "search path", you also allow all its DLLs to be reached as they were a system wide one.

So, people started to have a copy of the DLL they know for sure it's working fine to them on the same directory of the program, that is the place where it's supposed to be the DLLs that were made by the program maker and is not meant to be system wide. This defeated the very purpose of using a DLL, but whatever. This is Windows, and they are the Microsoft - don't expect too much.

And then Windows 95 came, a 32 bit system build from a 16 bit infrastructure, with support for legacy Win16 programs - they need to do that, otherwise they simply would not sell. But Win16 programs can't handle [well] Win32 DLLs, and Win32 EXEs can't handle [well] Win16 DLLs. Worse, MS also had the brilliant idea of allowing system data and configuration to be stored on C:\WINDOWS\SYSTEM , messing everything. What they could do at the time to cope with their own mess is to create the C:\WINDOWS\SYSTEM32 directory, and store there the DLLs for Win32, and leaving the Win16 DLLs on the C:\WINDOWS\SYSTEM. And everybody continued to look for configurations and data on C:\WINDOWS\SYSTEM.

If a Win16 program is started, the kernel would put C:\WINDOWS\SYSTEM on the end of its Search Path. If the program was a Win32 one, Windows puts C:\WINDOWS\SYSTEM32 in the front of the C:\WINDOWS\SYSTEM - so, yeah - if a Win32 program starts and invokes an DLL those 32 bits was not installed, then the 16 bits one will be provided. And yeah. **BOOM**.

Looks familiar?  

 

Yes. When Win64 arrived, nobody had to deal with Win16 anymore, but all that code was still there being compiled in 32 bits. Worse, people didn't had learnt anything from the past, and the new programs were hardcoded into the c:\Windows\System32 (we finally had lower/upper case support and long filenames as default! hurray!  ). 

So, using c:\Windows\System64 for the new 64 bits DLL would need to revise and recode everything. So... The damned stand-up guys just recompiled everything in 64 bits and put them all on the System32 and that's it. Since Win32 support would be kind of a sandbox (a "light container" would be a better definition) and so, having differentiated handling, they could be in anywhere else. So they had the "brilliant" (please note the quotes) idea of naming this place "System for Windows 32 on Windows 64", or SysWoW64.  

Oh, yes. Do you remember that "Search Path" thingy? They are still there. But now, in three different ways to screw you up! Four, to tell you the true, because they cooked up a way to allow Win64 EXEs to call Win32 DLLs.  It works some times.  

 

At this point, you already know the reason. There're a DLL for each directory in which there're an EXE that needs it, to prevent exactly the problem that is bitting you in the SAS.

However, and this is the inherent problem, some dumb-SAS mangled with the Search Path. I don't know if it's something that was done on your machine by some utility/program/whatever, or if it's something that someone on Microsoft implemented on the new Windows versions. In a way or another, this stand-up guy screwed up royally the way programs load their DLLs. Now, you are being forced to use the System Wide DLL, and not the one the program vendor (Squad, in this case) intended.

 

As I said before, welcome to DLL Hell:

  Reveal hidden contents

And… Yeah, the newest approach from the Microsoft "Gurus" for this problem is a thingy called WinSXS - Windows Side By Side. This is another excrescence they had to do to make things work for while. Every installed program (using the Windows Installer subsystem) owns a copy of the current System Wide DLLs it uses there. So if the System Wide DLL changes, that program would still use the one it knows about.

Now try to realize every single program you installed on your system having its own private copy of the DLLs. Yes, the WinSXS directory grows up until it's some times bigger than the original Windows Installation.

SSD users really appreciate it (not!). Nowadays, 320GB SSDs are not enough due exactly this thing.

 

Dude, it did. You really could had nailed down a reason for the Win64 instability.

Now we need to check if what I said before about the "Search Path mangling" is valid for everybody else or just for you.

This is something that the Dev Team should be aware too. @Vanamonde what you suggest? I don't know for sure if this is a bug, so I don't know if a ticket should be opened on the bug track.

Thank you for your reply, @Lisias, I very much appreciate being thanked in some way for something instead of being argued with over every piece of a statement I am attempting to make. 

I wasn't trying to attack Squad or the game(although it clearly seems like I was by several of my argumentative statements). I obviously like the game, or I wouldn't have still been trying to play it and get it to work properly. Due to this issue my game was crashing to desktop after about every 4 or 5 times I was reverting a flight and trying to go back into the VAB to tweak the ship to improve what I was attempting to do in the first place....

Try to imagine just for a moment what it is like to experience that situation. I understand it is difficult to view an experience from someone else's perspective, and I am guilty at sucking at this occasionally myself. 

So I am new to the game even though it's been available for quite a few years at this point. I have only been playing around a month so far. I don't know very much about rocket science, or designing air craft,  so all of this was a pretty big learning curve for me....as it most likely is for a majority of people playing this game. I feel many people probably find this game fairly difficult to master. That's one of the things that appeals to me. I have a Biochemistry degree in real life, so I like to believe I am somewhat intelligent. I'm no rocket scientist....but I AM a scientist of some sort, so I figure if I apply myself I will succeed in a difficult game based on scientific principles....

So I'm trying to learn the game and progress and BAM....every 5-10 minutes of tinkering with my next ship for my next contract I'm looking at my desktop. Then factor in I run about 100 mods from CKAN, so my game LITERALLY takes 5-10 minutes to load up again....So I was spending pretty much as much time watching the loading screen of the game as I was flying rockets and planes. Obviously that's no fun, and I was pulling my hair out, grinding my teeth, and probably giving myself cancer....or at least an ulcer.

I had already tried TWICE at this point slowly removing all 100 of my mods 5-10 at a time, because of course WHENEVER you ask anyone in any forum thread for help with this game.... and you get to the part where you tell them you run about 100 mods, the easy answer is to blame it on one of the mods, or my ability to install them properly....

After uninstalling all my mods, on both occasisions I also uninstalled the game completely from Steam and then deleted everything left behind as well. The second time I did this I decided my save MUST be corrupted or something because NOTHING I did would fix this crashing issue or my sorting parts by mass issue, and I felt I pretty much tried EVERYTHING I could think of trying. So that means I ALSO got to start my career over from scratch (I only play career mode), and I had already unlocked the first 6 tiers of the tech tree at that point.

I tried cleaning my registry, I tested my RAM with Memtest86, I tried some driver programs that scan all your installed drivers and recommed updates for ANY drivers that are not up to date. I ALMOST bought 16GB of new RAM for $105 from Newegg because linuxgurugamer suggested my RAM might be bad. The only thing I had left to try at this point (in my opinion), was learn a programming language and rewrite the game myself, or buy a new computer....or I guess I could have just given up trying to play this and just play something else.....I'm VERY stubborn though, and I have never considered myself a quitter....

So obviously all of above had already wasted A LOT of my time at this point, and I was in a pretty sour mood to begin with. Despite this my first impulse was to SHARE what I discovered with the modded technical support forum just on the off chance I could help ONE person, and prevent them from grinding their teeth, ripping their hair out, and getting an ulcer....because their game is crashing more than they are playing it.

I didn't come here to get in an argument about who's fault this is, or what exactly the minimum recommended specs for the game are, or whether or not DirectX is required to play it.

I'm a scientist....I make observations, collect data, and share results. That's the one thing I am good at. That was all I was trying to do here. I just wanted my damn game to work so I could frigging play it.

After two days ago I honestly had no plans of returning to this thread again based on the initial response from the first two KSP fanboys. Their response is the typical and expected response when you post anything contrary about anything on any forum. It is why I tend to not participate in forum communities in general. Frankly it's too aggravating and not worth my time.

The only reason I came back to respond to you, is because I was talking to Linuxgurugamer about my findings in his mod thread for using an Xbox controller, "Advanced flybywire," and after I posted to him he linked your post to me. 

So I came to thank you for your response!

Thank you!

Based on your first sentence I have no plans to read any posts above yours, because I'm sure I'll just get annoyed and block more daft people that have no business talking to me about anything anyway.

So if any devs wish to speak to me, or any gamers wish to thank me because I actually helped them in some way, by figuring out an issue that was impacting them, they can feel free to mail me through the forum. 

If anyone wants to quote this post line by line and refute every sentence I just typed, how about you just keep your opinion to yourself, or argue with someone other than me?

I honestly don't have the time or patience for you, I'd rather be adding to my first space station that I just placed 110KM over Kerbin, than agruing with you over DirectX files.

Thanks anyways!

Edited July 30, 2018 by JoE Smash
NEED MOAR COMMAS!

[JoE Smash]

20 hours ago, Lisias said:

 

At this point, you already know the reason. There're a DLL for each directory in which there're an EXE that needs it, to prevent exactly the problem that is bitting you in the SAS.

 

@Lisias I just re-read this statement and realized why exactly Linuxgurugamer may have linked this post to me. As I stated I am no programmer, and as such I didn't fully understand the relationship between dll files and exe files.....So instead of copying the 32bit xinput1_3.dll to my system32 folder, would KSP_64.exe utilize the one installed with the game in the plugin folder, if I instead copied it into the main folder containing the exe? That's where the the dll files included with Linuxgurugamer's advanced flybywire mod end up....

Basically where do you think the xinput1_3.dll file should go so KSP_x64.exe utilizes the 32bit one that comes with the game instead of trying to default to the 64bit one in my Windows folder....

Or maybe I should copy the 64bit windows xinput1_3.dll into the 64bit KSP_x64_Data\plugins folder?

Is this because the 64bit KSP data\plugin folder has a 32bit file that doesn't match the 64bit Windows file?

Basically is there a more intelligent way to remedy this situation other than the fix I did?

Edited July 30, 2018 by JoE Smash

[Lisias]

13 hours ago, JoE Smash said:

Thank you for your reply, @Lisias, I very much appreciate being thanked in some way for something instead of being argued with over every piece of a statement I am attempting to make. 

I wasn't trying to attack Squad or the game(although it clearly seems like I was by several of my argumentative statements). I obviously like the game, or I wouldn't have still been trying to play it and get it to work properly. Due to this issue my game was crashing to desktop after about every 4 or 5 times I was reverting a flight and trying to go back into the VAB to tweak the ship to improve what I was attempting to do in the first place....

Try to imagine just for a moment what it is like to experience that situation. I understand it is difficult to view an experience from someone else's perspective, and I am guilty at sucking at this occasionally myself. 

Been there, done that. I once read on this forum (I think it was on one of the Announces for a new 1.4 version) from a fellow kerbonaut: "It's infuriating".

I bought TWO copies of this game, one for me and one for my son. Some time ago I asked him about the game, and he answered that the game should be nice as he saw me playing it a lot, but he preferred to play Elite Dangerous instead. He wants to enjoy himself, and the way I used to curse while I was playing didn't sounded like enjoyment to him. That made me contemplative for some hours.

I tried to figure out the situation: if I was cursing that much, but yet I still insisted on playing the game, something had to change. So I remembered that I am a software developer myself and remembered the classes about Software Engineering and User Expectation Management (not sure if I translated correctly), and realized that I was cursing because I was feeling impotent.

Things got better since then - if something is wrong, I just work to fix or workaround it, so I can go back to play. I don't care about who was expected to fix what , if I can I fix it, if I can't I workaround it. 

My son said that the cursing almost stopped.  

 

13 hours ago, JoE Smash said:

So I am new to the game even though it's been available for quite a few years at this point. I have only been playing around a month so far. I don't know very much about rocket science, or designing air craft,  so all of this was a pretty big learning curve for me....as it most likely is for a majority of people playing this game. I feel many people probably find this game fairly difficult to master. That's one of the things that appeals to me. I have a Biochemistry degree in real life, so I like to believe I am somewhat intelligent. I'm no rocket scientist....but I AM a scientist of some sort, so I figure if I apply myself I will succeed in a difficult game based on scientific principles....

KSP is related to Real Rocketry as much as Test Drive is related to Real Racing.  It's a complex game, but yet, it's a game.

Some real life concepts applies, but not all. And some ones were way simplified to make things bearable. Some of my funnier mishaps happened when I tried to use "real life engineering" and the damned thing exploded under my nose.  

Play KSP as you were a kid: don't bring the RL knowledge to game. Use the game to find out what RL knowledge you need to bring to the game. Of course, this is just what works for me (I was a Carmen Sandiego addict when a kid, I used to play with Barsa on my side!), your mileage may vary.

 

13 hours ago, JoE Smash said:

[snip]

I had already tried TWICE at this point slowly removing all 100 of my mods 5-10 at a time, because of course WHENEVER you ask anyone in any forum thread for help with this game.... and you get to the part where you tell them you run about 100 mods, the easy answer is to blame it on one of the mods, or my ability to install them properly....

[snip] 

I'm VERY stubborn though, and I have never considered myself a quitter....

Been there, did that.  The more time one "invest" on the game, more angry one gets when the "investment" fails. It's exactly like this everywhere.

Be careful with your stubbornness. This will lead you to become a Software Developer if you don't take adequate precautions.  

 

13 hours ago, JoE Smash said:

I'm a scientist....I make observations, collect data, and share results. That's the one thing I am good at. That was all I was trying to do here. I just wanted my damn game to work so I could frigging play it.

That explains the marvelous investigative work. We need exactly this kind of approach on the industry. But I'm digressing...

 

13 hours ago, JoE Smash said:

After two days ago I honestly had no plans of returning to this thread again based on the initial response from the first two KSP fanboys. Their response is the typical and expected response when you post anything contrary about anything on any forum. It is why I tend to not participate in forum communities in general. Frankly it's too aggravating and not worth my time.

There's this fantastic cartoon from the early 90's:

Spoiler

There're kids around here. There're youngsters. And some old guys like me that never grows up.  Give them some slack, I surely needed that when I was a fanboy doing some mess on forums (boy, I was chewed a lot!  ).

But there're also some people that, frankly, you don't have to cope with. Put them on the "Ignore User List" and that's it - I put two in my very first post on this forum, 5 minutes after creating my account and I don't regret it for a second. They can be the best of the persons for someone else, and that's ok. But I didn't came here to be angry with people, so…  

Edited July 31, 2018 by Lisias
some mishaps on english phrasing

[Lisias]

8 hours ago, JoE Smash said:

So if any devs wish to speak to me, or any gamers wish to thank me because I actually helped them in some way, by figuring out an issue that was impacting them, they can feel free to mail me through the forum. 

Open a ticket for this problem, with a small abstract and link to this forum where the hot information is.

https://bugs.kerbalspaceprogram.com

I think you are the one that should do it, as you are the guy with the evidences. The devs need to test my hypothesis before investing resources on a fix (I can be wrong on the conclusion, besides the historical knowledge corroborates my hypothesis), and it's your machine that can provide the needed information.

[Lisias]

8 hours ago, JoE Smash said:

@Lisias I just re-read this statement and realized why exactly Linuxgurugamer may have linked this post to me. As I stated I am no programmer, and as such I didn't fully understand the relationship between dll files and exe files.....

It's about 4 years since I installed my last Windows machine for professional work, and since then, I only installed another one last month for a job (B.S., I installed Windows on my workstation to play games on a nice machine!  ). And both are Windows 7.

So, I don't have the slightest idea if anything really changed on Windows 10 and screwed up everything and everybody, or this is something that somebody else is doing on some systems, so I don't know exactly why this is happening with you. We need broader arms now, and Squad have the resources to check it out.

KSP uses as a 3D Engine a thing called Unity, and this engine handles all the weight lifting when handling hardware - from the GPU to the HMI (Human Machine Interface) devices (joysticks, mouses and keyboards for the common people), so we have yet another variable on this mess. Unity.

This time Unity appears to be innocent, besides this weird stunt of using what appears to be a 32 Bits DLL for input. Did you check if the DLL is 32 Bits by Right Clicking on it and selecting Properties? Just to avoid misunderstandings.

 

8 hours ago, JoE Smash said:

So instead of copying the 32bit xinput1_3.dll to my system32 folder, would KSP_64.exe utilize the one installed with the game in the plugin folder, if I instead copied it into the main folder containing the exe? That's where the the dll files included with Linuxgurugamer's advanced flybywire mod end up....

Basically where do you think the xinput1_3.dll file should go so KSP_x64.exe utilizes the 32bit one that comes with the game instead of trying to default to the 64bit one in my Windows folder....

Or maybe I should copy the 64bit windows xinput1_3.dll into the 64bit KSP_x64_Data\plugins folder?

Is this because the 64bit KSP data\plugin folder has a 32bit file that doesn't match the 64bit Windows file?

Basically is there a more intelligent way to remedy this situation other than the fix I did?

Ideally, this should not be happening. So there's no "more intelligent way" to solve this. What we can pursue by ourselves is the less ugly hack possible.

Copying the working xinput to the very same directory where the KSP_64.exe is should do the trick, but by doing this, you are "mangling" with the KSP installment, what technically void your warranty.  And also can cause something else to blow up, because we don't know who else on that directory would need the "other' xinput by some reason (if any).

However, yes, copying the working xinput.dll to match KSP_64.exe location is the "less dumb" solution for now, if it works. This is Windows, there's no intelligence available here.

Edited July 31, 2018 by Lisias
Damn! I'm unable to post without errors! =P

[JoE Smash]

1 hour ago, Lisias said:

It's about 4 years since I installed my last Windows machine for professional work, and since then, I only installed another one last month for a job (B.S., I installed Windows on my workstation to play games on a nice machine!  ). And both are Windows 7.

So, I don't have the slightest idea if anything really changed on Windows 10 and screwed up everything and everybody, or this is something that somebody else is doing on some systems, so I don't know exactly why this is happening with you. We need broader arms now, and Squad have the resources to check it out.

KSP uses as a 3D Engine a thing called Unity, and this engine handles all the weight lifting when handling hardware - from the GPU to the HMI (Human Machine Interface) devices (joysticks, mouses and keyboards for the common people), so we have yet another variable on this mess. Unity.

This time Unity appears to be innocent, besides this weird stunt of using what appears to be a 32 Bits DLL for input. Did you check if the DLL is 32 Bits by Right Clicking on it and selecting Properties? Just to avoid misunderstandings.

 

Ideally, this should not be happening. So there's no "more intelligent way" to solve this. What we can pursue by ourselves is the less ugly hack possible.

Copying the working xinput to the very same directory where the KSP_64.exe is should do the trick, but by doing this, you are "mangling" with the KSP installment, what technically void your warranty.  And also can cause something else to blow up, because we don't know who else on that directory would need the "other' xinput by some reason (if any).

However, yes, copying the working xinput.dll to match KSP_64.exe location is the "less dumb" solution for now, if it works. This is Windows, there's no intelligence available here.

Ok, I'll try switching my system32 folder back to the way it was and try moving the file in plugins folder back two steps to the main KSP folder where the actual exe is and see if my stability stays, or if I go back to crashes with xinput1_3.dll involved in my system32 folder, or doing this generates a completely new error I haven't experienced yet.

I'll also Googled how to check if a paticular dll is actually 32bit or 64 bit. It doesn't actually seem to say under properties. I assumed it was 32bit purely by going on a dll download site and seeing the correct sizes of xinput1_3.dll for two different versions of directx. Both the 32bit versions the older and the newer were right around 80KB just like BOTH copies in both KSP data\plugins folder. The two versions of the 64bit dll were larger than that.

Typically you need a special program to open a dll so you can actually see what it says in the header at the top if it points to a 64bit or x64 header, or a 32bit or x86 header. After digging for a while I found a handy shortcut....since I don't think I posess any software that lets me correctly view the contents of a dll. Someone said even though dlls look like gobbledy gook in Notepad if it says PE followed by L it is x86 or 32 bit and if it says PE followed by d+ (not really a plus sign, it looks more like a crucifix) then it is x64. Sure enough the xinput1_3.dll file in the KSP_64_Data\plugins folder starts with PE then L....so it probably REALLY is a 32bit dll in one of the game's 64bit folders. The four other dlls in that folder all have PE d+ somewhere near the beginning....as they probably should.  All 5 of the dlls in the x86 data\plugins folder all start with PE then L as x86 files should...

So in my non-expert opinion as non-programmer it does indeed seem that KSP has TWO copies of a 32 bit version of xinput1_3.dll installed with it and and at least one of them should probably be 64 bit.....maybe I should try replacing the one in the x86_data/plugins folder with the 64bit one from my system32 folder? All the other dlls in there are 64 bit....maybe that's all that is actually wrong? I might try that first actually....

I'm actually somewhat familiar with Unity....I mean I don't know how to program it or anything, but I am aware of it's existence. A lot of independent development studios seem to use it. Including the makers of my current favorite survival game, The Long Dark....on Steam. I was playing that game for months before trying this out.

As far as being a game and not based on real rocket science...I mean before playing this I didn't know anything about centers of lift and centers of mass or what an apoapsis or periapsis is....so there is some physics involved. It may not be a realistic as real life, but some fundamentals are there. Allegedly Elon Musk likes the game...lol.

I considered writing a bug report today, and started with reading the bug reporting forum. Several of the things they would like, I don't have. I don't have screenshots or videos, and I have never used the debug window....so I don't have any of that from my crashes. After reading a bunch of the bug reports it appears no one follows their many requests when reporting bugs anyways. 

The very first thing it says to do is a search to see if your bug has already been reported. In my opinion it has. At least one or two people already have open reports about frequent crashing when leaving or reverting to the VAB. One guy from three months ago supplied an error log with just TWO modules in it just like mine. One for xinput1_3.dll in his system32 folder and the other being steam_api64.dll in the KSP folder. When I force DX11 instead of OpenGL that's typically all I have in my error report too. So I tacked notes onto those bug reports about trying out my potential fix to see if it helps with their stability.....

[Lisias]

3 hours ago, JoE Smash said:

So in my non-expert opinion as non-programmer it does indeed seem that KSP has TWO copies of a 32 bit version of xinput1_3.dll installed with it and and at least one of them should probably be 64 bit.....maybe I should try replacing the one in the x86_data/plugins folder with the 64bit one from my system32 folder? All the other dlls in there are 64 bit....maybe that's all that is actually wrong? I might try that first actually....

Sometimes, we software developers just do what we are told to do. And then the time passes and the reason for what we were told to do something is not valid anymore, but nobody tell us to stop doing that, and so we keep doing it. I'm wondering is this is not the case: somebody, somewhere, fixed something by doing this, and nobody remembered to tell him to stop doing it once it was not needed anymore.

And yeah, I think your line of action is the more sensible one at the moment.

I'm somewhat lost about what DLL is good and what is not - I somehow was convinced that the KSP's xinput was the good one, and you had to copy it to system32 to make it work. Reading now, it appears to be the opposite way. o.O

Nevertheless, copying the "good" dll into the same place where the .EXE are should fix the problem (if it will create any more, we will see).

 

3 hours ago, JoE Smash said:

I'm actually somewhat familiar with Unity....I mean I don't know how to program it or anything, but I am aware of it's existence. A lot of independent development studios seem to use it. Including the makers of my current favorite survival game, The Long Dark....on Steam. I was playing that game for months before trying this out.

KSP exhausted by a mile Unity's maturity and capabilities. The usual Unity's client has a product life cycle based on a Project - you start it, you work on it, you finish it, you kick the product thought the door then close the shop and that's it.

KSP is a Program (in the sense of a Space Program!), a long term commitment formed by a series of specific short term goals. Exactly like a Space Program.

Unity doesn't copes well with this model. They don't expend enough resources on long term support and compatibility as new versions of the Engine is sent to the streets.

Try to imagine every single computer of the Apollo Program needing to be reprogramed, retested and redebuged every 6 months due a change on some vendor's math library (they can just switch from imperial to metric system on the next version!). Yeah, this is what's happening with KSP.

 

3 hours ago, JoE Smash said:

As far as being a game and not based on real rocket science...I mean before playing this I didn't know anything about centers of lift and centers of mass or what an apoapsis or periapsis is....so there is some physics involved. It may not be a realistic as real life, but some fundamentals are there. Allegedly Elon Musk likes the game...lol.

That's the catch: I took some private pilot lessons as younger. I even learnt some commercial pilot lessons (I can read and understand the flight manual for a old Boeing 737, and perhaps a 747 - Airbus is over my head, new aircrafts are totally different nowadays). And this was the reason my first airplanes had a weird tendency to hug the grass.  

There're some glitches on the model they adopt for the lifting forces that doesn't match exactly a real airplane - what's perfectly fine, they had to shove that math on a consumer grade consumer from the last decade - but this smart-sas here wanna to play engineering and, obviously, failed.  You need to see my face when one of the guys here explained how things work on the game. A kid would already figured out what to do, because he/she would try to understand the problem at hand. I spent months trying to shove what I knew about into the game, ignoring the evidences that the game were providing me.  I feel stupid every time I open that save game.  

And Ellon is crazy. BFR style crazy.

Edited July 31, 2018 by Lisias
oh yeah. typos. =/

[JAFO]

On 7/30/2018 at 5:09 AM, Lisias said:

Well… Welcome to Windows DLL Hell. Take a nice seat, you are staying for long.  

Thanks for a most succinct and informative explanation.. I'm saving that one for future reference!

 

4 hours ago, Lisias said:

This is Windows, there's no intelligence available here.

I am SO tempted to use that for a sig!

 

29 minutes ago, Lisias said:

Sometimes, we software developers just do what we are told to do. And then the time passes and the reason for what we were told to do something is not valid anymore, but nobody tell us to stop doing that, and so we keep doing it. I'm wondering is this is not the case: somebody, somewhere, fixed something bydoing this, and nobody remembered to tell him to stop doing it once it was not needed anymore.

And yeah, I think your line of action is the more sensible one until the moment.

I'm somewhat lost about what DLL is good and what is not - I somehow was convinced that the KSP's xinput was the good one, and you had to copy it to system32 to make it work. Reading now, it appears to be the opposite way. o.O

Nevertheless, copying the "good" dll into the same place where the .EXE are should fix the problem (if ti will create any more, we will see).

It gets even more interesting.. see this post of mine on the subject.. Essentially, we seem to have a case of a 64bit program, calling a 32bit dll, which itself makes calls to 64bit dll's, and it works better than Micro$oft's own 64bit dll. Go figure.

[Lisias]

9 minutes ago, JAFO said:

It gets even more interesting.. see this post of mine on the subject.. Essentially, we seem to have a case of a 64bit program, calling a 32bit dll, which itself makes calls to 64bit dll's, and it works better than Micro$oft's own 64bit dll. Go figure.

Check if this DLL was compiled in Debug Mode. It was (are?) usual practice to ship binaries linked against the debug libraries from Microsoft because this library can be "tricked" into absorbing exceptions instead to throwing them up to the caller. It's the earliest form of empty "try catch" I'm aware.

This would explain some performance and functional glitches. A function with a masked Null Pointer Exception would return a random value (whatever on the returning register/memory address at the moment), not to mention the time spend on the exception handling,

[JAFO]

3 minutes ago, Lisias said:

Check if this DLL was compiled in Debug Mode. It was (are?) usual practice to ship binaries linked against the debug libraries from Microsoft because this library can be "tricked" into absorbing exceptions instead to throwing them up to the caller. It's the earliest form of empty "try catch" I'm aware.

This would explain some performance and functional glitches. A function with a masked Null Pointer Exception would return a random value (whatever on the returning register/memory address at the moment), not to mention the time spend on the exception handling,

<Sigh> The more I learn about Windows, the more I like Linux. If anyone ever invents a time machine, I hope they go back and erase Bill Gates from history before he ever started his damned company.

[JoE Smash]

Ok @Lisias and @JAFO,

I don't want to jump the gun because I don't feel I have done enough exhaustive testing to feel positive, because I myself got exhausted and needed a nap....That being said, putting the 64bit xinput1_3.dll from my Windows\system32 folder into the KSP_x64_data\plugins folder seems to be equally stable as doing the reverse of this...I think.

I didn't get to play as much as I would have liked, or reverted as many flights as I would have liked, but I messed around quite a bit and I didn't crash to desktop.....In my opinion I did do at least three times as many things that would normally have resulted in a crash by now, so that will have to be good enough for now.

I don't feel this is a matter of one dll or another being "bad" or "corrupted" or containing bad code, I think the 32bit xinput1_3.dll being in the KSP x64 data plugins folder was just WRONG. Just wrong in the general way that 32bit and 64bit programs don't play well with each other, or with a 64bit OS that doesn't match in general.

I tried out that Dependancy Walker program you mentioned, and while I don't fully understand what all those errors mean, one thing is clear....On my 64bit OS obviously any 64bit dll I check has FAR less red and errors going on than any 32bit dll I look at.

I tried opening all the dlls that are in both data plugin folders that install with KSP, and there is far less things "wrong" with the stuff in the game's 64bit plugin folder....which is obvious and makes sense. With the one exception of that 32bit xinput1_3.dll file. Once I copied the 64bit copy there from my Windows system32 folder they all more or less match now as far as error messages with that program.

I believe this may work just as well as messing around in my Windows folder, which I didn't feel good about in the first place to be honest....

So this crash and error I have been dealing with for the last month is probably simply due to what you basically explained about the file path and dlls. I'm running a 64bit OS and trying to run a 64bit version of a game on it, which is normally a fine idea, but while playing the game it is trying to use xinput1_3 periodically and the copy it is told to go to is wrong....so it then goes and looks for the "system wide one" in my system32 folder....and BOOM. CTD. Maybe it's because the other 4 dlls in the plugin folder are not also system wide dll files....I don't know. I also ran a file search for some of those dll files and the only two copies I have are the two installed with the game. So I don't believe there is a system wide version of the other four dlls that are in the game's data plugin folder that are ALSO in my system32 folder.....and I'm not about to start throwing random junk into my windows folder, lol. I was only willing to mess with renaming the xinput1_3.dll because technically it was already in there to begin with...

Anyhoo. Like I said there are open bug reports about CTDs while changing scenes from flying back to the VAB/SPH, and at least one guy was throwing errors involving only two modules like I was: xinput1_3.dll and steam_api64.dll, so I added notes to those. I'll try to remember to go back and revise them about doing the reverse solution once I am more sure it is definitely a solution....

Once my game is definitely stable I probably will go back to trying to break it again....lol. Meaning I uninstalled mods that I would like to use, but I uninstalled them because I thought I was using too much RAM or something and this was crashing my game. Now that I see it most likely had nothing to do with too many mods I can add more, lol!

[Lisias]

10 hours ago, JAFO said:

<Sigh> The more I learn about Windows, the more I like Linux. If anyone ever invents a time machine, I hope they go back and erase Bill Gates from history before he ever started his damned company.

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

[Lisias]

8 hours ago, JoE Smash said:

Once my game is definitely stable I probably will go back to trying to break it again....lol. Meaning I uninstalled mods that I would like to use, but I uninstalled them because I thought I was using too much RAM or something and this was crashing my game. Now that I see it most likely had nothing to do with too many mods I can add more, lol!

"RAM is overrated".  

I have a rig with 48G of RAM (a professional Workstation with a dual boot for gaming!  - don't tell my employers!), and I can't shove everything I want into GameData neither.

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

Besides, every single mod you instal on the game also eats their share on the CPU's cake, and since every part alive on the game it's a discrete entity in need to be individually simulated, the after math is that you run out of CPU way sooner you run out of memory in rigs with more than 16G RAM.