leak91

MSVCR80.dll Error

Recommended Posts

I have FSX:SE, so I can't really uninstall acceleration.. any solution for that? Cause I keep reinstalling visual 2005 (due to msvcr80) and it keeps messing up... the add-on that causes the crashes is always a weather add-on (I use FSXWX, but ASN did this too). I know I can just turn off the add-on but there has to be another way? A way to fix msvcr80? I mean do I happen to be doomed and not be able to use weather add-ons when everybody else can?! So unfair!! 

Ok coming back to a more serious attitude (even though at this point I am as frustrated as a child) I managed to calm the crashes down for a while. I had them sometimes, but much more seldomly. Now I installed fsx:se on my new computer, have done exactly what I did with the last one, and even though I manage to get less CTD it's still sort of a 50/50 gamble, and it's almost always msvcr80.. I uninstall and reinstall ++2005 sp1, and even run the cmd that detects corrupted files (and find none) but it seems to be a mystery...

P.D: I have followed the avsim CTD guide on this, but still...

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

2 hours ago, leak91 said:

I have followed the avsim CTD guide on this, but still...

You followed the guidance on page 31 of the guide regarding the Microsoft Visuals and using the Microsoft.net Repair Tool and uninstalling the MSVCR80 visual using the Add/Remove Program?  I doubt the problem is the Microsoft Visual C++ 2005 that is at fault in your situation if so.  For FSX-SE users, the developers, Dovetail, just installed Microsoft Visual C++2005 to maintain compatibility with legacy addons such as FSXWX.  They used another MS Visual to install FSX-SE and the reason why some say it runs better than the boxed version.  In your case it might be the fact you do not have Microsoft.net 2.0 or below installed as FSXWX needs the old stuff.  Microsoft Visuals are used by developers to make sure their product is installed properly.  Microsoft.net's are installed by developers to make sure their application runs as intended.  I doubt FSXWX installed any Microsoft.net as that was done when FSX (boxed version) was installed.  You should look in C:\Windows\Microsoft.net\Framework\ and make sure v1.0, 1.1, or 2.0.50727 are installed.  I have them all installed.  I did not install them.  Some application did it for me as I'm not that smart to know how to install each.  I would suspect FSXWX uses v1.1 or 2.0 to run properly.

Share this post


Link to post
Share on other sites

I might that you must make sure FSX-SE is run with Admin Privileges - see page 11, AVSIM CTD Guide.

Share this post


Link to post
Share on other sites
1 hour ago, Jim Young said:

You followed the guidance on page 31 of the guide regarding the Microsoft Visuals and using the Microsoft.net Repair Tool and uninstalling the MSVCR80 visual using the Add/Remove Program?  

Hello again Jim! You were the one to help me once with this and recommend I follow the guide, which I did!

1 hour ago, Jim Young said:

 I doubt the problem is the Microsoft Visual C++ 2005 that is at fault in your situation if so.  For FSX-SE users, the developers, Dovetail, just installed Microsoft Visual C++2005 to maintain compatibility with legacy addons such as FSXWX.  They used another MS Visual to install FSX-SE and the reason why some say it runs better than the boxed version.  In your case it might be the fact you do not have Microsoft.net 2.0 or below installed as FSXWX needs the old stuff.  Microsoft Visuals are used by developers to make sure their product is installed properly.  Microsoft.net's are installed by developers to make sure their application runs as intended.  I doubt FSXWX installed any Microsoft.net as that was done when FSX (boxed version) was installed.  You should look in C:\Windows\Microsoft.net\Framework\ and make sure v1.0, 1.1, or 2.0.50727 are installed.  I have them all installed.  I did not install them.  Some application did it for me as I'm not that smart to know how to install each.  I would suspect FSXWX uses v1.1 or 2.0 to run properly.

Definitely sounds reasonable, I will definitely try that and let you know! However, ASN is not an old program (or is it? and I got the same problem when I tried a trial version of if not so long ago.. shouldn't ASN use a later version? I will try your tip anyways of course, I'm just bringing the ASN thing to the table to see if that says anything about the problem!

1 hour ago, Jim Young said:

I might that you must make sure FSX-SE is run with Admin Privileges - see page 11, AVSIM CTD Guide.

I have done that too :-)

Share this post


Link to post
Share on other sites
On 9/12/2013 at 9:09 PM, Jim Young said:

