MSVCR80.dll Error

[MrLyo 2]

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...

[Jim Young 2,356]

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.

[Jim Young 2,356]

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

[MrLyo 2]

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 :-)

[Luke 782]

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!

[MrLyo 2]

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? :(

[MrLyo 2]

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?

[Luke 782]

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!

 

[Jim Young 2,356]

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.

[Luke 782]

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!

[MrLyo 2]

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 :/

[MrLyo 2]

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!

[Jim Young 2,356]

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

[MrLyo 2]

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!

[Jim Young 2,356]

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.