Pete Dowson

The problem you have is nothing to do with any video drivers. Usually it is a SimConnect trust bug. There is a thread about this. in the FAQ subforum. The report occurs before FSUIPC is even loaded. The log you supply shows a perfectly good FSX session. I assume that was a previous one. Both Event Viewer logs show: Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3 Faulting module name: FSUIPC4.dll, version: 4.9.6.1, time stamp: 0x58933f1b Exception code: 0xc0000005 Fault offset: 0x0001f145 Now 1F145 is the ENTRY point into FSUIPC from SimConnect (the exported function called DLLStart), so it really isn't getting to run at all. There's a similar investigation into this going on for P3D users -- see the pinned thread at the top of the Forum. Please read that, and though you are using FSX, i think parallel investigation into the same startup problem is warranted. If you email me, as it says, I can supply another FSUIPC version which should give us more information. Pete

Apart from recording the version of FSUIPC, the files are identical. I don't know why you are supplying them. You haven't even made the change I suggested. I do not need the whole file. That change is all you should need. It doesn't get added by itself UNLESS you are starting from scratch with no letters allocated, in which case both lines will be added for each device with different letters for each one. You need to add the line yourself now. Pete

On disk? Are they all fragmented and spread all over? If you are using SSDs, leave well along. If not, run a good defragmenter. 10 minute freezes!!! You definitely have something really wrong there then. Nothing can take 10 minutes to load without there being a serious problem! Is is streaming over a very slow internet connection each time? Rather than just remove things willy-nilly you should have tried to do a process of elimination to see where the one culprit file was, one which is probably corrupt. Or, probably quicker, use Process Monitor (ProcMon) to log all the file accesses and see where the 10 minutes comes in. Pete

The PMDG aircraft don't suite cockpit builders at all for all these reasons. I think the iFly models have a slightly more cockpit-oriented attitude, but I like many others use external aircraft systems like Prosim, SimAvionics and Project Magenta. The flight model in the sim is then cockpit-less and relatively simple, with only the flight characteristics (and outside views of the aircraft) then being important. In the past the manufacturers of the MCP units have often supplied their own drivers, and I think they probably could do (and may already have done it) it with PMDG's assistance, but I bet they pay for this. Pete

And you'd prefer not to be able to see scenery below you? And not have the traffic from / to that airport, except that little the default would allow? The VAS usage would decrease again once past. At least it does in FSX-SE and the latter editions of P3D. Pete

Yes, I realise this in any case. It is simply their routine functioning as if it had been called by a mouse click. I was thinking that the wheel codes, supplied the same way, would do it too. Have you tried? i.e. these: #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 The thing with those though, is what increment or decrement (wheel clicks) their function assumes. With the real mouse they can be accumulated and arrive in a separate parameter. Still, it may accept them faster, if necessary. Er, Lua without FSUIPC? How? Unless they accept L:Vars (Local panel variables) then I think there's no way. Have you tried using the L:var logging facilities in FSUIPC, or the supplied Lua plug-in to check?. Modern gauges written in XML tend to use L:Vars a lot, but I think the PMDG ones may be the older style C/C++ ones, which don't so much. Pete

As I've said before, and explained in my pinned post at the top of the Forum (why are folks not reading these?), I have already started a closed test session with updates by email only. Please see the pinned thread and drop me an email. It works better that way because it all goes into a separate folder on my system and I can contain it. I'm afraid I don't really like the PM system as I cannot organise it. I used to be able to disable it, but the later Forum software won't let me do that. But I only tend to check PMs once or twice a week. Sorry. Pete

If anyone in this thread wants to help solve these problems, please see the pinned thread at the top of the Forum and send me an email. I've only got one kind volunteer so far, but also an update to FSUIPC for testing. but I am not posting links here as I want to retain control for now. Pete

If this occurred after an update to a recent FSUIPC version, then it will be because a bug in the GUID checking has been corrected. In this, your JoyNames section: [JoyNames] AutoAssignLetters=No R=Mad Catz Pro Flight Rudder Pedals R.GUID={68A93020-D4E0-11E6-8002-444553540000} S=Saitek Pro Flight X-55 Rhino Stick S.GUID={68B56520-D4E0-11E6-800A-444553540000} T=Saitek Pro Flight X-55 Rhino Throttle T.GUID={68B2A600-D4E0-11E6-8008-444553540000} T=Saitek Pro Flight X-55 Rhino Throttle T.GUID={68B60160-D4E0-11E6-800D-444553540000} 0=Mad Catz Pro Flight Rudder Pedals 0.GUID={68A93020-D4E0-11E6-8002-444553540000} 1=Saitek Pro Flight X-55 Rhino Stick 1.GUID={68B56520-D4E0-11E6-800A-444553540000} 3=Saitek Pro Flight X-55 Rhino Throttle 3.GUID={68B2A600-D4E0-11E6-8008-444553540000} 4=Saitek Pro Flight X-55 Rhino Throttle 4.GUID={68B60160-D4E0-11E6-800D-444553540000} I don't know how you got two throttles registered with different GUIDs -- update to Windows perhaps? Before I corrected the GUID checking you were just lucky that the right device was selected. Try changing the second "T" pair to be "U" instead of T. Then see whether you get T or U showing in the Axis assignments tab. If T then delete the U and 4 lines. If U then delete the T and 3 lines and change the two U's to T's. Pete

