P3D MSVCR100.dll CTD [Solved]

[iwebber 207]

Dear All,

 

I recently started getting lots of CTDs with P3D 2.4 with the faulting module always MSVCR100.dll.

 

Having done a load of Google searches and trying all the fixes I could find, it was still happening.

 

I spent best part of a day disabling, testing, disabling, testing until I found the culprit.

 

What fixed it for me was to delete the FSUIPC4.ini file and let it generate a new one. This is not a dig or accusation at FSUIPC (v4.937) but it seems to have got it's knickers in a twist about something and letting it start over fixed this particular CTD.

 

Hope this saves someone some time,

 

Ian

[iwebber 207]

After a bit more digging, it turns out setting either CloudTurbulence or CloudIcing to Yes causes mine to CTD.

 

Keep them both no and life is sweet...

[Jim Young 2,356]

I'm glad you found the fix for your problem. As you know the MSVCR100.dll belongs to Microsoft Visual C++ 2010 and, what you may not know is that PMDG and P3D programs are currently using MSV 2010. Other programs, like Orbx/FTX products may now be using it too but I know for sure it is used by PMDG and Lockheed. Developers use Microsoft Visuals to help install their products/addons properly.

 

This solution may or may not work for everyone. This is one reason why I have recommended that everyone who gets a CTD to disable their modules, like FSUIPC, in the dll.xml. It's one of the recommendations in the AVSIM CTD Guide. This way you can immediately see if one of your modules is causing this problem. If you continue to get crashes after disabling all of the modules, then you know it's not the modules and you can move on to another possible solution, like rebuilding your fsx.cfg or disabling all of your addon scenery in the scenery.cfg. Of course it could be an aircraft addon too and if you get the crashes using one particular addon aircraft, then that should certainly be suspected too.

 

In any case, thanks a lot for posting your solution to your CTD. I know how frustrating CTD's can be and how much they can affect your enjoyment of flight simming. Hopefully the crashes will stay away!

 

Best regards,

[aerojef 0]

Thank you thank you thank you!  That was exactly my problem too.  Bless you for posting that solution!

[Guest]

I recently started getting this error also ... I have FSUIPC .437b registered version.  However my solution was very different ... I ended up having to install .NET Framework v4.5.2 to resolve.  Didn't need to do anything with FSUIPC.  

 

I had gone thru the process of uninstall and reinstall of all the VC++ 2010, 2012, and 2013 redist.

 

I'm was not "confident" in my solution as it would only make sense if something got corrupted in my registry or another version was installed.

 

During this process I did notice something very odd with my VC++ 2012 ... I had the german versions installed ... this wasn't the source of my problem (at least I don't think it was), but it was interesting.  There were only two products on this particular PC that could have installed the German version of VC++ 2012 ... it was either Navigraph or FSCommander 9.5.  I'm thinking Navigraph because it was the most recent install for me on that PC.

 

So my final solution was to:

1.  Download the english versions of VC++ 2010, 2012, 2013 both x86 and x64

2.  Uninstall my existing versions of VC++ 2010, 2012, 2013

3.  Install the latest English versions

4.  Install .NET framework 4.5.2

 

This cured it on both my computers.

 

Cheers, Rob.

[Jim Young 2,356]

Hi Rob,

 

Interesting information. I hope I did not insinuate that fsuipc might have been the fault. My usual recommendation when someone has a crash is to disable the modules in the dll.xml (or move the dll.xml to a temporary folder), run FSX/P3D (as appropriate) and see if this fixes the problem. If so it is likely one of the modules and the individual will have to reenable them one by one until the culprit is found.

 

Microsoft Visuals are another story. They are not backward compatible and FSX/Acceleration and most addons use Microsoft Visuals 2005 w/SP1 and 2008 w/SP1. FSX/Acceleration needs MSV 2005 w/SP1 to run and most FSX addons use MSV 2008. So anyone owning FSX must have these installed. Recently, Orbx/FTX, ASN, and PMDG upgraded their software to MSV 2010 so that version is required (as well as a requirement for P3D). If the proper version is not installed, the product will not even start up. I know because one member tried to test my comments and told me I was wrong. He later came back and apologized.

 

FSX also needs dotnet 2.0 to run. When FSX/Acceleration were installed, dotnet 1.1 was installed but 2.0 came out later with minor changes and it works just as great. So I recommend everyone with FSX/Acceleration make sure dotnet 2.0 is installed. Some early addons to FSX require dotnet 3.0 and 3.5 but I saw that Orbx/FTX, who required 3.5, upgraded their products for dotnet 4.0 or 4.5. Again, dotnets are not backward compatible (for the most part). I had Googled that a long time ago and the experts say you need them all.

 

