tommchowat

Managed to complete the flight with beautiful visuals and performance. I rebuilt the CFG file and didn't tweak it at all apart from Optimize Parts. Think that's the lesson now, no more messing with sliders and configs and tweaks... It works, so leave it. Thanks.

I filtered the log file to only show gdiplus access, and there were two logs at 17:09:06 with the same path to gdiplus that Event Viewer showed, both were a 'SUCCESS'.

Sorry to drag this up again, I'm sure you're bored of it but the same rubbish is happening still, this time at exactly the same spot elsewhere. Taxiing towards runway 12 in Kingston, about halfway to the runway I'm always getting a gdiplus.dll error. The flight to Kingston from Gatwick went brilliantly last week. I've been testing it all day and can't get to the bottom of it. I got Process Monitor and made a note of the exact time it crashed and had a look to see if I could spot something, but I can't. Here's the message from Event Viewer, time 17:08:57 Faulting application name: Prepar3D.exe, version: 2.5.12946.0, time stamp: 0x555f2e54 Faulting module name: gdiplus.dll, version: 6.1.7601.18852, time stamp: 0x555633d1 Exception code: 0xc0000005 Fault offset: 0x000c7e85 Faulting process id: 0x104c Faulting application start time: 0x01d0cadf99272dfe Faulting application path: D:\Prepar3D v2\Prepar3D.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18852_none_72d5ba7586659cb4\gdiplus.dll Report Id: 47f72e93-36d5-11e5-9122-bc5ff436a2d8 Here's the associated bits of the log file at around that time: Now the sim itself froze at 17:08:52, so here are the associated bits of the log file at that time: Now at the time the sim crashed (above picture), I can't spot anything out of the ordinary in the log file there, partially because everything says "SUCCESS". At the time Event Viewer recorded the crash (first two pictures) I can't really make head or tail of what any of it means!

Thanks for the help anyway, I've made alot of adjustments to my configuration which will probably help to avoid future crashes.

It doesn't have a scenery library entry, I just installed the models and made an entry in the Sim Objects CFG. To be honest it's not worth the time or effort to figure out what is causing this, it's just a short hop which I'm probably never going to do again, so I'm just going to have to come to terms with it!

I only have UT2 installed for the models as I only fly on Vatsim so I'd be surprised if it was that. The EGLL - OMAA flight went without a hitch, as did the OMAA - OOMS. There must be something, somewhere on that route in that exact place which my computer just doesn't get on with. Strange indeed.

After all that, still getting the same crash in exactly the same place, every time. Descending through 190 on the way into OMAA. Disabled all addon scenery too. I'll do the longer OMAA-EGLL and if that goes well then I'll just have to put it down to that particular route!

Update: I started up everything at Muscat in the 777 like I normally would, full procedure, GSX running and all, and I set up everything all the way up to ready to push and left it like that - it's usually after about 5-35 minutes that I'd get the crash. However, it just sat there behaving with no crashes for about an hour. Didn't have time to actually take off as I have to go to work, but it looks promising so far. Only weird thing is that Active Sky Next on my networked laptop decided not to start up at all on double clicking the icon - hopefully that's a fairly straightforward reinstall. Thanks for your help so far.

Thanks for replying Jim. I did mean 353.06, not 353.03, not sure those even exist! I uninstall video card drivers in Add/Remove programs then restart in safe mode and use driver sweeper. However when I install a new one I don't disable anti-virus protection - I'll do this now. I've taken ownership of all relevant P3D folders. I've got UAC disabled and P3D running as admin. I've added the P3D directory in my exception list for scanning by my anti-virus. I also realised I didn't have any chipset drivers installed, and found some on the Asrock site. I also updated the firmware for both my Samsung SSD's. We'll see how it goes.