You must have versions 2 thru the latest installed.  Just like Microsoft Visuals, Microsoft.net Framework packages are not backward compatible (for the most part).  If you just have the latest installed (which means you had to uninstall the old ones), FSX and FSX addons may function for a while but eventually you will have problems depending on the situation.  I know FTX/Orbx was using the dotnet 3.5 package.  Not sure what the other developers used but again, the proper package is installed with the addon developer's install program.

With respect Jim, the .NET CLRs operate differently from the VS Runtime packages - they are backward compatible. You do not need .NET 1.1 or 2.0; any future version should run that software just fine. I only have 4.5, 4.6 and 4.7 installed on my machine and I run ActiveSky 6 (a .NET 1.1 package), Delta Virtual's ACARS 2.0 (a .NET 2.0 package), Delta Virtual's ACARS 3.0 (a .NET 4.0 package) without any issues at all. I've had this machine since 2014 I've never installed anything older than 4.5 on it.

Here's a microsoft KB article that may help: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility

Cheers!

Share this post


Link to post
Share on other sites
3 hours ago, Jim Young said:

 In your case it might be the fact you do not have Microsoft.net 2.0 or below installed as FSXWX needs the old stuff.  Microsoft Visuals are used by developers to make sure their product is installed properly.  Microsoft.net's are installed by developers to make sure their application runs as intended.  I doubt FSXWX installed any Microsoft.net as that was done when FSX (boxed version) was installed.  You should look in C:\Windows\Microsoft.net\Framework\ and make sure v1.0, 1.1, or 2.0.50727 are installed.  I have them all installed.  I did not install them.  Some application did it for me as I'm not that smart to know how to install each.  I would suspect FSXWX uses v1.1 or 2.0 to run properly.

Jim, I checked FSXWX website and it says it needs net framework 3.5, So guess installing 2.0 and lower won't solve it? :(

Share this post


Link to post
Share on other sites
27 minutes ago, Luke said:

With respect Jim, the .NET CLRs operate differently from the VS Runtime packages - they are backward compatible. You do not need .NET 1.1 or 2.0; any future version should run that software just fine. I only have 4.5, 4.6 and 4.7 installed on my machine and I run ActiveSky 6 (a .NET 1.1 package), Delta Virtual's ACARS 2.0 (a .NET 2.0 package), Delta Virtual's ACARS 3.0 (a .NET 4.0 package) without any issues at all. I've had this machine since 2014 I've never installed anything older than 4.5 on it.

Here's a microsoft KB article that may help: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility

Cheers!

Hi Luke, So you have any idea of what the problem might be, considering it always points to msvcr80 and I have pre-installed a bunch of times?

Share this post


Link to post
Share on other sites
13 minutes ago, leak91 said:

Hi Luke, So you have any idea of what the problem might be, considering it always points to msvcr80 and I have pre-installed a bunch of times?

Something is calling the VS runtimes with bad data, but beyond that I can't begin to speculate. You say it only happens at FSDT airports, but is there anything beyond that it has in common?

Cheers!

 

Share this post


Link to post
Share on other sites
1 hour ago, Luke said:

With respect Jim, the .NET CLRs operate differently from the VS Runtime packages - they are backward compatible. You do not need .NET 1.1 or 2.0; any future version should run that software just fine. I only have 4.5, 4.6 and 4.7 installed on my machine and I run ActiveSky 6 (a .NET 1.1 package), Delta Virtual's ACARS 2.0 (a .NET 2.0 package), Delta Virtual's ACARS 3.0 (a .NET 4.0 package) without any issues at all. I've had this machine since 2014 I've never installed anything older than 4.5 on it.

Here's a microsoft KB article that may help: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility

Cheers!

