Pete Dowson

No. There's nothing peculiar or special in the Buttons menu, especially if there are no buttons defined already. Can you tell me if you have GoFlight devices? Could it be a bad GFDev.dll file somewhere? Just in case, try installing the copy of GFDev.dll you can find in the download announcment above into the FSX modules folder. Otherwise, do you have an EPIC? Regards Pete

Goodbut what a palavah! Thanks for explaining how. Regards Pete

Maybe. If so it would be FSUIPC4.DLL, but as it isn't a separate process (it actually runs inside FSX) I don't understand how you could list it. I actually think the whole business of one bit of FSX sending another bit messages via Internet Protocols which are then subject to all this stuff is a mistake, and I hope MS do something about it very soon. No, as others have reported before in other threads both here and elsewhere. I think those who solved it uninstalled it and tried some other protection, like AVG file the virus checking and WinXPs own firewall. Maybe an uninstall and a very careful reinstall might do it. It is all really outside of anything in my experience. I use Norton A/V and WinXP's firewall and have never had any of these problems. Sorry I cannot be any more explicit about solutions -- in the end it is Microsoft who needs to deal with this. Regards Pete

You are entering something wrong. Don't only paste the registration code, paste your name and your email from the same receipt -- all three parts must be identical to those you used to get the code. It's amazing how many different ways folks have of spelling their names -- in this case a different spelling means a different registration. Regards Pete

Okay. The log files show several things. First, whilst MyFSTools does use FSUIPC, FSPilot does not. It is not a conflict within, or even to do with FSUIPC at all. Second, then FSPilot is running is is actually preventing MyFSTools getting access to FSUIPC altogether -- in the log where both are installed there is no sign whatsoever of MyFSTools. I have no idea why this might be -- it looks like FSPilot is doing something rather unfriendly, but I have no idea what that might be. I cannot possibly diagnose it because FSUIPC never sees any sign of MyFSTools. Maybe you could try getting it loaded earlier. I see at present that you have two other FS DLLs loading, both of which also use FSUIPC and neither of which are affected by FSPilot: SB3GAUGEBRIDGE.DLL and PMDGOPTIONS.DLL. I'm not sure what controls the order of DLL loading by FS, but you could try renaming MyFSTools.DLL as "AMyFSTools.DLL" to see if having it earlier in the alphabet helps. The problem might be due to the method used by MyFSTools for connecting to FSUIPC. With version 3.71 I cannot tell what method it uses, as I removed the access checking, but if you have a previous version you could try it with the same logging, so I can see the access method. If MyFSTools uses the EXTERNAL method for connecting to FSUIPC (which has been wrong for many years!), then it would explain more easily how this problem could be caused by FSPilot, and if that is the case it would need a change by the authors of MyFSTools. If you don't have an FSUIPC version 3.709 or earlier let me know and I'll email one, just for this test. Regards Pete

FSX flight plans are in a completely new XML format. Has Enrico published a revised version of his software to handle XML plans? I just checked. Build 80 of the pmRJ (18th November) supports FSX XML flight plans, according to the release notes. So does the latest Boeing CDU build, so I shall be able to try it here when I get a moment! :-) Regards Pete

In that case it most definitely sounds like a firewall or security problem and is really the same as all the other "no add-ons menu" reports here and elsewhere. Yes, the firewall problems don't stop Simconnect loading the DLLs or EXEs, but the necessary interaction thereafter doesn't occur. If you check the FSUIPC4.LOG file you will either find that the SimConnect_Open returned a failure (0x80004005 seems the common error return), or that the Open succeeded by then nothing else happened. If you try FSUIPC4 version 4.052 (available in the FSX downloads announcement above), it will actually retry the connection again and again until it succeeds (unlikely) or you terminate FSX. These attempts will be logged too. It is most likely to be a block caused by a firewall or security setting. If you refer to the announcement above about Firewalls, it will lead you to an announcement and suggestion from Microsoft about this. Please note that the READ ME document I place inside each and every ZIP for FSUIPC4 does tell you about these problems too. Maybe you missed that? It is only a single page, or maybe tow now, basic text document. We are all finding this situation most frustrating and hope that Microsoft are doing something more proactive about it, to prevent the problems occurring, rather than only advising folks to disable or uninstall their security software as now. Regards Pete

FSX flight plans are in a completely new XML format. Has Enrico published a revised version of his software to handle XML plans? This is 100% a question for PM support by the way. I really cannot answer for PM. Regards Pete

