Pete Dowson

That's an interesting find. 4.949f should crash P3D 3.4 with HotFix2. Are you using Hot Fix 2? 4.949f is not compatible with it -- at least one link is wrong. Can you show me your FSUIPC4.LOG please? Pete

I don't know of any away. Maybe there is, but I've never used multiplayer on on-line connections (except for weather). Sorry. Maybe one of the multiplayer or VA sites can help? Pete

An unregistered version acts in its original purpose, ever since FS98. It provides an interface to application programs needing data out of and control into FS. There are no user facilities without registration, except logging the data programs can read and write. Why not try reading the User Guide as a start? It is installed foor you, in the folder FSUIPC Documents. All this is explained also in the Installation guide which is included in the ZIP itself. Did you completely ignore that? Yes, as it says in the User Guide. The user facilities are for Registered Users. If a bluetooth device is installed with a driver which emulates a COM port, then, yes, it is going to be possible. But for more details you need to read the documentation. Also, depending on your device you might find help in the User Contributions subforum above. Documentation is provided to assist in understanding software. That's its purpose. Pete

Well that log shows a successful run to a normal close. The Windows event seems to take place before you started FSX: See the log entry less than half a second after FSX started: 453 System time = 06/01/2017 09:12:24 You have a lot being run there. Make sure you have them all updated to current versions. The Windows event viewer unfortunately doesn't identify the specific component at fault in the crash which occurred before you started that run of FSX, but I've usually found "Stackhash" crashes to be down to drivers. Maybe the video driver if not the SAitek software? Pete

Sorry, I thought you said it minimised to the task bar. That means it reduces to an icon in the task bar which should certainly be clickable. So you really mean is closed completely except for some hung thread. It would be good to identify that thread. You'd need something like Process Explorer for that I think. Is that with the very latest Addon Manager, released this week? Well, yes to the former (though it may be devices or drivers rather than files per se) but I don't know what files "touched" by the FSUIPC Installer could affect anything. It's only the timestamp on he DLL.XML as I said. Maybe the Addon Manager checks that and does something different when it changes. It might be worth asking Virtuali about that. Pete

Well, yes, the timestamp on the DLL.XML file will be different. But that's all. Nothing else at all will be different. The timestamp on the DLL is set by the installer and is related to creation time here on my system. You mean the "crash" which is actually a "minimise" action? Won't it restore if you click it? Those points need reporting to L-M please. I've not heard of any "minimise" problem before. The 100% core utilisation sounds very odd indeed, and the DXDiag does seem related to devices -- back to LINDA I suppose. Maybe a process of elimination on what LINDA is doing would be useful? I know L-M were making quite a lot of changes to the way they were handling devices, even with choices between DirectX use and the older style device driving. Pete

If it goes to the task bar it simply means that something else has stolen the focus. There are lots of addons which can do that. It is still running! All you would need to do is click it on the task bar to return the focus and it would re-open its screen! Pete

There have been two distinct possible solutions now found, but perhaps not yet proven. The first appears to be to do with LINDA, as described in the messages above. The second has been posted by gypsyczar obver in the L-M forum, as follows: I just did a reinstall of GSX using the 1/4/17 version (download from the FSDT website). I have now restarted P3D multiple times without a crash both with a reboot before restart or restarting without a reboot. The reinstall of GSX was the only change made from the configuration that resulted in the repetitive P3D CTDs. Anyone else having this problem may want to try a GSX reinstall I added my own observation to this: Odd that I'm using GSX without that update (I have one from mid-December I think). The AddonManager install puts the COUATL.EXE into the EXE.XML, and the BGLMANX.DLL into the DLL.XML files, both on the ProgramData folder I think. I expect this would be the same, then, for any DreamFleet install. Can others here confirm or deny either of these? Pete

I could understand this better if LINDA was changing the state of some hardware or driver and this was causing the crash on the next load, but then you would get a crash on the second and sunsequent load in any case, whether you ran the Installer or not. After all, the Installer is actually changing nothing at all. Ah, so could the apparently successful sessions actually be crashing on exit without you noticing? Can you check the Event Viewer logs in Windows to see? On a successful run, is the FSUIPC log file complete with the end summaries? Well other folks have tested this and proved there's no change to that file before and after. They are character-for-character identical! I don't know what else the Installer could be doing to "reset" anything. Incidentally, ever since FS2002 days I have always started each new flight with a clean PC re-boot. It doesn't take long and you are then assured of exactly the same start conditions. I most especially don't trust any Windows based system after any crash. Try a re-boot instead of an FSUIPC reinstall. Pete

Interesting findings. Thanks. Pete

It clearly says there are 64 bytes -- that's 64 x 8-bit values (BYTE ot Character), 32 x 16 bit ones (WORD), 16 x 32 bit ones (DWORD or FLT32) or 8 x 64 bit ones (double or FLT64). So how many are useful to you depends on how you use them. For things like switches, on/off, you could put 8 in each byte or use one byte for each, but only values 0 and 1. If there are all floating point numbers you'd need 32 or 64 bits each, so less different values. I missed this question in my last reply: You use one or more events, which keep the plug-in running but idle just waiting for one of those events (a change in the value). You get the plug-in running by using an [Auto] section entry in the INI file -- either a generic [Auto] section to run it always or a Profile specific one [Auto.profile name] to have it running only for specific aircraft. And no, since the plug-in only runs when something changes, there's no overloading. Pete