Thanks Luke, you are clearly the expert as you are a developer and I am not, but the link you provided reaffirms my comments.  I did a lot of research on dotnets and found that they are mostly not backward compatible.  As your link states, by default, an app runs on the version of dotnet it was built for (i.e., in FSX's case, v1.1.  V2 is compatible as it did not make that many changes).  But, just having the latest dotnet will not work for ALL apps (and FSX-SE, FSX/Acceleration Boxed) have a lot of add-ons and apps.  Certainly the latest dotnet will work with FSX and any addon developed back in the last decade.  There were bug fixes mainly for the latest and greatest stuff and some of the old stuff still exists.  But it isn't going to work 100% of the time.  Just uninstall all the previous versions and leave the latest only on your drive and you will see crashes or freezes.  For the Microsoft Visuals, one member uninstalled 2005 thinking he could keep the latest version and FSX would not even start up. 

When one gets an MSVCR80.dll error it means to me that the application that uses that Microsoft Visual was not installed properly as the developer intended.  It throws this error when things are not the way the developer intended to have his application installed.  What could cause this?  One possibility would be not installing the product with Admin Rights, without disabling User Access Controls (UAC), and/or an anti-virus/anti-malware program working in the background during the install.  Those possibilities are remote but they can happen during any installation of a program or add-on.  FSX Weather program may or may not need the old Microsoft Visuals and you could be right about that but I am voting for the old addons do need the old visuals for which they were developed (many add-ons do not install Microsoft Visuals or dotnet's as they assume the right versions are already installed). 

One of the things someone who gets this error can do that I did not mention was to simply do a system restore back to the time before the error started.  He can also make sure he does not have a corrupted User Profile as discussed in the AVSIM CTD Guide.  Fixing the User Profile instead of reinstalling Windows has fixed crashes for many members as the User profile gets corrupted somehow.

Share this post


Link to post
Share on other sites
26 minutes ago, Jim Young said:

Thanks Luke, you are clearly the expert as you are a developer and I am not, but the link you provided reaffirms my comments.  I did a lot of research on dotnets and found that they are mostly not backward compatible.

I disagree. Microsoft clearly states "The .NET Framework 4.5 and its point releases (4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, and 4.7) are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5." in the link. This matches what I've seen - I track my client configurations for Delta Virtual's ACARS - it's a .NET 4.0 app but fully 95% of the people using it are running .NET 4.6 or 4.5, and it runs flawlessly, including on my own system.

Does this mean that there isn't poorly written software out there that makes poor assumptions about its runtime and won't work on a newer version? Absolutely, and Microsoft provides the ability to install older versions in parallel. But that does not mean that they are not backwards compatible, and it also doesn't mean that the vast majority of .NET software will happily and successfully run on a newer version.

Out of curiosity, could you send me a link to what you found in your research? I am curious to see why we have come to such significantly different conclusions.

34 minutes ago, Jim Young said:

hen one gets an MSVCR80.dll error it means to me that the application that uses that Microsoft Visual was not installed properly as the developer intended.  It throws this error when things are not the way the developer intended to have his application installed.

That also isn't correct.The Microsoft Visual C++ runtimes are the native code equivalent of the .NET CLR - they are the runtime libraries needed to support the core functions in Visual C++. As a software author, there's no point bloating your executable with several megs of core library code that is the same for every single app compiled with that version of VC++.

(As an aside, the reason why these aren't backwards compatible is that the version is in the DLL name, and when the linked builds the executable it tries to load that specific DLL rather than a generic "latest VC++ runtime" dynamic link library.)

The problem with debugging crashes in C++ (or really, any non-managed code) is that you're throwing around raw pointers to memory locations and there's no way that the library functions can check whether they are right or not. If you pass in a pointer to a memory location outside FSX's address space, then the library (whether it's VCRUNTIMExx.DLL or one of the FSX APIs) will try and read/write from/to it, and the operating system will catch it and terminate the process. The faulting module will be the DLL, but the real cause is whoever called the function within that DLL. If it's a pointer within my process' address space, it's more insidious - I'll silently corrupt some other component's data causing a crash down the road.

So when you get a VCRUNTIME.DLL crash, it's almost never the fault of the VC++ runtime, and almost always the fault of whoever called it. I can easily crash FSX or XPlane via a C++ plugin by passing in a bad pointer. It's not a bug in either of those programs, it's a bug in my code, but this is the nature of unmanaged code. This is why programmer productivity is an order of magnitude better with Java and C# - you get to focus on your logic rather than the mundane of memory management.

Jim, please take my feedback in the spirit that it is intended. You do a lot of great work here helping others, but some of the information you repeat doesn't entirely match how the Microsoft software ecosystem works. To be fair, it's not my primary background, and if your research doesn't match mine (as it apparently does not), I would appreciate you passing along a link or data for me to evaluate.

Thanks!

Share this post


Link to post
Share on other sites
3 hours ago, Luke said:

Something is calling the VS runtimes with bad data, but beyond that I can't begin to speculate. You say it only happens at FSDT airports, but is there anything beyond that it has in common?

Cheers!

 

Its not related to airports, it's related to the weather program FSXWX. It happens randomly, sometimes in the beginning of a flight, sometimes mid-flight, descent... I believe it happens when the program reinjects the weather. Otherwise can't see anything else it has in common :/ 

The weird thing is that, as I mentioned earlier in the thread, this has happened with a trial version of ASN as well (on my older computer, just got a new one a few days ago). So all in all it seems to be related to weather injections. Maybe communication with SimConnect? The error that pops up usually says something about Simconnect and FSXWX. I'm the window event viewer the faulting module is usually msvcr80 though :/

Share this post


Link to post
Share on other sites
1 hour ago, Jim Young said:

One of the things someone who gets this error can do that I did not mention was to simply do a system restore back to the time before the error started.  He can also make sure he does not have a corrupted User Profile as discussed in the AVSIM CTD Guide.  Fixing the User Profile instead of reinstalling Windows has fixed crashes for many members as the User profile gets corrupted somehow.

I checked and no corrupted files. As to system restore: the error has been there from the beginning, and I got this computer a week ago, so I don't think it would make a difference unfortunately. The problem started on my.old computer when I got FSXWX, so it seems to clearly indicate something wrong when weather add-ons interact with FSX!

Share this post


Link to post
Share on other sites

I have removed

1 hour ago, Luke said:

I disagree. Microsoft clearly states "The .NET Framework 4.5 and its point releases (4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, and 4.7) are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5." in the link. This matches what I've seen - I track my client configurations for Delta Virtual's ACARS - it's a .NET 4.0 app but fully 95% of the people using it are running .NET 4.6 or 4.5, and it runs flawlessly, including on my own system.

Does this mean that there isn't poorly written software out there that makes poor assumptions about its runtime and won't work on a newer version? Absolutely, and Microsoft provides the ability to install older versions in parallel. But that does not mean that they are not backwards compatible, and it also doesn't mean that the vast majority of .NET software will happily and successfully run on a newer version.

Out of curiosity, could you send me a link to what you found in your research? I am curious to see why we have come to such significantly different conclusions.

That also isn't correct.The Microsoft Visual C++ runtimes are the native code equivalent of the .NET CLR - they are the runtime libraries needed to support the core functions in Visual C++. As a software author, there's no point bloating your executable with several megs of core library code that is the same for every single app compiled with that version of VC++.

(As an aside, the reason why these aren't backwards compatible is that the version is in the DLL name, and when the linked builds the executable it tries to load that specific DLL rather than a generic "latest VC++ runtime" dynamic link library.)

The problem with debugging crashes in C++ (or really, any non-managed code) is that you're throwing around raw pointers to memory locations and there's no way that the library functions can check whether they are right or not. If you pass in a pointer to a memory location outside FSX's address space, then the library (whether it's VCRUNTIMExx.DLL or one of the FSX APIs) will try and read/write from/to it, and the operating system will catch it and terminate the process. The faulting module will be the DLL, but the real cause is whoever called the function within that DLL. If it's a pointer within my process' address space, it's more insidious - I'll silently corrupt some other component's data causing a crash down the road.

So when you get a VCRUNTIME.DLL crash, it's almost never the fault of the VC++ runtime, and almost always the fault of whoever called it. I can easily crash FSX or XPlane via a C++ plugin by passing in a bad pointer. It's not a bug in either of those programs, it's a bug in my code, but this is the nature of unmanaged code. This is why programmer productivity is an order of magnitude better with Java and C# - you get to focus on your logic rather than the mundane of memory management.

Jim, please take my feedback in the spirit that it is intended. You do a lot of great work here helping others, but some of the information you repeat doesn't entirely match how the Microsoft software ecosystem works. To be fair, it's not my primary background, and if your research doesn't match mine (as it apparently does not), I would appreciate you passing along a link or data for me to evaluate.

Thanks!

Thanks Luke.  Understand.  I do not have the time or 'desire' to be researching this all over the Internet once again.  I will remove all references to dotnet and Microsoft Visuals from the CTD Guide.  Thanks for your assistance.

Best regards,

Jim

Share this post


Link to post
Share on other sites
18 minutes ago, Jim Young said:

I will remove all references to dotnet and Microsoft Visuals from the CTD Guide.  Thanks for your assistance.

Best regards,

Jim

Are you going to remove the entries about msvcr and reinstalling Microsoft visuals?? That HAS helped people before and it helped me get all the other msvcr errors away.. are you sure you should do that? The only error I haven't solved through the guide's instructions on this has been msvcr80!

Share this post


Link to post
Share on other sites
42 minutes ago, leak91 said:

Maybe communication with SimConnect? The error that pops up usually says something about Simconnect and FSXWX. I'm the window event viewer the faulting module is usually msvcr80 though :/

In your Steam FSX folder look in SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces\FSX-XPACK\ .  You should see SimConnect.msi in that folder. FSX-SE uses a custom version of simconnect.

15 minutes ago, leak91 said:

Are you going to remove the entries about msvcr and reinstalling Microsoft visuals?? That HAS helped people before and it helped me get all the other msvcr errors away.. are you sure you should do that? The only error I haven't solved through the guide's instructions on this has been msvcr80!

I am removing the MSVCR80 and other Microsoft Visual discussions on page 31 of the guide.  It does not hurt to have the old versions installed and my earlier discussions recommending that will remain in the guide.

Share this post


Link to post
Share on other sites
On 9/24/2017 at 10:54 PM, Jim Young said:

In your Steam FSX folder look in SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces\FSX-XPACK\ .  You should see SimConnect.msi in that folder. FSX-SE uses a custom version of simconnect.

Alright, i ran all the msi files, since it was a recommendation I saw a while ago for some programs. Do tell me if that was wrong!

By the way, the AVSIM config file recommends that high end users can should have global texture resolution set to max, however it also says that max texture load in the cfg file should not go over 2048. It also says the default is 1024. However when I put global texture resolution to max I notice that my max texture load automatically goes up to 4096. Does this mean global texture resolution should after all not be set at max?

Share this post


Link to post
Share on other sites

By the way, as to the whole Microsoft net discussion: I also interpreted the text in the links provided earlier by Luke as if Microsoft net is often but not always backwards compatible, I was not convinced of the fact that you can completely exclude the possibility of this being an issue. However FSXWX works with net framework 3.5, which FSXWX tells one to install when installing the program.. do you think, considering this, that installing earlier versions would be pointless?

Share this post


Link to post
Share on other sites
3 hours ago, leak91 said:

By the way, the AVSIM config file recommends that high end users can should have global texture resolution set to max, however it also says that max texture load in the cfg file should not go over 2048. It also says the default is 1024. However when I put global texture resolution to max I notice that my max texture load automatically goes up to 4096. Does this mean global texture resolution should after all not be set at max?

Sorry to hear you got confused over the recommendation.  There are three settings - 1024, 2048, and 4096.  The default is 1024.  The max is 4096 for this setting.  High end user can set to max (computers like mine - see specs in my signature) but we recommend 2048 as there is little difference between 2048 and 4096.  It's a FPS killer and VAS killer when set to high.  Just trying to save some from having a lot of crashes.  Of course, put it at 4096 if you think your computer can handle it.

In regards to dotnet recommendations, I stand fully by my recommendations.

Share this post


Link to post
Share on other sites

I have read the link provided by Luke above and found my previous research on backward compatibility was correct.  I will not be making any changes to the CTD Guide.  As stated in the link provided by Luke, "By default, an app runs on the version of the .NET Framework that it was built for. If that version is not present and the app configuration file does not define supported versions, a .NET Framework initialization error may occur. In this case, the attempt to run the app will fail."  So, like I stated, you need version 1.1, 2.0, 3.0, and 3.5 installed for most applications associated with FSX.  This is one reason why LM and Dovetail make sure those versions were installed if they were not already there when they installed P3D and FSX-SE.  If one goes on the assumption that one of the latest versions of Microsoft.net is compatible with the older versions of dotnet, then you will suffer from unexplained crashes or the triggering of the MSVCR80.dll error.  If you don't want to follow this advice, then you will eventually suffer the consequences of a crash.  I am not trying to destroy your enjoyment of FSX, FSX-SE, or P3D with my statements on backward compatibility.  Follow the advice of Luke or follow my advice.  Personally, I'm following my advice.

Share this post


Link to post
Share on other sites
11 hours ago, Jim Young said:

I have read the link provided by Luke above and found my previous research on backward compatibility was correct.  I will not be making any changes to the CTD Guide.  As stated in the link provided by Luke, "By default, an app runs on the version of the .NET Framework that it was built for. If that version is not present and the app configuration file does not define supported versions, a .NET Framework initialization error may occur. In this case, the attempt to run the app will fail."  So, like I stated, you need version 1.1, 2.0, 3.0, and 3.5 installed for most applications associated with FSX.  This is one reason why LM and Dovetail make sure those versions were installed if they were not already there when they installed P3D and FSX-SE.  If one goes on the assumption that one of the latest versions of Microsoft.net is compatible with the older versions of dotnet, then you will suffer from unexplained crashes or the triggering of the MSVCR80.dll error.  If you don't want to follow this advice, then you will eventually suffer the consequences of a crash.  I am not trying to destroy your enjoyment of FSX, FSX-SE, or P3D with my statements on backward compatibility.  Follow the advice of Luke or follow my advice.  Personally, I'm following my advice.

Jim, I will follow all of your advice. Even though I have yet to comprehend why it may have looked this way: I'm very sorry if anything I said made it look like I thought you were trying to kill my FSX enjoyment. The net framework issue I double checked with you since FSXWX instructions say the 3.5 version is needed, therefore I looked for guidance on whether or not you still considered installing earlier versions as possible solution despite that piece of information. Since you do consider that, I will do it.

I greatly appreciate all the time you have put down, not only on this occasion, to try and help me with my problem by writing detailed and extensive recommendations. I also appreciate the time and energy you have put into the guides. Besides, I didnt get any advice from Luke, so I would rather say that I consider Luke's contributions to the latest discussion (as good-willed they may have been) as contradictions to your advice, rather than advice on it's own ;-)

I do hope you haven't gotten frustrated with me on this and that you will still be willing to guide me through this tough labyrinth of FSX:SE issues,

Best regards,

Leo

  • Upvote 1

Share this post


Link to post
Share on other sites
On 2017-09-26 at 7:55 PM, Jim Young said:

I have read the link provided by Luke above and found my previous research on backward compatibility was correct.  I will not be making any changes to the CTD Guide.  As stated in the link provided by Luke, "By default, an app runs on the version of the .NET Framework that it was built for. If that version is not present and the app configuration file does not define supported versions, a .NET Framework initialization error may occur. In this case, the attempt to run the app will fail."  So, like I stated, you need version 1.1, 2.0, 3.0, and 3.5 installed for most applications associated with FSX.  This is one reason why LM and Dovetail make sure those versions were installed if they were not already there when they installed P3D and FSX-SE.  If one goes on the assumption that one of the latest versions of Microsoft.net is compatible with the older versions of dotnet, then you will suffer from unexplained crashes or the triggering of the MSVCR80.dll error.  If you don't want to follow this advice, then you will eventually suffer the consequences of a crash.  I am not trying to destroy your enjoyment of FSX, FSX-SE, or P3D with my statements on backward compatibility.  Follow the advice of Luke or follow my advice.  Personally, I'm following my advice.

Hi Jim, I had gone without any mscvr80.dll problems for a while. Yesterday, however, I got an MSCVR100.dll problem. Ran the reparation kit, reinstalled the C++ and haven't had time to try again yet.. but since reinstalling the C++ didn't really help previously (however installing the earlier net frameworks did) I wonder if there is any other solution you know to this? Thinking so im prepared for next time. 

Share this post


Link to post
Share on other sites

Microsoft.net's and Microsoft Visuals are used by developers when developing their application and running the application when installed.  This is why you see a lot of sites where they state you must have Microsoft.net 4.0.XXX installed.  The repair kit worked for me 3-4 years ago and I got the idea from a member and computer expert.  It is why it is in the AVSIM CTD Guide. 

When it does not work for you, this is why I came up with the section on how to fix almost all ctd's and freezes in FSX and P3D.  There's an application you installed that is not compatible with your installed Microsoft Visual or Microsoft.net.  The product might have been made for FS9 or Windows XP or Vista so needs an earlier Visual or dotnet.  These old dotnets and visuals do not know about the latest and greatest benefits of the latest tech in Microsoft Visuals and dotnets.  So, you have to rename your dll.xml, fsx/p3d.cfg, and scenery.cfg to something like just adding .off at the end of each (in case you want to return them).  Restart FSX or P3D and these files will be rebuilt.  Does the problem still exist?  If no, the issue is with one or more of these files.  Bring back your old dll.xml and see if the problem is still fixed.  If so, bring back your scenery.cfg.  If still no problems, then your problem was with something in your fsx or p3d.cfg.  Sometimes just renaming the p3d or fsx.cfg will fix the issue but, for Microsoft Visuals and dotnets, it is most likely something in the dll.xml or scenery.cfg.  An old airport scenery does not like the installed dotnets or Microsoft Visuals.  It is looking for the right version.  The AVSIM CTD Guide provides more solutions like this starting around page 7.

Share this post


Link to post
Share on other sites
10 hours ago, Jim Young said:

Microsoft.net's and Microsoft Visuals are used by developers when developing their application and running the application when installed.  This is why you see a lot of sites where they state you must have Microsoft.net 4.0.XXX installed.  The repair kit worked for me 3-4 years ago and I got the idea from a member and computer expert.  It is why it is in the AVSIM CTD Guide. 

When it does not work for you, this is why I came up with the section on how to fix almost all ctd's and freezes in FSX and P3D.  There's an application you installed that is not compatible with your installed Microsoft Visual or Microsoft.net.  The product might have been made for FS9 or Windows XP or Vista so needs an earlier Visual or dotnet.  These old dotnets and visuals do not know about the latest and greatest benefits of the latest tech in Microsoft Visuals and dotnets.  So, you have to rename your dll.xml, fsx/p3d.cfg, and scenery.cfg to something like just adding .off at the end of each (in case you want to return them).  Restart FSX or P3D and these files will be rebuilt.  Does the problem still exist?  If no, the issue is with one or more of these files.  Bring back your old dll.xml and see if the problem is still fixed.  If so, bring back your scenery.cfg.  If still no problems, then your problem was with something in your fsx or p3d.cfg.  Sometimes just renaming the p3d or fsx.cfg will fix the issue but, for Microsoft Visuals and dotnets, it is most likely something in the dll.xml or scenery.cfg.  An old airport scenery does not like the installed dotnets or Microsoft Visuals.  It is looking for the right version.  The AVSIM CTD Guide provides more solutions like this starting around page 7.

Thanks Jim, definitely will try them and the page 7 and onwards solutions :) by the way, out of curiosity, dont you think the dotnet/visuals problems should be gone since I installed all the early dotnets and the latest versions of the visuals? (I'm thinking of the example you gave with the old airports, could there still be a problem that is caused by the dotnet/visuals considering what I did?) Just seeing if I can exclude some solutions already :)!

Share this post


Link to post
Share on other sites

I'm not a developer and cannot answer your question completely.  Maybe it is NOT the visual/dotnet that is triggering the crash but another issue with Windows which is triggering the Microsoft Visual error.  But, from what I have learned, if the coding is not proper for a program, the Microsoft Visual error will be triggered.  It could even be high settings.  If you remove the old dotnets and Microsoft Visuals, FSX will not start up.  It has been proven as we had a member (a computer expert) who was telling everyone to get rid of their old Microsoft Visuals and dotnets and I told him not to do it.  He tried by removing them and FSX would not start up.

It is super easy to disable your scenery.cfg, dll.xml, and p3d.cfg.  That will tell you if you have some module or addon installed that is not compatible with P3D.  Just remember, P3D and FSX were not developed with addons and the apps works great until you start adding the addons.

Share this post


Link to post
Share on other sites

With respect Jim, but I've never installed any .NET version before 4.5 (I have 4.5, 4.6 and 4.7 on my machine) and FSX, P3D3, P3D4, ActiveSky and other .NET programs have always run smoothly and reliably. The issues that I have are related to poor third party add-ons and are immediately corrected when they are removed or disabled.

I do not know what this so-called "expert" did or didn't do. I can't duplicate it because I cannot uninstall what I never installed in the first place. If you wish to install all sorts of .NET versions to make yourself or others feel better that's great, but it's either just a placebo effect or the act cleans up some other underlying (real) issue.

The FSX release date was less than 90 days before the release date of .NET 2.0. There are literally thousands of people running FSX and not running .NET 1.1 or 2.0.

Cheers!

Luke

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now