Hi Guys, I'm at the end of my tether with this. I moved over to P3D from FSX a while ago, and have had nothing but trouble on a totally fresh install of Windows 7. I can't complete a flight in the PMDG 777 from Muscat to Abu Dhabi, the sim is constantly crashing either on the ground or during the descent. More often than not it's caused by gdiplus.dll. I remember I had this a while ago with FSX and it helped to go back to a previous Nvidia driver (344.65 I think worked). Didn't work this time though. With the latest driver (353.30) I get a gdiplus.dll error without fail, like this: Faulting application name: Prepar3D.exe, version: 2.5.12946.0, time stamp: 0x555f2e54 Faulting module name: gdiplus.dll, version: 6.1.7601.18852, time stamp: 0x555633d1 Exception code: 0xc0000005 Fault offset: 0x000c7fa0 Faulting process id: 0x10a4 Faulting application start time: 0x01d0b69c99ed9031 Faulting application path: D:\Prepar3D v2\Prepar3D.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18852_none_72d5ba7586659cb4\gdiplus.dll Report Id: cdc55e57-2296-11e5-b74a-30b5c218a6ad Reverting back to the previous driver (353.06) I get a crash I've never seen before: Faulting application name: Prepar3D.exe, version: 2.5.12946.0, time stamp: 0x555f2e54 Faulting module name: nvwgf2um.dll, version: 9.18.13.5306, time stamp: 0x55668242 Exception code: 0xc0000096 Fault offset: 0x006ebd85 Faulting process id: 0xc64 Faulting application start time: 0x01d0b6970c8dd0c1 Faulting application path: D:\Prepar3D v2\Prepar3D.exe Faulting module path: C:\Windows\system32\nvwgf2um.dll Report Id: a48852f4-228b-11e5-87b6-bc5ff436a2d8 And now using 344.65 which fixed the gdiplus.dll error when I was using FSX, I get this: Faulting application name: Prepar3D.exe, version: 2.5.12946.0, time stamp: 0x555f2e54 Faulting module name: gdiplus.dll, version: 6.1.7601.18852, time stamp: 0x555633d1 Exception code: 0xc0000005 Fault offset: 0x000c7f80 Faulting process id: 0xbfc Faulting application start time: 0x01d0b6a9c19f005e Faulting application path: D:\Prepar3D v2\Prepar3D.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18852_none_72d5ba7586659cb4\gdiplus.dll Report Id: 8623f651-229f-11e5-8833-bc5ff436a2d8 It's getting a bit ridiculous. Background information: Fresh install of Windows 7 x64, UAC off, fully up to date P3D 2.512946 running as admin FSUIPC 4.939 registered .NET verification tool ran and confirms no issues with 2.0 up until 4.5.2 .NET repair tool run SFC /SCANNOW run with no integrity violations System: i5 3570 @ 4.7GHz 16GB DDR3 RAM 128GB SSD 4GB GTX 970 There isn't much out there about this sort of crash, so I certainly hope someone can help me, as I'm about to lose it. I moved from FSX to P3D in the hope of getting a more stable sim and it's just getting worse.

Hi guys, Recently switched from FSX to P3D. I was using DX10 in FSX and was having the d3d11.dll crashes so removed the above KB fix from Microsoft which solved the issues. My question though... now that I'm using P3D, which actually uses DX11, would it be wiser to reinstall the KB or leave it out?

I can try it with leaving the auto throttle in I suppose, but usually when I fly an approach I disconnect the auto throttle and then the autopilot (and yes, I'm aware the purists will tell me that Boeing recommend leaving the auto throttle engaged during a manual approach but I don't do it in the 737 so won't do it here!)

Thanks. If it biases it ANU then surely I would have good pitch up authority...

Hi Guys. This has been an ongoing issue for a while, I'm not sure if it's a 777ism or not! Basically during landing there is a distinct lack of pitch up authority. Example, if you get slightly above the glide and pitch down to compensate, then try to recorrect with a pitch up for the flare, even full rearward movement of the controls does little to nothing, which results in a rather... Positive landing. If I disconnect early on the approach it flies fine, all control inputs are responsive, but it's only the last fifty feet or so where I've little to no control in nose up effort. I've noticed on approaches where I'm bang on the glide all the way down it remains responsive enough to start a flare at around 50 or 40 feet for a nice touch down. So I'm wondering if a nose down correction late in the approach is affecting the ability to pitch up... Seems a bit strange. Trim issue? I'm not sure where the trim is at this stage as I haven't looked but I'm assuming it should be around 5-7 units ANU. No issues during takeoff rotation or manual flight in other stages. I seem to have made no less than four of these posts. Feel free to delete the others!

Chaps, I'm having the same crash with the same module in exactly the same place - just coming up to GORLO flying West towards Heathrow - happened twice now and both times it's referenced gdiplus.dll, which is a new one on me. Here's the message from Event Viewer: Faulting application name: fsx.exe, version: 10.0.61637.0, time stamp: 0x46fadb14 Faulting module name: gdiplus.dll, version: 6.1.7601.18455, time stamp: 0x535b14fb Exception code: 0xc0000005 Fault offset: 0x000c7e75 Faulting process id: 0x101c Faulting application start time: 0x01d010634e80bd87 Faulting application path: E:\Microsoft Flight Simulator X\fsx.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18455_none_72d576ad8665e853\gdiplus.dll Report Id: e5f179aa-7c87-11e4-995a-bc5ff436a2d8 Just done a fresh FSX install too, literally did it yesterday. Am in the middle of Googling but it's all a bit wishy washy. Anyone seen this before? After doing a bit of research on it I've made sure I've got all up to date .NET frameworks, reinstalled all the default Windows 7 fonts and rolled back my Nvidia driver to the previous (344.65).

But in my opinion, it's the loading that causes the crash! d3d9.dll will cause a crash most times when I tab out of FSX, change to windowed mode, sometimes even just quit in a normal way. If I can stop this loading then it won't cause that module to crash the program. I'm doing a flight now with Sweet FX and I haven't had it... Yet.

I know it's ENB that causes the physical crash, but what causes ENB to do it is the refresh of the screen while it's reloading whatever it's trying to reload. That's what I'm trying to stop! I just switched to Sweet FX which I like the look of, so hopefully whenever it chooses to reload something it won't actually crash anymore. Would be nice to know what the loading is all about though.

It's d3d9.dll. But that's always the faulting module when I try to ALT+ENTER out of FSX or sometimes when I quit out of it. It's the action of this loading screen that causes the d3d9.dll crash, so I'd prefer it if the load didn't happen!

Hi Guys, Had this half way across the Atlantic yesterday and just coming into Germany today, the latter occasion causing a CTD. Yesterday, about once every five minutes the screen would go black and the loading dialogue would appear at 100% for a split second, same screen that you see when initially loading a flight. This evening it happened again, then I got a fatal error. I have no idea what it's loading for a split second or what it's doing. Does anyone know? Someone said it could be the time sync feature of FSUIPC which causes the refresh, but I've had a registered copy for years and it never used to happen. Also, in the middle of a flight, if I disconnect from vPilot, then reconnect, the same short load screen appears. Something to do with traffic? No idea. Appreciate any help.

Hi Guys, Weird problem I encountered this morning. This is with the 777-2 with the 1B update and EZDok version 1.17. Preflight everything is working as it normally should be, panning around with the hat switch on the gamepad and arrow keys on the keyboard. On the taxi out though, weird things happened. The camera went absolutely crazy, it started flickering and flashing rapidly between the FO view (where I normally 'sit') and the Captain's view. Only happened when the plane was moving forward. When I stopped, it stopped. Thought it could be an anomaly with the scenery (Barbados) but was still there after liftoff. I went to the EZDok studio and did a global disable, and everything went back to normal (apart from having the rubbish FS default views). Did some experimenting to try and isolate the problem. Sat on the ground again and as soon as I put the thrust up above around 60% N2, the camera went crazy again. Back to idle thrust, and back to normal again. Seems this only happens when the plane is moving, or wants to move. Tried it with the NGX and everything was working normally there, so seems it's only happening with the 777. It only happens in the virtual cockpit view, outside everything is fine. These are the things I have tried that have NOT worked: 1) Played with endless settings in EZDok 2) Reinstalled EZdok 3) Reinstalled the 777 4) Imported Froogle's 777 EZCA profile The only thing that fixes it is to disable EZDok completely from the menu. Anyone have any ideas? Thanks EDIT: Just double checked and turns out it DOES happen with the NGX too. Chaps I'm so sorry, I've done that thing that I usually berate other people for, and that's figure out the problem right after I've posted on a forum :oops: Remembered that I updated to the latest version of Opus yesterday, and there is a tiny little checkbox to do with dynamic head movement in the Opus interface that I didn't untick :evil: Would normally just delete the post but I'll leave it here in case anyone else does the same cockup. Got to love this hobby. So much messing about when the problem is just one little mouse click away.

It did cross my mind that it might be something to do with it not knowing that it should now be in approach mode. It did it a little earlier on in the approach too with the flaps at 1 and no speed intervent, but when it got about 200 feet high it pitched down and recovered the path, whereas later in the approach it decided to go VNAV SPD. Definitely something wrong I think, when I speed intervent I always double check the FMA (as in real life) to make sure it's still in VNAV PTH. If I remember correctly the FAF on that approach is very close to the airport and should be crossed at only 900 feet, and that's where the FMC coded 3 degree glidepath starts, whereas with most NPA's I've flown the FAF is alot further out, therefore the FMC glide path starts earlier. Wonder if this confused it at all, even though all the RNAV points leading up to the FAF were coded with at or above altitudes and didn't seem to me to be too challenging to adhere to! Thanks for the tip on how to get back onto PTH without a mode change. I guess vertical speed or level change for me is a habit as I usually use them at the end of an initial approach phase to refine a glideslope capture to get a nice CDA

Thanks for the reply. I'm lucky enough to fly the 737-800 for my day job, and assuming the logic of VNAV is the same on the 777, when you have the flaps down you can speed intervent and the VNAV logic will keep it in PTH. So on the 737, if I've got flaps five and I speed intervent to 165, VNAV will still be in PTH, and it'll follow the path. Just because I've bugged 165 doesn't mean it will try to decelerate to that speed, it's still following the path and may not be able (most of the time actually) to get to 165. A very slippery plane. I don't know if the 777 is the same, but judging by the FMA, VNAV PTH was still annunciated and I was expecting it to follow the path regardless of what speed I had bugged. Annunciating VNAV PTH and just sort of floating above it then changing to VNAV SPD doesn't really make sense to me! The approach was fine other than that, speeds were fine, config sequence was fine, and I use the same stable approach criteria as the company I fly for, which were of course met

Hi Chaps, Was doing an EGLL - LLBG run this afternoon and was happy to have online ATC, and happier that they told me to expect the RNAV GNSS approach for runway 30! Have yet to do an NPA in this thing so was looking forward to it. Anyway they cleared me for the approach just before the downwind and I was at clean speed, LNAV and VNAV PTH. I cross checked all the FMC altitude and speed constraints with the charts and all were in there. I put the MDA in the MCP on the downwind, which I know I would get into trouble for on a line check but hey, no one was watching! Anyway as it was quite a short base turn (the approach is pretty much like a circle to land with prescribed tracks and RNAV points) I was flaps 15 with speed around 175 at the start of the turn, VNAV PTH, LNAV and now speed intervent with the bug at F15 manoeuvre speed of around 165. Around the turn it started only descending at around 100fpm, getting gradually above path. I let it do it just to see what would happen. At around 300 feet above path (VNAV PTH still annunciated) it kicked out of PTH and went to VNAV SPD. I intervened here as I had the bug at 165 and it would have pitched up to maintain it, getting even more above path. Quick flick into vertical speed then back to VNAV PTH fixed it and rest of the approach completed normally. My question then, why did it allow itself to get above path then change to VNAV SPD?

Hi Guys, More 777 woes for me. Both of my CDU's completely freeze pre-flight. I sit on the FO side and I tried the Captain's side too but no luck. It always happens when trying to put in the cost index. I've tried a flight from EGLL - KPHL about five times now with different starting scenarios but it never seems to get past that point. I can tell when it's about to go weird aswell because when I select the VCN8 arrival for KPHL, it doesn't say SEL next to it when I click it, unless I go to another page, then back to that one. The route executes okay and I can do the PERF INIT up until cost index, where I try to put in say 90, and it won't let me put it in. Then on the FO's CDU everything is completely frozen, and on the Captain's side I can navigate pages for a while but not make any inputs at all. Then when I try to load a different panel state from the Captain's CDU it just goes black. I've tried everything I can think of, reinstalling the entire aircraft, trying from different panel states, but it always gets stuck at this phase. The rest of FS is running perfectly and everything else in the plane remains clickable, except perhaps the most important bit of it!

Righty Ho there's been a bit of progress (not positive, but uncovering something). I tried fully updating Windows and NET frameworks but still nothing worked. I tried to remove all the ENB that I had in FSX and still the same. However, I closed down Opus and set my own weather to overcast and no visibility, and the main menu ended up looking like this: As soon as I set a friendlier weather it was fine again. So I thought that's odd, I wonder if I try with another plane the same thing will happen. So I selected the NGX with rubbish weather, and the same thing happened. In the NGX itself the effect on certain panels are not as pronounced as they are in the 777 but it's definitely the same sort of effect. So I think I can now deduce that it's actually something within the sim that's broken and not just in the 777. Like I said I tried without ENB and no change. What I'm slightly afraid of is that Shade has broken something. I'm pretty sure I backed up my original files before using the set and forget function, and I searched on what to do if you hadn't done that and I downloaded some presets from Shade which they themselves say is exactly the same as the FSX ten day cycle. I'll be someone's new best friend if they can help me isolate this issue.