That's what it would look like after a reinstall also, so the reinstall is making no change whatsoever. Pete

Sorry, you seem to have omitted something here. Is "what" the "fix"? Why would P3D minimise? Many users other than myself also have no problems at all. Some process of elimination is needed to see what is common between those who do have the problem. so far I only seem to have got one user to cooperate with going through a process of elimination to see which add-on is causing the DLL loading problem. Pete (Not sure where that orange bar comes from, but I can't delete it!)

I need to see the Windows crash details. Use the Windows Event Viewer to retrieve them. This will also show what module is responsible. If it is only happening since you installed the Saitek throttle, it is more likely to be a problem witth its driver. Is that from a session which crashed? Why are you logging Events and IPC reads and writes, making the log so big? What software are you running as well? In particular, what add-on is doing all those read and write actions? Please never turn on extra logging options without me asking you to or suggesting it to get specific information. According to this: you seem to have enabled pretty much all the logging options. This just produces unnecessarily large logs and confuses matters. Was the portion of the log you deleted all just READ and WRITE lines? Because there are other crucial initialisation lines which should appear, right near the beginning. You've shown only 25 seconds worth before the 273 second deleted part. The next initialisation line to appear should probably be the one giving the Aircraft name ("Aircraft= ..."). Please switch the logging options off and supply a normal default log, plus the Windows crash details and a list of add-ons apart from FSUIPC. Then I might have a chance of telling you what is wrong. Pete

It cannot recover memory which still appears to be allocated. A defrag would only be a joining up of the known free blocks. Allocated memory must be freed so that the system knows the pointer is now unused. [LATER] On researching the idea of memory defraging, I find that things have changed a lot since the early days of Windows when I thought I understood it Windows 3, probably! ;-) ). Since Vista all Windows versions appear to allocate in pages of 16kb anyway, and attempt to do so in a way that had previously to be opted as "Low Fragementation Heap". The only vaguely useful function appears to be HeapCompact Coalesces adjacent free blocks of memory on a heap. but this assumes the process has only one heap, and wouldn't deal with real fragmentation, only contiguous free backs. I suspect the system would do that automatically when needed in any case. The code I'm using to determine the largest free block does not check for continuity with other free blaocks, so it may be showing a more pessimistic value that I thought. Multithreaded programs like P3D are likely to have more than one heap. Pete

Why not refer to the Offsets Status document installed in your FSUIPC Documents folder? That is what it is for! Just search on the word "Free". It includes 66C0. Documentation is provided for you to use. Much more efficient than posting here, surely? Because that is the only way to get the information. The PMDG implementation simply provides a data block to be read. No, I cannot possibly support every aircraft out there and most certainly not those which don't provide data in a mappable form. Pete

Assigning is only part of it. you have to calibrate then as well. You've evidently not calibrated properly then, if at all. Again, that sounds like bad or no calibration. Looking at your INI, for default calibrations you only have Throttle2=0,0,512,16383/48 which is no reverse zone and standard range 0-16383., with a axis reversed. You have no other calibrated axis at all for anything other than you FA18 profile where you have Throttle1=-16383,-16383,-16383,-16383/32 A throttle with a range -16383 to -16383 (ie no range at all), no reverse Throttle2=0,0,0,0/32 A throttle with a range 0 to 0, again no range at all. Also no reverse. Plus these with default calibrations: Rudder=-16380,-512,512,16380LeftBrake=0,16383RightBrake=0,16383 I suggest you find the FSUIPC User Guide, in your FSUIPC Dcoumentas folder, and follow the numbered steps for calibration given in the Calibration Chapter! Pete

Only if TeamSpeak uses the Windows "hotkey" facility to get a keypress no matter how it is pressed. I think there are many folks who programmed PTT on a button for TeamSpeak. Have you searched? Check for instance the User Contributions subforum. Or is there a TeamSpeak forum? Pete

Interesting to see FSUIPC4 loading before PMDG_HUD. That was one of the problem DLLs others have isolated -- that and RAASPRO.DLL. But I am loading RAASPRO (though I had to go find and update). Pete

Very odd. It usually gives more problems with interaction with other modules when it is loaded early. Is the only thing after it the PMDG HUD? Not sure if your ".." means you omitted other entries. Pete

Can you all check that you don't also have FSUIPC4 being loaded by the DLL.XML in the ProgramData folder! This has been reported once already, and removing it has fixed it --- so far. If so we need to identify what it putting it there, as FSUIPC's installer certainly doesn't! Pete

Does it still fail if you stop LINDA loading? Pete

Are you all using LINDA? There have been reports of problems with LINDA, reported elsewhere. There's a workaround I think..... I'll see if I can find the details.. [LATER] Ah, no. It was different -- to do with closing problem (http://forum.simflight.com/topic/82312-timeforluaclosing/#comment-496245) Pete

Sorry, I don't see the point of a video. Are you assuming I don't believe you? I prefer proper descriptions and readable data. Pete

I've added another value, in offset 0290, giving the maximum contiguous memory black size, in the same units as the current 024C. I've not tested it enough to know whether it indices any new stutters, so I'd like it tested by anyone interested. Just download FSUIPC4959bTEST.zip and copy the DLL into your modules folder. Change any logging or plug-in you are using to display VAS to use offset 0290 instead of 024C and see what you think. Any performance issues at all? Next question then is -- should this value be used for the OOM check (warning beeps) instead of the total? If so should the threshold be reduced or left the same? Pete