If it is asking you whether to run it or not then it isn't the same problem. You need to let it run. It's a timing problem in SimConnect "trust" code which has been there in all versions of FSX and FSX-SE. There's a thread about it in the FAQ subforum above. Once it goes through once without a problem reported then it works forever after. Most folks never get this problem at all, but in the worst cases it seems to occur on every new FSUIPC update. Pete

Yes, this is occurring AFTER FSUIPC has closed normally hence: Please see the pinned thread at the top of the forum. I cannot reproduce the problem here and neither can my colleague Thomas, so we need volunteer testers to try things. STOP PRESS: I just realised: you are using FSX. This is the very first report of this error with FSX! Up to now it looked specifically P3D version 3, so we've only been looking in areas which are different for P3D! This makes it of wider scope! Not sure to be pleased or horrified at this. Pete

Just enter "Event Viewer" into the Windows Start / Run edit box and press return. Pete

Ah, you never said that before. You have a direct assignment to FSUIPC's tiller somewhere! Find it in the INI file and delete it. Pete

Yes, a lot of folks has said that mouse clicks on some more sophisticated add-on aircraft appear to be rather slow in activation. By reports I've seen I think it is with P3D this is so rather than FSX, though it probably applies to both. Sending what are effectively mouse clicks you are emulating the user with a real mouse, so you need to insert delays to bring it down to human times. Have you tried using the facility to hold the button down for a time? You'd either have to measure the time for a certain larger increment, or read back the value and rorrect overshoots afterwards. Or measure the overshoot and correct with a shorter time. Since PMDG have not provided any way off writing values directly, as you could with default aircraft, I don't know of any other ways really. Not holding the button down? Have you tried using the mousewheel? I thought I saw a Mouse code for that. The Lua plug-in Mouse library provides for wheel turning, but you'd probably need to move the mouse to the right position first, rather than just end the PMDG control with a mouse code. You could try posting on the PMDG forum too -- they'll all be PMDG users there! Pete

You misunderstood. It's the check INSIDE FSUIPC which was corrected. The FSUIPC settings won't need to have changed! Well it doesn't seem to deter others! You can use the <> button above to place the text into a frame with scroll bars where applicable. In the INI file you attached, the [JoyNames] section contains this: [JoyNames] AutoAssignLetters=Yes A=Logitech Extreme 3D 0=Logitech Extreme 3D 0.GUID={8CB99BC0-67B3-11E6-8001-444553540000} Is that your only device? No yoke or throttle or anything? That device does it all? Anyway, I think the problem is that the GUID for device A is missing. You need the section to read: [JoyNames] AutoAssignLetters=Yes A=Logitech Extreme 3D A.GUID={8CB99BC0-67B3-11E6-8001-444553540000} 0=Logitech Extreme 3D 0.GUID={8CB99BC0-67B3-11E6-8001-444553540000} Try that and let me know. There are NO other chanes in FSUIPC which would affect your device's actions, only the GUID check. Pete

It may be that the GUIDs associated with your devices are wrong. I recently fixed an error in FSUIPC whereby the GUIDs were not being correctly used to identify devices, as they should always have been. If there are some old incorrect entries in the [JoyNames] section of your settings, the FSUIPC4.INI file, then it may be that the current correct GUIDs are now associated with old joystick letters or numbers, so your assignments are ineffective because they are expective a non-existent device. I'm not sure what changes the GUIDs -- probably a Windows update -- a change of Windows version -- or of PC. And that could have been any time since you had those devices and started using FSUIPC for assignments. It should be easy to fix, and I'll show you if you show me your FSUIPC4.INI file. Pete

4.957c!? Well,, yes, I'm definitely thinking I'm not going to fix this by FSUIPC changes only. This is with P3D 3.4.xx? Because so far that's the only (other) common factor. Please see my pinned post at the top of the Forum. Pete

Understood, and please see email. Pete

Check with default aircraft. And check your FSUIPC version number. Pete

Hmm. You say it might be FSDT others say it's PMDG 747, I expect others will say they have neither. The only common factor is P3D 3.4 -- and, mostly, Win 10, though that's only from what i've seen reported. Oh, and FSUIPC. Pete