So, if you only have P3D installed, then you need MSV 2010 and dotnet 4.0 or 4.5 (these are installed by the installer if not found on your system)(Windows 7 and 8.1 require the latest versions).

 

That was certainly strange Navigraph/FS Commander 9.5 would have installed MSV 2012 (a German version). I was not aware any addons used any MSV above 2010.

 

I might add everyone needs the 32 bit versions for FSX/P3D but the 64 bit version for X-Plane if they use the 64 bit version of X-Plane. A lot of people get rid of their 32 bit versions as they are running a 64 bit version of Windows.

 

Thanks for your input!!

 

Best regards,

[Guest]

I hope I did not insinuate that fsuipc might have been the fault.

 

Who knows, it maybe for the OP's instance ... or it was going to be a problem and FSUIPC just happened to be the one to trigger it  ... there are just so many variables it's very difficult to pin-point "who's on first".  There can be more than one way to trigger this type of error ... so I'm not discounting anything.  Just sharing my experience also which in my case was NOT related to FSUIPC.

 

I was VERY shocked to find I had the German versions of VC++ 2012 installed because when viewing it in the control panel there is no obvious indication it's a German version.  It wasn't until I actually initiated the Uninstall that I discovered it was the German version.  I think some of the 3rd party installers need to have a re-think about what they are doing ... I've often seen 3rd party products installing run-times they should not be installing and/or failing version check and still install or worse yet partial installs.  It sadly can be a giant mess and as many have done, resorted to complete system wipes and OS re-installs.

 

Unfortunately this is what we call DLL hell ... the solution to get out of "DLL versions" was supposed to be .NET Framework ... but that strayed and became yet another issue to contend with as .NET progressed ... good idea, poor implementation (on par for Microsoft).  

 

Personally I preferred the days where you distribute what you need in the root of your application and don't rely on a "common" repository of shared run-times -- that way if there is an application problem it's just that application affected and doesn't bring down one's system or many other applications.   Ironically this process stemmed for conservation of HD space from way back in the day ... in today's world it's a non-issue for these relatively small run-times yet we have an entire construct in place -- short sited vision from Microsoft devs.  The biggest problem with common repository of run-times is:

 

1.  Expecting an end user to know how to answer the question (during an uninstall) "do you want to remove this XYZ.DLL that is a shared..." - to me this just seems like way too much to expect from an end user, how could they possibly know what's sharing it and how their answer to the question could be disastrous for them?

 

2.  End user uninstalls a .NET framework or a VC++ runtime and the next thing they know they reboot and many of their applications crash and in some cases you have to resort to Windows SAFE mode to boot ... just a BAD idea ... an idea that fit Microsoft's desires and not necessarily end user desires but leaves the developers holding the support bag.

 

Probably more than you wanted to know ... sorry.

 

Cheers, Rob.

[Jim Young 2,356]

Probably more than you wanted to know ... sorry.

No, I'm always interested in this stuff and I agree with your comments. I actually wish there was just one dotnet and one MSV that works with everything and older applications would be upgraded accordingly. Of course, if Microsoft would have kept the FSX Aces Team, future updates would have included updates to the MSVisuals/dotnet programs too but we are one of the few users out there that has to have a lot of garbage on our machine which possibly causes a lot of unnecessary issues with our members and the flight simulation community. This is why I like Lockheed Martin getting some of the code and developing P3D, a program very similar to FSX. I hope Microsoft stays out of the flight simulation business forever as the greed and stockholders do not allow any of their products to fully mature. Lockheed has a business interest to keep P3D in development forever.

 

Best regards,

[hjsmuc 393]

Thanks Jim and Rob, very interesting stuff. I lived without the error for weeks until I installed the Milviz310 which I bought in particular because of the said easier integration of the GTN750. It turned out that the integration is not really easy and simultaneously the dll error was back. I will try your suggestion Rob and hope that it helps me as well.

 

Best,

Hans

[jfmitch 33]

Worked for me, thanks

 

Jim

[alexcunille 3]

Yes SIR "iwebber"  FSUIPC.ini made mi P3D CTOD when I load Mayor Thunderstorm Theme, I did delete it and no CTOD, strange but it worked!!!   :wink: