Pete Dowson

Only arithmetically from the aircraft heading and the relative bearing. Really? Never noticed that. I need to know which version of FSUIPC and FS you are talking about, and the actual offset you are talking about would help. Tell me more about versions (information always needed!) and I'll check. I did change the priority of a lot of values recently. I don't want to delve into code unnecessarily, nor, indeed, the wrong code! Pete

You appear to have lost SimConnect, which is needed to load and run FSUIPC and most other add-ons for FSX. Please see the FSX Help announcement above. You need to reinstall/repair SimConnect. Regards Pete

Not quite right there. The 0BDC offset is the standard flaps control value. 0BFC is the flaps INDEX number. 0BDC dates back as far as FS98 and Adam Szofran's FS6IPC. It is one of the originals, reflecting values which were actually at these offset in the FS98 GLOBALS.DLL. As is made perfectly clear in the FSX Offsets documentation, the 0BFC value is new to FSX -- that's why it's listed in Blue. Please do refer to the documentation supplied for all these things. Well, for 0BDC it sounds like he's doing something wrong. How's he checking? Easiest way is to use FSUIPC's monitor -- right-hand side of the Logging options, enter offset 0BDC and type U16. Check the "Advdisplay" option, and it will be shown in real time on screen. The offsets list shows it as 4 bytes, but in fact only the loer two bytes, i.e. 16 bits, are used. Regards Pete

Well, the memory certainly shouldn't be the problem (unless some of it is playing up). but Vista SP1 is something I don't know about. There have been a few folks mentioning problems with SP1, though they might have been using a Beta. Are you? I don't have SP1 here yet -- when I look for it I'm told it isn't available till mid-April, and the my automatic update setting will take care of it in any case. All add-ons, or only some? Re-introduce them one at a time. Regards Pete

But are you sure those were not running anyway? As I said, cleaning the Registry won't stop them. You'd have to explicitly delete the EXE.XML and DLL.XML files, or remove the modules they were loading. Ah, yes, so it is! Sorry. How much memory do you have? Which version of Windows are you using? Regards Pete

Okay, I received the logs. The one from FSUIPC doesn't really show anything wrong, other than the premature termination of course. If does, however, show that you FSX is first loading a default flight with a non-default aircraft: 3666 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\FLIGHTS\OTHER\FLTSIM.FLT 3666 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR It would be sensible, for elimination purposes, to start FSX up with default data, in case any of the add-on parts are corrupt. Is that add-on FSX-specific, or transferred/converted from FS2004? I know you changed then to a different aircraft: 24180 C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\C208B\Cessna208B.AIR but by then the damage may have been done. The only way to be sure you are not constantly reloading something which is causing corruption is to delete your FSX.CFG file and let FSX make a new one. If you have too much invested in that and don't want to lose settings, then either delete or edit FLIGHTS\OTHER\FLTSIM.FLT so that the third party aircraft is not loaded. Looking at the SimConnect log, I see that there are other SimConnect clients loading: 0.25883 Exe Launched: Path="C:\Program Files\FSForce 2.0\FSForce.exe" CommandLine="/FS" Version="2.0.5.0" and 1.68951 DLL Loaded: Path="C:\Program Files\FSForce 2.0\FSForce.dll" Version="2.0.5.0" These are loading by virtue of entries in your EXE.XML and DLL.XML files, respectively. You didn't mention these in your orginal report. And when you said "Removed FSX, cleaned registry, reinstalled FSX", you should note that "cleaning the registry" doesn't remove much to do with FSX at all -- only its install path really. Most of its data is kept in assorted Application Data folders, in the Documents and Settings areas -- separately for CFG, XML and Scenery configurations. You probably didn't remove all of those before the reinstall. I don't know what FSForce does, but as part of the process of elimination, try without it. There's a freeware program which makes enabling/disabling EXE and DLL modules easy -- download the DBS FS Startup Editor (see http://www.dbsim.com/). I see TrackIR is also running -- looks like a new version, as, like FSUIPC4, it is using SimConnect's "named pipe" interface (added in FSX SP2/Acceleration). The FSForce programs are both using the old less efficient SimConnect interface. I use TrackIR also, so it looks like I should go look for the newer version. The only othe interesting info in the SimConnect log is related to that Exception 2 you referred to earlier. See, here, at 39 seconds into the session: > 39.95232 [ 1, 2383]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 < 39.95234 [1] Event: Group=2 EventID=66387 Data=-16383 > 39.95235 [ 1, 2384]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 39.95237 [1] Event: Group=2 EventID=66388 Data=-16383 These are two events setting Left (66387) and right (66388) brakes, respectively. no error, perfectly good. They re-occur regularly without problem. However, much later (3 mins 42 secs): > 222.61162 [ 1, 11209]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 222.61164 [1] Event: Group=2 EventID=66388 Data=-16383 > 222.61165 [ 1, 11209] < 222.61166 [1] >>>>> EXCEPTION=2, SendID=11209, Index=0 <<<<< Unrecognized Data Received. [ 1, 11209] SimConnect reports a data error on the same Right Brake setting? I can only think this is an indication on some memory corruption -- named pipes operates through shared memory. This isn't where you get the crashmany more working exchanges with the Right brake occur before then. The log simply peters out at the point of the crash, there's nothing spectacular, nothing indicating anything wrong. Quite honestly, from the varying reports from Windows about where the crash is occurring, plus that very suspicious Error 2 for no reason, I would suspect one of two things: 1. You are running out of real memory during the FSX session. FSX is not very good at dealing with memory shortages and they do often tend to cause crashes in different places, or 2. You have a problem with one or other of your memory chips. Maybe they are not seated correctly, or getting too hot, or have rather precarious timing settings on them. By all means try the process of elimination I mentioned. You already did that with FSUIPC, reducing the memory load, maybe the other add-ons also increase the loading. The other thing is added scenery -- meshes, landclasses, etc etc. They all help to increase FS's demands for memory. Regards Pete