This gets weirder and weirder. The ONLY change was moving the memory check to its own thread. What if you disable the memory checker again? Can you always check the event viewer to see if P3D crashed on exit from the previous session, and also if FSUIPC's log shows a proper close? Pete

This is EXACTLY the same problem with recent versions of P3D 3.4 that is reported as discussed in this and other threads. Please go and read the pinned thread at the top of the Forum. Pete

You are using an out of date reference. The current document for offsets is in your FSUIPC Documents folder, inside the FSX Modules folder, along with the other FSUIPC Documentation. Offset 3308 is a 2-byte value, not 4-bye as you are reading. The "FADE" part is another documented value, if you go look. 2 byte values are probably not called "Integers" in VB. You need to learn VB before you write a VB program! Pete

Just to clarify something about the P3D startup crash which is the main thing which folks are concerned with. Some folks are saying it was all okay in version 4.959 and want to go back o that. but if you refer to the thread referenced at the end of this message (and others) you'll see, especially if you skip the first few messages which were different, that it was 4.959 which had the strt-up problems with P3D. It's a long thread with a long list of test releases going from 4.959a to 4.959m. The "m" version seemed to fix it for folks then, and it wasn't long ago. A couple of fixes to prevent LINDA crashing (due to a bug in LINDA now fixed i understand, to version 4.959p, it was relabelled 4.960 and released. The change between 4.960 and 4.961 was a minor one, to put the OOMcheck into its own thread to prevent a small stutter every 10 seconds when Windows was asked to tot up the memory blocks. It was also announced to support P3D3.4.22 which was released the same day, though in fact 4.960 already was 3.4.22 ready. So, i cannot revert back to 4.959 level as it will re-introduce the problems which have been fixed with a lot of blood sweat and toil. Well, maybe not blood. The only conclusion we can reach is that there's more than one cause for the P3D startup problems. I am pretty sure it only occurs if the preceding otherwise good session crashed on exit, or even hung as some have reported, Identifying what might cause that is the focus of my work on this. it isn't easy because it isn't crashing or hanging withing FSUIPC. As the log shows, FSUIPC is long finished and gone -- unloaded even. So if FSUIPC is causing it, it must be something it did whllst it was still there, even though nothing went wrong during that time. With the original problems it seemed mostly relating to the way Lua plug-ins were terminating or being killed, so most attention was focussed on that area and I now believe that's a good as it's going to get. So it's somewhere else. Since I can't reproduce the problem, and nor can Thomas, I'd like volunteer user testers please, to try experiments and gather information on the resluts. Those willing and able to help and who can definitely reproduce the problem (crash or hand on exit, mainly. There's no way for us, outside L-M, to debug the crash on start). please drop me an email: petedowson@btconnect.com. Pete

Just to clarify something about the P3D startup crash which is the main thing which folks are concerned with. Some folks are saying it was all okay in version 4.959 and want to go back o that. but if you refer to this thread http://forum.simflight.com/topic/82599-crash-loading-p3dvhttpforumsimflightcomtopic82599-crash-loading-p3dv34-reporte-fsuipc4dll34-reporte-fsuipc4dll/ you'll see, especially if you skip the first few messages which were different, that it was 4.959 which had the strt-up problems with P3D. It's a long thread with a long list of test releases going from 4.959a to 4.959m. The "m" version seemed to fix it for folks then, and it wasn't long ago. A couple of fixes to prevent LINDA crashing (due to a bug in LINDA now fixed i understand, to version 4.959p, it was relabelled 4.960 and released. The change between 4.960 and 4.961 was a minor one, to put the OOMcheck into its own thread to prevent a small stutter every 10 seconds when Windows was asked to tot up the memory blocks. It was also announced to support P3D3.4.22 which was released the same day, though in fact 4.960 already was 3.4.22 ready. So, i cannot revert back to 4.959 level as it will re-introduce the problems which have been fixed with a lot of blood sweat and toil. Well, maybe not blood. The only conclusion we can reach is that there's more than one cause for the P3D startup problems. I am pretty sure it only occurs if the preceding otherwise good session crashed on exit, or even hung as some have reported, Identifying what might cause that is the focus of my work on this. it isn't easy because it isn't crashing or hanging withing FSUIPC. As the log shows, FSUIPC is long finished and gone -- unloaded even. So if FSUIPC is causing it, it must be something it did whllst it was still there, even though nothing went wrong during that time. With the original problems it seemed mostly relating to the way Lua plug-ins were terminating or being killed, so most attention was focussed on that area and I now believe that's a good as it's going to get. So it's somewhere else. Since I can't reproduce the problem, and nor can Thomas, I'd like volunteer user testers please, to try experiments and gather information on the resluts. Those willing and able to help and who can definitely reproduce the problem (crash or hand on exit, mainly. There's no way for us, outside L-M, to debug the crash on start). please drop me an email: petedowson@btconnect.com. I'll post this as new new pinned thread too. Pete