CTD with PMDG MD11 and FS2CREW for FSX since 4.8

[kriggelb]

Dear Mr. Dowson,

I'm encountering CTDs since updating FSUIPC from version 4.7 to 4.8 when flying the PMDG MD11 combined with FS2CREW (button version). It's quite interesting, because I have got the latest version of both (PMDG MD11 and FS2CREW MD11) and both products worked quite well with version 4.7 of FSUIPC. Then I installed PMDG 737 NGX and also updated FSUIPC from 4.7 to 4.8 (actually with modules 4.831). The 737 NGX seems to work perfectly in combination with FS2CREW (version 1.4), but now I always get CTDs when approaching Oslo (ENGM by Aerosoft) with the MD11. The CTDs can easily be reproduced: every time I approach ENGM I get a CTD with different .dll error logs (terrain.dll, g3d.dll, ntd....dll). I've got an absolutely stable high end pc system, but already tried to move some sliders to the left (in-game-settings). Still the crashes always occur when approaching ENGM and interacting with FS2CREW in the MD11: just in between the descent and landing checklist...

Do you have a clue what could be causing the problem? There were no hardware changes and no further tweakings after obtaining a very stable system, but the package "MD11, FS2CREW and FSUIPC 4.8(31)" seems to be tricky somewhere.

Could it be a solution to leave FSUIPC the way it is and reinstall the MD11 and FS2CREW in order to get a fresh installation on a system already running FSUIPC 4.831? I wouldn't like to go back to FSUIPC 4.7, because the new version seems to run perfectly with the NGX on my system.

By the way, I have got a registered version of FSUIPC - thanks for your work:-)

Kind regards,

kriggelb

[Pete Dowson]

I always get CTDs when approaching Oslo (ENGM by Aerosoft) with the MD11. The CTDs can easily be reproduced: every time I approach ENGM I get a CTD with different .dll error logs (terrain.dll, g3d.dll, ntd....dll).

I'm sorry, but there is no way FSUIPC can be involved in any of those types of CTD. And there is no relationship that I know of between those products and FSUIPC, excepting the possibility of your enabling the NGX's SDK provisions for supplying data for third party programs, which FSUIPC maps to offsets.

It actually sounds exactly like a scenery problem causing memory corruptions. Folks always like to blame FSUIPC for all such things, but it really cannot be involved at all. The only small difference a new version might make, because of its different size, is a slight shift in some memory positions for some data.

If you were going to reinstall anything I would suggest that the Oslo scenery be your first target.

Regards

Pete

[kriggelb]

Hello,

please don't get me wrong - I'm not trying to blame FSUIPC for anything:-)

I'm just trying to "think" the way, programs could actually interact with each other - I know the saying: "computers help us solving problems we wouldn't have without them..."

Yesterday I tried something that seems to solve the problem:

I opened the FS2CREW start center and first restored the original PMDG key assignments for the MD11 and then just set them to the FS2CREW-way again. There was no CTD when approaching ENGM now.

It seems to be a problem of the aircraft.cfg, panel.cfg etc. when installing FSUIPC after setting up PMDG and FS2CREW - not because FSUIPC is a problem, but because PMDG and FS2CREW seem to interact in a specific way that could cause problems when "adding" a .dll afterwards...

Regards,

kriggelb

[Pete Dowson]

It seems to be a problem of the aircraft.cfg, panel.cfg etc. when installing FSUIPC after setting up PMDG and FS2CREW - not because FSUIPC is a problem, but because PMDG and FS2CREW seem to interact in a specific way that could cause problems when "adding" a .dll afterwards...

Well, I suppose it could change the timings of things, but if it is associated with a specific area of the world it is nearly always going to be because of a problem with that scenery. By changing the order of things you are probably simply still getting the problem but the memory corruption is then occurring in a place which at that time isn't being used for anything critical and doesn't therefore cause a crash. Another small change at another date could cause it to matter again. If that happens I would seriously consider reinstalling the scenery, also looking ot see if there's an update for it.