That's weird. The only thing I can suggest is that you go to http://www.sysinternals.com and get the free diagnostic utility "filemon" (http://technet.microsoft.com/en-gb/sysi96642.aspx). Run that before running FS. It will generate a lot of entries so set the filter to "FS9.EXE" (or whichever FS it is) so that it only shows actions from that program. Erase the list then run FS. If you can't see what is happening, save the results to a file, Zip it up and send it to petedowson@btconnect.com. Hopefully I'll be able to see what is going on. Regards Pete

Okay, but it is getting late here & I'm off to bed, so there may be a few hours delay ... Regards Pete

It means the the code signature placed on FSUIPC for security against corruption does not check out. Either the DLL is corrupted, or virus-ridden, or something is missing in your system needed for the check. The helpful part saying "Try applying the supplied Global SignRoot Fix." is actually normal everyday English, and it means that you should try applying the supplied Globalsign Root fix. "Supplied" here means that it is actually included in the ZIP file you downloaded, the one containing the FSUIPC.DLL. Did you not even bother to look? This is documented in the FSUIPC User Guide, also in English. Please take a moment to look at it. It would save us both time and frustration. The relevant part is in a Box labelled "IMPORTANT" right at the begining of the section on "Installation". I do write this stuff for a reason, you know. :-( Regards Pete

Nevertheless, the parameter files (configs) should still be saved. If FSX really isn't terminating correctly, albeit after many seconds, you need to find out which it stopping it. it will be a Gauge or DLL, not any external EXE. You'll need to go through a process of elimination. First, eliminate the possibility that it is one of the gauges in one of the aircraft you are using. Assuming your default flight loads a default aircraft (if it doesn't you'll need to change that), have a session where you only use default aircraft, no add-on ones. See if your button settings are saved okay. If so, it is one of your asircraft causing the problem. Then, assuming you don't find it that way, list the DLLs which are being loaded -- the DLL.XML file controls those (in the same folder as your FSX.CFG file). Disable one at a time until you find the culprit. If I were you, to make this easier, download the DBS FS Startup Editor (see http://www.dbsim.com/). That makes this part much easier! Regards Pete

What do you mean "enabled all FSUIPC logs"? Please do not! FSUIPC produces a log in any case, and any serious problem will be logged in there without you messing with any of the options. This means nothing in isolation. Please never bother to extract single lines, if you want me to look at a log, show me the log -- the complete log, beginning to end. You have simply enabled an option which confirms that you don't have either the PFC or Epic drivers installed. They are optional logs precisely because they are not relevant to most users, but help identify problems for those who do use such things! I'm not aware of any problems in those, but it is sounding as if you have a corrupt FSX installation. If you want me to check further all I can suggest is: 1) uncheck all those superfluous FSUIPC logging options you have selected. 2) Set up to get a SimConnect log (those size mismatch errors may not be true errors, but the details about them will be in the SimConnect logging). To get a SimConnect log see the FSX help announcement above. 3)Run FSX until the crash. Find the SimConnect log and FSUIPC log and ZIP them both, send to petedowson@btconnect.com with a description of what you were doing. Regards Pete

It sounds like FSX isn't terminating correctly -- it only saves config changes when it closes, so if it crashes out instead you don't get its CFG files updated. Does this happen with other options in its menus too? If so then that's confirmation -- something you've added is not allowing FSX to terminate correctly. After you close it, look in the Process list in task manager (Ctr_Alt_Del) for FSX.EXE. If it is still there after a number of seconds, it isn't terminating correctly. Regards Pete

It does the same as the AP_PANEL_HEADING_ON/OFF controls, as appropriate. When turning this on it sets the flight director to use the current Panel (bug) setting. No, the FS control for that is AP_HDG_HOLD. This would also change the bug to the current heading. To do this via the 07C8 offset you'd first set the current heading to the AP Heading offset (07CC). Alternatively just send the FS control via offset 3110. Note that you can easily find out what controls do what by using the Event logging in FSUIPC, and checking the Log file. Regards Pete

I don't know. This is a facility I use all of the time, with never a problem. The command line is used exactly as you enter into the line -- the "Error 2" simply means "file not found", and this is what Windows is telling FSUIPC at the time. Could you show me the INI file and the FSUIPC.LOG file from at least one of these, please? Regards Pete