Sorry, are you saying that before you installed FSUIPC 4.05 you did get an Add-Ons menu? If so, what was in it, please? How many other Simconnect client programs are you running, and what are they? But if FSUIPC4 was "wel loaded" and running okay, there would be an Add-Ons menu and it would have FSUIPC in it. Can you clarify please? You are not alone, but at present the answer still appears to be EITHER some sort of broken Simconnect installation OR a firewall problem. Please do double check that there is no firewall blocking the use of SimConnect client programs. I have also heard that merely re-installing SimConnect from its MSI file, or, indeed, the whole of FSX, doesn't always repair a broken installation. There has been advice given that you first need to find and delete the folder of the original Simconnect installation. Search in your Windows folder for Simconnect.dll. It will be in a folder with a horrible long and complicated name including "WinSxS". Only the DLL will be there. Delete the folder along with the DLL, then try re-installing from the MSI file. I don't know if this works, as I haven't yet heard back from others about this. Regards Pete

Hmmmthat is rather strange. Can you enable IPC read and IPC write Logging (see the Logging options), then close FS, restart so as to run that test again, then Close FS (very important), ZIP up the FSUIPC.Log file and send it to me at petedowson@btconnect.com (or show it here if it is short enough). Regards Pete

Glad you found it. What does it actually do? I guess it hooks into stuff on the Network? I wonder why it affected an outgoing connection (WideClient connects TO WideServer) but not incoming ones, like when you tried the Server on that PC? Regards Pete

Er, I still there's a lot of confusion in what you are talking about. There's no file I know of by the name PFC DDL. There is a DRIVER written by me, called PFC.DLL. In other words, the PFC driver for FS9 IS "PFC.DLL". I don't know any "DDL", and, yes, the PFC.DLL goes into the Modules folder in FS9. There's really nothing new for you to look forward to. The version 2.00 PFC.DLL will not be much different from the 1.999b available in the "Other Downloads" announcement above, except that there will be joint and slightly updated FSX + FS9 version documentation, and some minor improvements in both versions for pmSystems when using the PFC 737NG cockpit. Oh, and the FSX version (4.00) will turn off the Avionics displays when FSX is closed, which currently is a problem. Regards Pete

I have no control over their site. Version 1.0 must have been many years ago, obviously well before the C2 in any case. I assume they just put it up there when I first wrote it and forgot clean about it. The latest "official" version is always on www/schiratti.com/dowson, but I tend to provide updates here too, in the Announcements above. Unless it specifically says its for Beta testing, the ones here will be best, always. At present the only reason the one here isn't "official" is that I've not yet updated the documentation -- so you still need the official ZIP for the Dox. Please, do peruse the announcements above, they do tell you these things. Always the latest here, but with Dox from the Schiratti site. The only time that may not be so is when either (a) there isn't a later one here, or (b) the later one here explicitly says for testing this that or the other and you don't have any of that. I am in the process of tidying some things up both for PFC.DLL and PFCFSX.DLL and then they will both be released as versions 2.00 and 4.00 respectively. That will be on the Schiratti site, but announcements here will say too. ALWAYS install new versions. It's only the DLL itself you change in any case. The INI file contains your settings, you don't need to delete or change that unless you want to start again! I don't know what you mean "has a driver in there"? The PFC.DLL is the FS9-and-before driver for PFC serially connected devices. Simply copy new versions into the Modules folder. You won't wear anything out!!? Regards Pete

I think you misunderstood me there. You need to do "fine tuning" on your calibrations -- a larger null zone is needed to stop the constant jitter seem on all three axes (rudder and both brakes). The central "null zone" for the rudder is determined by the central two numbers in the calibration -- you need to move the pedals slightly one side and the other of centre to set two separate values there, far enough apart so jitter is eliminated. Similarly depress the brakes slightly before setting the brakes off position. Usually it's a good idea to depress them quite a way to avoid accidental application. My adjustment in FSUIPC is merely to avoid sending Events to SimConnect before those Event numbers have been established. It doesn't affect anything except the logging of spurious errors in the Log. I'm testing changes to FSUIPC4 now to try to recover from an erroneous SimConnect disconnection, but whilst it suffers from such weird errors there'll be some problems. I will try to recover exactly where it left off, after 5 seconds or so of non-communication, but data like the whereabouts of all the AI may be wrong for a while after that. Regards Pete