The last time I got such an odd problem it was actually a couple of bad BGL type files in a much lower level scenery -- one of the Ultimate Terrain layers. The only fix was to delete/rename two specific BGLs, and the onlty plake it caused the crash was Copenhagen (though i don't think I went to Oslo before fixing it), so yours might even be the same problem. Do you have UT installed?

Regards

Pete

[kriggelb]

OK, that sounds very logical to me - thanks for that!

But unfortunately

1. I don't have UT installed, but FS Global 2008... and

2. I already reinstalled the scenery and there are no updates available at the moment.

One thing is quite clear to me:

I can't use the error logs to solve the problem. I hope there is an ENGM update soon...

Still thanks a lot,

kriggelb

[Pete Dowson]

One thing is quite clear to me:

I can't use the error logs to solve the problem

I located the BGLs affecting me by using "ProcMon", a free program from www.sysinternals.com which can be used to log access to all files, devices, etc. It produces a lot of data so you have use to the filters to narrow it down to specific file types and special actions, like "createfile" (the action used to open existing ones as well as create -- misleading name).

It takes a lot of patience though. I spent a couple of days on it because I wasn't willing to avoid trips to or over Denmark!

Regards

Pete

[kriggelb]

Wow, great!

I'll see if I have enough time to try this out!

Thank you!!

[kriggelb]

So, I finally made two approaches to ENGM without crashing to desktop. I flew in window mode and got ProcMon running in the background.

Even though I didn't get a CTD there are several "name not found"-results referring to the file

J:\Microsoft Games\Microsoft Flight Simulator X\Scenery\World\TEXTURE.CAB

Additionally there are single .agn-files that also caused an "name not found"-result:

J:\Microsoft Games\Microsoft Flight Simulator X\Scenery\World\Texture\027b2an4.agn

J:\Microsoft Games\Microsoft Flight Simulator X\Scenery\World\Texture\027b2an3.agn

and several others...

Looking at the time this occured it's just the time when usually the CTDs happen...

As you see it: Could that be the cause? And if yes, does it mean that I have to manually install the texture.cab-file by using the original FSX-CD or can I just set this file to .CAB.off??

In fact there is no .cab-file in the Scenery\World-folder, but only the two folders "scenery" and "texture"...

So there is no way to turn it off, but how can I prevent fsx.exe from searching for this file?

Kind regards,

kriggelb

[Pete Dowson]

Looking at the time this occured it's just the time when usually the CTDs happen...

As you see it: Could that be the cause? And if yes, does it mean that I have to manually install the texture.cab-file by using the original FSX-CD or can I just set this file to .CAB.off??

In fact there is no .cab-file in the Scenery\World-folder, but only the two folders "scenery" and "texture"...

So there is no way to turn it off, but how can I prevent fsx.exe from searching for this file?

Sorry, I don't understand these things either. It isn't an area I know much about I think 'agn' files are autogen files. I don't think those missing does any harm, but I wouldn't swear to that. CAB files are simply containers for other files. I don't know why it would want missing ones of those. Maybe there's a scenery Forum someplace (AVSIM?) which has experts on this stuff who can advise, or perhaps check in the CTD forum over in AVSIM?

Generally i've not found missing files a problem for FSX. It just seems to waste a lot of its time checking for stuff that may or may not be there or which might be available to it in different formats. When I view what FS is doing with files it makes me very sad indeed as it seems to do a helluva lot of unnecessary or repeated accesses all the time -- very often reading files which cannot possibily have a bearing on your locality, stuff from thousands of miles away. Think how fast it could be if it didn't do all that stuff! :sad:

Anyway, I wouldn't worry yourself about it unless you do get a CTD, then you need to check the last accesses for clues. It won't be the very last, so you'd need to look back a litte. To avoid lots of irrelevant stuff freeze the ProcMon log as soon as the CTD happens.

Regards

Pete

[kriggelb]

Ok, thanks,

now, that I can use ProcMon I'll surely find a solution once the CTD happens again...

Kind regards,

kriggelb