Glad you fixed it. I suppose I've developed a bit of a persecution complex over the years! Regards Pete

Isn't there a message in the title bar telling you why? It sounds like you are not running as an Administrator. Please check the documentation. Regards Pete

You've made some mistakes with assignments, then? Delete the FSUIPC4.INI file and let it generate a default one. The default trim keys are 1 and 7 -- the 2 and 8 normally operate the elevator itself. It sounds like your FSX assignments themselves are in a mess. Have you checked? Anyway, unless you've got those keys assigned for something else in FSUIPC, this really can be nothing to do with it. Maybe it is something to do with those aircraft. Did you check with a default aircraft to see? Well, that must be pure coincidence. Something else has changed, for sure. No. There is no reason to go back. It will make no difference whatsoever. There is an interim update (4.264) in the FSX Downloads announcement which you can try too, but there certainly isn't anything these which would affect this either. Everyone always blames FSUIPC for everything. It is very depressing. :-( Regards Pete

Ah. Glad it wasn't too hard. ;-) Pete

Actually, that isn't the problem. That's only the UDP server failing to start: Since you are probably using TCP that wouldn't stop it working. What does stop it is this: Now I've never seen either of these errors ever before. WideServer is merely relaying the errors it is getting from Windows. It loooks like you have no network working, possibly no active network adapter, etc. Best to try to get your network really working properly then try again. Incidentally, why are you putting these parameters into the Server's INI file? The server supports any of the three protocols, the choice is made by the Client. And why would the Server need to be given its own IP address? Are you reading the documentation and making your own mind up about what to do? If you've been messing with the INI files, best to delete them and let them default again. Regards Pete

Good. but it is a bit worrying for me. The codesigning check in Windows uses "wide character" format -- 2 bytes per character instead of 1. But all the folder / filename routines use multi-byte characters -- that is single characters for standard English/ASCII characters but 2 or more for other character sets like Cyrillic. Before I call the codesign checker I have to use a library routine "mbstowcs" to convert multi-byte to wide character format. It seems this is going wrong. I've looked at my code and that looks fine, so I'm wondering now if there's a bug in the C++ library, at least for Cyrillic multi-byte. I'll do some checking into this, as it may occur again with other users. Glad you are okay now, though. [LATER] I can't find any reports of any problems with the library routines I'm using. I am wondering if it has to do with "locale" settings. The multibyte encoding, or "Unicode", has different "code pages" for different character sets, and the "locale" set on the PC selects the code page to be used when Unicode is selected. Is it possible that you have a different User locale set, not the one normally used for Cyrillic? (Sorry, I can't, at present, explain any moreI am floundering a little in an area I know nothing about). Regards Pete

Only the first few lines were needed: The outgoing connection is being blocked completely. The most likely reason is a firewall, on the Server PC by the look of it. You said you tried disabling them, but evidently this did not happen. Windows Error 10038 merely says "An operation was attempted on something that is not a socket.", which effectively implies that the socket which was automatically opened for the incoming connection from the client has been closed by something as soon as an attempt to write to it is made. Incidentally, I've never had to disable any firewalls anywhere to make WideFS work fine. I've used both Windows and Norton firewalls with no problems. You may get a prompt asking if you want to allow the connection, but no more. I don't know what security software you are using, but it is still preventing the connection -- or something you have installed certainly is. Regards Pete

I've tested this and, in fact, the space bar by default actually uses the same toggle control ("MOUSE LOOK TOGGLE", but it sends it when pressed and also when released (also continuously whilst held), so cancels itself. I think this is too complex for me to easily implement in the easy way I dealt with the simple space bar held action -- detecting the control is asynchronous compared to keyboard interception in any case, and things may get out of step. so I'll quit on this whilst I'm ahead. Regards Pete

Not so rapid. The retries are at 20 second intervals. This is the standard timeout for receiving data. The Client end is only half the story. Please show the equivalent period WideServer.Log too. The summary at the end shows that, in fact, the Client never received any data blocks from the Server. I have no idea what the instruments were showing, but it most certainly was nothing to do with what was happening on the Server. I can't comment any further without seeing what the Server made of this. Pete

With Vista I'd avoid "Program Files" if I were you. Vista protects it against programs writing data, so makes life difficult for non-Vista aware add-ons which then forces you to always run everything with the "RunAs Administrator" special privilege. Best to keep it simple -- C:\FSX. Regards Pete

Ah, I see. So to avoid any problems all folks should do is make up their minds whether to use CHM first, before assigning in FSUIPC. Then no problems would arise. Alternatively, simply delete the FSUIPC INI file and start again if you change to/from CHM? I don't think CH themselves would be interested is "fixing" anything here, as they wouldn't regard it as a problem, surely? This reminds me of the days of Game Ports. If you were using a Game Port joystick, then unplugged it but did not unassign it, there would be long delays whilst the Game Port driver timed out every single attempt to poll the device that isn't there! USB is supposed to deal with all of these things tidily, but evidently the CH Manager hooking is wrecking that a bit. Regards Pete