You sent me some good logs illustrating the problem with the disappearing menu (and FSUIPC4 operations thereby stopping). You said: I don't think I need any more logs, thank you. Those illustrate it well enough. In the SimConnect log, which is mostly full of GoFlight stuff initially, then a reasonable mixture of GF and FSUIPC4 traffic (the lines with #62 are GF, #63 FSUIPC4), the thing that killed the FSUIPC4 connection occurs in the 1215th second: 1215.99501 [63] I/O Error! How the hell SimConnect can experience an I/O error when everything is happening in the one machine with no actual I/O involved I've no idea, but it evidently can and it appears it have no recovery built in as it never again talks to FSUIPC4. I am wondering if it is something simple like running out of TCP/IP buffers of somethnig stupid like that. I am really hating the methods Simconnect uses more and more with each passing day! There's not a lot I can do except to detect a number of seconds with no Events arriving and re-initialise the Simconnect link. That would be my 'recovery'. I'll put that into the next Interim FSUIPC4 version, which I'll be posting in the Announcement above within the next day or two. Please try it and let me know. There's also one interesting result I can see in the log which needs a little adjustment from me. You appear to have jittery Rudder pedals/brakes, and FSUIPC4 is sending loads of rudder events to SimConnect. It starts doing this quite early, and in fact BEFORE those events are registered with SimConnect. This is a result of my delayed Simconnect initialisation (to avoid FSX crashes when two clients try to initialise Simconnect together). That results in these errors initially: > 39.32469 [63, 30]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-8192, GroupID=2, Flags=0 < 39.32474 [63] >>>>> EXCEPTION=1, SendID=30, Index=2 <<<<< > 39.32507 [63, 31]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-8356, GroupID=2, Flags=0 < 39.32510 [63] >>>>> EXCEPTION=1, SendID=31, Index=2 <<<<< > 39.32657 [63, 32]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=256, GroupID=2, Flags=0 < 39.32661 [63] >>>>> EXCEPTION=1, SendID=32, Index=2 <<<<< 66387 and 66388 are left and right toe brakes, 65764 is the rudder. If you aren't shuffling you feet on those whilst FS is loading up then it seems they aren't calibrated well with a decent centre "null zone" to avoid jitter. Anyway, I'll tidy up FSUIPC4 so it doesn't send these events on until it knows they've been registered. Thatt'll be in the interim version too. I'll send the details of this "I/O Error" directly to my MS contacts. Perhaps you could make a detailed report, including the Simconnect log (the other logs won't be of interest to them) and send it to tell_fs@microsoft.com too, please. Regards Pete

Are you now using FSUIPC 3.71 on both computers? If not why not? Nevertheless the problem is in MyFSTools, and you need to contact the supplier/author to find out what the above message means. It makes no sense to me -- it presumably means something to the author! If the "2" is the error number returned by FSUIPC_Open, then this means "Cannot link to FSUIPC or WideClient", which is simply a failure to get the SendMessageTimeout through to FS for FSUIPC to see. It probably simply means that Windows is so busy swapping processes or threads between FS and FSPilot that the messages from MyFSTools are timing out. Most programs try many times before giving up. Maybe MyFSTools has no or few retries built in, and FSPilot is very greedy in its dealings with FS. I'm afraid your recourse still lies with the author(s). Regards Pete

Something is bad in the drivers or network hardware on that Client. There a no loops or places in WideClient which can use all that processor time -- it is getting stuck deeper down, inside the drivers somewhere. All WideFS operations are aynchronous, based on reacting to Windows messages sent when data is ready to be read or the line is ready to accept data to be written. One possibility is interrupts clashing. This is usually sorted out well by Windows XP, but it used to be a big problem on Win98 and so on. You don't say what operating system you are using, but that is somethnig to check. If the Network hardware on that Client is on a PCI card then moving the card to a different socket might help. Otherwise all I can suggest is uninstalling the Network hardware and letting Windows find it again so it re-installs the drivers. If you continue to make no headway, you can set "Log=DebugAll" in the Client's INI file, and this will put everything that the Client is doing into the Log (it may get very large), but based on past experience of this sort of problem I suspect it will only indicate that same as above. If you do produce a large log, ZIP it up and send it to me at petedowson@btconnect.com. Regards Pete

