Patience is a virtue

For what it can be worth but I had a CTD flying EDDF-EGLL between the fix REMBA and GILOM. I've installed all suggested libraries and had the LOD set to 7.5. After reducing the LOD to 4.5 I just got the missing library warning but no more CTD.

No rushing Pete ; I can wait for half an hour........( What's the time ? )

Can't be that late for you in Netherlands, or you made the night through!!??

Okay, try 4.749b http://fsuipc.simflight.com/beta/FSUIPC4749b.zipThis now checks within the loop, not before entry. So the count will increase substantially.It also now tries to identify the file being processed -- or at least the last one I can identify as a file when the routine is called. The file name will be logged along with the bad pointer value (not that the latter is much use to anyone really).Here, testing on a default FSX installation, and with a Debug version of 4.749b rigged to log all filenames, it looks as if the failing function is only used to process objects -- aircraft, scenery objects like vehicles and so on (i.e. everything in "SimObjects"). I've not yet caught it looking at scenery BGLs themselves, so I'm very doubtful that scenery textures are involved.I'm out for a couple of hours. I'll review the results here later. Still no promises, but fingers crossed ...RegardsPete

I hope the link is right now Testing...Please note: I set LOD_RADIUS so high that my VAS is between 3.1 and 3.5 GB. That is what triggers g3d.dlls here usually but only at specific airports.EBBR Test, now we got another offset:Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Faulting module name: g3d.dll, version: 10.0.61472.0, time stamp: 0x475e180cException code: 0xc0000005Fault offset: 0x00062c99Faulting process id: 0x100cFSUIPC LOG: 169682 **** G3D Bad Ptr: 0x6CD61946LOWI Test:Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Faulting module name: g3d.dll, version: 10.0.61472.0, time stamp: 0x475e180cException code: 0xc0000005Fault offset: 0x00062c99Faulting process id: 0x744FSUIPC LOG: 160462 **** G3D Bad Ptr: 0x003CB925EDDF Test:Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3Faulting module name: g3d.dll, version: 10.0.61472.0, time stamp: 0x475e180cException code: 0xc0000005Fault offset: 0x00062c99Faulting process id: 0xeb0 FSUIPC LOG: 164019 **** G3D Bad Ptr: 0x0CE09C61Any use from these numbers?

Just flown twice over my error area and did not have a CTD....I will try 2x extra later this afternoon to be sure.Word Not Allowed , I will make a flight to EBBR too.Can you tell me the coordinates of the crash area ?

Just flown twice over my error area and did not have a CTD....I will try 2x extra later this afternoon to be sure.Word Not Allowed , I will make a flight to EBBR too.Can you tell me the coordinates of the crash area ?

I can do better:http://dl.dropbox.co...446/crashes.rarBut: be sure to set your LOD_RADIUS so high that your VAS reaches 3GB at least (in process explorer!). As said, I set it as high as needed to get between 3.1 and 3.5GB. Otherwise crashes are inconsistent.For me LOD_RADIUS=10.5 is working nice, it puts VAS to about 3.1 and I can pan around to get it to about 3.3. You gotta experiment.Also VAS is going to depend on scenery you are using - for instance UTX or not.Pete, could it be also that some sceneries are irreparable? Like, that it works for ORBX but it doesn't work for Aerosoft's sceneries?!

Unfortunately the 3rd time flying over my problem area I got a CTD.FSUIPC Log :242332 LUA: LINDA:: Offsets watching list cleared! 535131 **** G3D Bad Ptr: 0x01AFD2E3 535131 Last file="D:Microsoft Flight Simulator XMyTrafficAircraftB744MXmodel.HighFSXP-PWB744-PW-quality"Version : 10.0.61637.0Module : g3d.dllOffset : 0x00064469Ex.code : 0xc0000005Proces ID : 0x10bc

I guess this ain't gonna be a simple solution as we might have thought...

Tested with slightly higher settings, crash, here is the log:********* FSUIPC4, Version 4.749b by Pete Dowson *********User Name=User Addr=FSUIPC4 Key is providedWideFS7 Key is providedRunning inside FSX on Windows 7Module base=61000000 15 System time = 29/11/2011 07:08:15 31 FLT UNC path = "AL-NVIDIA-PCFlight Simulator X Files" 46 Trying to connect to SimConnect Acc/SP2 Oct07 ... 46 FS UNC path = "D:Microsoft Flight Simulator X" 280 LogOptions=00000000 00000001 280 Wind smoothing fix is fully installed 280 G3D.DLL fix attempt installed ok 280 SimConnect_Open succeeded: waiting to check version okay 280 Trying to use SimConnect Acc/SP2 Oct07 2542 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 2542 Initialising SimConnect data requests now 2542 FSUIPC Menu entry added 2589 D:Microsoft Flight Simulator XFLIGHTSOTHERFLTSIM.FLT 2589 D:Microsoft Flight Simulator XSimObjectsAirplanesAircreation_582SLAircreation_582SL.AIR 24164 D:Microsoft Flight Simulator XSimObjectsAirplanesCarenado Centurion T210Carenado_T210.AIR 48048 C:UsersAl-nVidiaDocumentsFlight Simulator X FilesVFR Orcas I to Portland Intl.PLN 103241 System time = 29/11/2011 07:09:58, Simulator time = 11:42:37 (19:42Z) 103241 Aircraft="T210 CENTURION ELECTRIC BLUE" 103288 Starting everything now ... 104567 Advanced Weather Interface Enabled 2669614 **** G3D Bad Ptr: 0x0D75A2E3 2669614 Last file="D:Microsoft Flight Simulator XMyTrafficAircraftF18MXmodelF18F"Note that VAS was just above 2.9 from 10nm before KSEA right up to the crash; is it of relevance if both GSalden and me have a "Traffic X" file as "last file" ?alain from Montreal

EBBR Test, now we got another offset:

That's what I was afraid of. By letting it carry on regardless of the bad data now trapped, it trips up in another place, probably on the same bad data.I'm not sure I can fix that sort of thing. I'm not going to have enough patirence to patch all possible places where it might trip up.One thing I might try, seeing as the bad pointers are links in a chain, is overwrite the memory place from which the bad pointer emerged in the hope that the other places are using the same original and not re-reading it or using a different copy.

FSUIPC LOG: 169682 **** G3D Bad Ptr: 0x6CD61946

Wasn't FSUIPC able to determine the filename? If it had it would be in the next log line. Maybe I need to change the way I find the filenames for SP2, but I only have Acceleration installations here so it's rather difficult.

Any use from these numbers?

Not the bad pointers, no, but I'll have a quick look at offset 62C99 to see if it's using the same data or a different copy or different data altogether.RegardsPete

Wasn't FSUIPC able to determine the filename? If it had it would be in the next log line. Maybe I need to change the way I find the filenames for SP2, but I only have Acceleration installations here so it's rather difficult.

Yeah, in my case it was usually my aircraft, it said either CRJ 700 or Learjet, depending what flight I used (I use either or).I didn't paste it since I thought it might be unimportant, since it only referenced to my used aircraft.

Not the bad pointers, no, but I'll have a quick look at offset 62C99 to see if it's using the same data or a different copy or different data altogether.

Hm ok, if you need that line that comes after the pointer, just say it.

Unfortunately the 3rd time flying over my problem area I got a CTD.FSUIPC Log :242332 LUA: LINDA:: Offsets watching list cleared! 535131 **** G3D Bad Ptr: 0x01AFD2E3 535131 Last file="D:Microsoft Flight Simulator XMyTrafficAircraftB744MXmodel.HighFSXP-PWB744-PW-quality"

Ah, at least you got the filename of the last file accessed. It looks like something is causing the MDL files to be trampled on. All the files logged here (when I log every passage through) are SimObject MDL files.

Version : 10.0.61637.0Module : g3d.dllOffset : 0x00064469

Looks like that's the Acceleration version of the same offset Word Not Allowed just got in SP2. I'll be looking.RegardsPete

Yeah, in my case it was usually my aircraft, it said either CRJ 700 or Learjet, depending what flight I used (I use either or).I didn't paste it since I thought it might be unimportant, since it only referenced to my used aircraft.

That's interesting. The G3D routine which is crashing is only processing aircraft and other SimObjects in any case. You'd think the current aircraft data would be held in memory instead of being reloaded each time, so it may well be -- along with its MDLs path name. This suggests that it's an MDL file structure in memory which is being corrupted (by some bug elsewhere no doubt), and may explain why some actions, like AutoSave, can reduce the errors by forcing some things in memory to be reloaded.I certainly think the filename log entry is likely to be more interesting than the bad pointer value, as the latter could be absolutely any old rubbish and is unlikely to have any useful meaning. That's why it is "bad". ;-)The other two reports with 4.749b have AI traffic MDL files reported instead of the user aircraft, but I suspect the same process is at work.I'll experiment with trying to terminate the chain of pointers. If it really is the MDL being processed in order to draw or re-draw the aircraft or other object then that could result in some missing parts ...Pete