I don't know FS Commander, but isn't it some sort of moving map and so on? How do you use that with FS in full screen mode on the same PC? From the little I've heard, I would have thought FS Commander was more suited to running on a networked PC using WideFS? The original FS9 release used to do that, but I think most of the bugs that caused it were fixed in the FS9.1 update. Are you using the original version? Otherwise such crashes tend to be related to video driver problems. Try different drivers, or different settings in the drivers and/or FS9. All on the one PC? I know it is quite a powerful one, but still ... Run-time error 5 sounds like a Visual Basic type of error message -- which program gave that? Surely not FS. Isn't FS Autostart the program which automatically stops a number of "inessential" processes for you before launching FS? Do you think it may be stopping something it really shouldn't in this case? I'd try a process of elimination on that if I were you. Regards Pete

Thanks for the logs. The main problem seems to be another Add-On you have, "bglmanx.dll", which adds a "Addon Manager X" entry to the menu. It seems to clobber SimConnect good and proper. Try renaming that (it looks like it is in your main FSX folder). If everything then works okay then you have another case of the symptoms caused by having more than one SimConnect client. Also, it looks like that bglmanx.dll is keeping SimConnect constantly occupied with very repetitive action, very frequently asking it the very same question. FSUIPC4 is not getting anything from SimConnect at all and in fact is unable to proceed. It looks like it never gets any acknowledgement of its requests, let alone a log of them. Please forward this stuff to Microsoft with your own descriptions of the problems, and the AVG stuff. send to tell_fs@microsoft.com, and be sure to include the word "SimConnect" in the title. Don't expect a reply. Meanwhile, please also contact whoever supplied "bglmanx.dll" (which I've not heard of at all) and show them the larger SimConnect log, because it certainly looks pretty bad. The only other advice I would give at present it to completely uninstall AVG, for now at least, to see if that alleviates the problem. even with these things apparently disabled, their hooks are still there, and this looks to be a problem with SimConnect at present. Regards Pete

Hi Andrew, Thank you for the logs. Unfortunately these are both contination logs, so they don't show me a lot of the information which may have been useful, like the aircraft concerned. It is writting the elevator value okay. It looks like it expects the read-back to be the same as what is written, which it isn't in FSX. I'm not sure WHY it isn't, though. However I'm equally not sure why that program treats it as some sort of error -- you'd need to take that up with them. What aircraft are you using for this Fly-by-Wire? Not the FSX A321 I hope? Because if you are that probably explains it -- for the first time MSFS have implemented Fly-by-Wire. You can't have your inputs passing through two FBW processes. You'd need to turn off one of them. You may be able to turn off FSX's FBW. If not in the cockpit, in the Aircraft.cFG file. Regards Pete

and did you ever read the "User Guide" at all? Right on the first page it says: Sorry that it is actually called "FSUIPC4 for Advanced Users", but I think is close enough to be recognisable!? It is very saddening. One day perhaps folks will actually read what I write, or even have a look to see, do you think? :-( Regards Pete

Yes, you must have done it wrong, somehow, as I have just tried it and it works fine --- as long as the ATC window isn't open. Do they? They don't here, at least not when the ATC window is open! Anyway, I've tried all sorts of things. Amazingly MANY of the key functions change when the ATC window is open. It seems to be capturing many of them and passing them off using its own equivalence table. FSUIPC is unable to get above this as the ATC window is receiving the keys first. This is really quite a big bug and you should certainly be reporting it as such! Sorry I can't find any way to help -- the only thing you could for now do is get a mouse or cheap joystick. Regards Pete

Seems as though they meessed things up then. I have a record or an "MyFsTools.dll" being issued with an access key on 2nd April 2005. That will apply to all version 3.xxx of FSUIPC -- except 3.71 for which no access keys are required in any case. I fail to understand why you insist on keeping to FSUIPC 3.65 on the PC on which you have this problem. If you don't want to update it, you don't get support from me in any case, and you need to talk to MyFsTools folks. Pete

Erplease hold on a moment then. Are you saying you ARE using multiplayer, and the problems occur after you've enabled multiplayer? If you are saying this, then, as I said, this is a known SimConnect bug, reproduced by Microsoft, and there is a work-around implemented in FSUIPC4. Download version 4.05, the current version. If you are NOT actually saying that you are using multiplayer when the problem occurs, or not before that in the same session at all, then, yes, please go ahead and get some logs. The same applies of course if the work-around in 4.05 doesn't fix it. Regards Pete

Not heard of "MyFSTools". Sounds interesting. Is there any reason you didn't update to 3.71? And what does that mean? Do you have any "MyFSTools" documentation to explain it? Have you asked them? I've no idea, since I've never heard of it. Sorry. If it doesn't work and it needs FSUIPC and you haven't registered it as a user, then that is probably the reason, but you need to ask the suppliers of MyFSTools. Pete