Pete Dowson

That is a much more normal sort of crash, and it is actually where you can get more useful information, such as the address of the error, often also the module, and even some status of the stack at the time. You get this by the button for more details. Unfortunately nothing in any Event Log I've ever seen contains anything useful whatsoever, at least not to a programmer. I think it's intended for system administrators, not programmers or testers. I find myself now in a very difficult position. The problem which I reproduced here, which seemed identical to yours, is not now reproducible here wth 3.717. So far nothing I've done has induced any sort of crash whatsoever. So it seems I fixed a problem which you don't get. I'll keep trying, but please let me know anything specific you find. Unless I can make it crash here I do not stand much chance of doing anything about it I'm afraid. I may actually be forced to freeze all pre-FSX development back at 3.70, discarding 3.71 etc, and all additions so I can get on into future things for FSX and beyond. The strange thing is the lack of any really serious changes between 3.70 and 3.71. It is a shame no one reported this problem with any of the increments -- 3.701, 3.702... 3.709, all of which were provided for several weeks each. Determining exactly WHICH change brought this on would be oh, so useful! Alas, although I do keep some increments, for a while, it is now over 9 weeks since 3.71 was officially released (9 weeks till the CTDs were reported to me!) and I do not keep prior histories so long. Even the increments between 3.70 in July last year and 3.71 in early November were pretty evenly spread over those four months, with, again, no adverse feedback like this. :-( Looking through all of the changes from 3.70 to 3.71 there was really only one related to its interface to FS (which is where this problem must be occurring), and that is the one providing new data for the HSI. I wonder if the code accessing that data isn't so well protected against a change of aircraft. Maybe I will provide another interim version with that data removed for now, as a test. Regards Pete

Er, what, precisely, is in your FSX folder? Have you tried following any of the instructions in the documentation? Have you actually looked at the documentation? Have you actually run FSX with FSUIPC4 installed, and looked at the Add-ons menu at all? If you cannot find the section called "Entering Registration Details" (page 7 in the documentation), how will you manage to find later sections on using these "control tweaks" in any case? I'm at a bit of a loss to understand why you paid for it. Can you say why, what you actually want to do? Please, do follow the Installation and Registration sections in the user guide, first. When you run FSX and go to the FSUIPC menu entry under Add-Ons it should be obvious .... and there are actually pictures in the user guide to show you things you will see. Regards Pete

Well, I did it by disassembling and hacking into FS modules, to see what made them tick. At that time (back in FS98 days) it took me many many hours. A good, but expensive, disassembler is IDA, and you might want to consider Soft-Ice as a debugger, which is what I invested in back then. However I think the latter is very very expensive these days, and in fact the latest Microsoft visual Studio debuggers are quite good if you get the Pro editions. Alternatively, if you learn how to do FS C/C++ gauges, from the older FS SDKs, you will find that the DLLs are not really so different. C compiled GAU files are DLLs too, just renamed. There is a "blank DLL" which helps -- i.e. one which does nothing but gives you a starting framework. I'm not sure where that might be found now. But someone may chip in. Else go look at the FS programmers forum, on Avsim I think. Regards Pete

Can you explain how you managed to interpret it like that? Just because, for ease of installation and better performance, I did not maintain the WideServer.DLL separately, does not mean it was not re-written for FSX and is, in fact, a new product and separately registrable. The only common code in the Wideserver7 part of FSUIPC4 with the WideServer 6 DLL is the part handling the Network, which hasn't changed very much for many years, being based on Microsoft examples. Installing FSUIPC4.DLL in FSX is akin to installing both FSUIPC3 and WideServer in FS2004. But in neither case are both automatically registered without a key. The only difference having WideServer code incorporated in FSUIPC4, apart from the performance advantages, is that it saves you having to add a new version of WideServer.DLL. It doesn't not mean WideFS7 is now free. Regards Pete

I don't really know anything about firewalls. I use a router which has my firewall, so usually I don't bother with any software ones. When I have tried them I am simply prompted the first time anything wants to access the Network and I am able to set the correct permission, like "yes, always" or "only this once", or "no, certainly not" (but not those exact words). This occurs with both WideServer and WideClient -- WideServer to send out the Mailslots (port 9002 on the clients, by default, by the way), and WideClient to request connection. Oh, also, Is a "UDP" port the same as a "TCP port"? By default WideFS uses TCP -- did you select UDP instead? In any case, you didn't actually say it would not connect but that it took over 10 minutes to connect. How would a firewall block come to allow a connection attempt only after such a time? I doubt that it would have a setting saying "don't allow any connections unless they are really really persistent!" ;-) Sorry, I am not being very helpful on this subject at all, simply because I don't know. I cannot imagine what took 10 minutes, and without any logs showing any errors I couldn't really even guess. Just glad you resolved it! Regards Pete

Okay, by following your procedure: I can induce FS9 to crash eventually -- seems to take 10-20 attempts here, but only on one of three PCs I've tried it on. Oddly and perhaps relevantly that one is the only one I have with an ATI video card rather than an nVidia. Can you tell me what video card you are using please? I am installing my debugging system on the one PC on which I can induce it, and will try to see what is happening. At first glance it looks to be a timing clash between threads involved in setting up and cancelling data structures between different aircraft types, as the crash is always between a prop to jet, jet to prop, jet to helo, helo to prop, etc etc type change, not for instance 737 to 777. FSUIPC accesses these data types in what is supposed to be a "safe period" (i.e. one in which they are guaranteed to be accessible), but some of my threads may be rather more efficient than they were and need additional safeguards. I'll let you know as soon as I think I may have got somewhere. Are you willing to test a version for me if I send it, or are you sticking to your "3.70 works and that's it" stance? If the latter I will need to find someone else willing to try things. Thanks & Regards Pete

Oh dear. That is very strange. I have already had a separate response from someone else for whom 3.716 "fixed" them. Neither posted here. It is very unhelpful if folks do this and never report it here, or even write to me in other wayts. I really cannot afford the time to be a web browser. Well, it wouldn't be a waste of time if we could get to the bottom of it, but it isn't easy when everyone simply decides to stick with an older version, and even in the majority of cases not bother to report it. But that's your choice. Anyway, now I know you can make it happen in 3.716 I will try to reproduce it here. If I can do this under debugging conditions there is a good chance I can work out a fix or a work-around for it. It is probably a case of timing, where data for one type of aircraft no longer exists for another. There are precautions taken for this, but timings may be critical. There was no way I could debug anything with 3.71 because I don't keep copies of original sources going back so many releases. Regards Pete

It isn't particularly limited. The tables internally alloow for 255 simultaneous connections, but a few of those should be left free for re-connection attempts in the event of errors. I suspect the real limit is imposed by Windows sockets -- the maximum number of sockets it can allocate is specified somewhere in the network properties. That may be limited to something like 128 or even less. Regards Pete

I am assuming you are talking about using FSUIPC offsets? Or are you reading gauge variables direct in FS? It would help if you gave the context of your question. If FSUIPC, can you tell me what offset it is which tells you whether it is a Boeing or Cessna? I don't think I know that one. The main aircraft type offset, at 0609, tells you whether it is a prop or jet or helo or glider, and the offset 0AEC tells you how many engines it has. There are offsets which give you the full "title" of the aircraft, from the Aircraft.CFG file, and other offsets giving other information from that file, such as the ATC type and so on, but all they do is reflect whatever it is that the user or aircraft designer enters into those fields in the CFG files. Please clarify your question somewhat so I can help. Regards Pete

Are you running FS in Windowed or full screen mode? Isn't FSPassengers a module of FS, part of FS, not a separate EXE? I think you have to write an FS module. Have you checked what the programs you are talking about consist of? Regards Pete

Yes, but if it it only WideFS you are concerned with, why worry about FSUIPC'sINI? Pete

First, the only thing you can't stop: if FS loses the focus you will lose the FS sound. You cannot transfer focus (keyboard and mouse input) to a separate process without the original program losing focus, and if FS doesn't have focus it stops the sound. The pausing on loss of focus is an option in FS which you can turn off. I don't remember which menu it is in, you'll need to look through them. You shouldn't be able to minimize FS except deliberately, unless of course you are running it in full screen mode. In full screen mode nothing else can use the screen --- by definition. If you want to share the screen between FS and your program you will have to run FS in Windowed mode. Regards Pete

Apart from possibly upgrading to the FSUIPC 3.716 avaialble above, I certainly don't see the point of uninstalling and reinstalling FSUIPC or wideFS DLLs. they are code. they don't change except from version to version. Unless you have edited the INI files there's no point in reinstalling those either. Have you edited them? Are you using winXP throughout by the way? If you haven't been changing the INI files i don't want to see them. I can look at mine! ;-) Log files are made each time you run FS. Regards Pete

10 minutes!?!!??? 10 seconds is pushing it! What do the logs show? sounds like you have something pretty seriously wrong. It always helps if you have static IP addresses on ALL your PCs on a Network, and your Router too. but it wouldn't account for your long long long connection time. If it is taking 10 minutes or more before it can even see the Server, it is certain to go wrong later too. I really cannot imagine any sceneraio where such a time would be possible. assuming both ends are running WinXP, the Server sends out its details every second, so 2-10 seconds for initialisation is normal. 3.71 is an FSUIPC version number. WideServer version 6 would hsave to be 6.71 or you have an explanation already -- WideFS 3 would be about 6 years old and certainly not very compatible with recent versions. Regards Pete

There's no such thing as a "proper" or "improper" INI file, and there's nothing you can set that will cause CTDs or fix CTDs if something is causing them. Much more important information would be in the FSUIPC.LOG file, but even then, if it is FSUIPC you are having problems with, the Log would show the problem and you wouldn't get a CTD. I assume you are using version 3.716? If not, try that first. Regards Pete

I've not used EPIC for a long time, but axis values could surely be used for V/S too if needed? Is it the EPIC negative number problem? PM doesn't change for FSX, so why isn't the same facility there? FS itself has always had INC/DEC facilities too of course, in FSX just as in all previous releases -- AP VS VAR INC and DEC. These are the ones used by mouse clicks on the MCP. Regards Pete

It's a facility to remove ATC ops in FS9 and patch some parts of FS which otherwise cause CTDs when you have ATC switched off. These are caused by a known bug in FS9, to do with COM1 frequency tuning with ATC windows suppressed. If you use FS's ATC windows then you don't need to use the FSUIPC facility at all. If you look at the current FSUIPC User Guide you will find a complete sub-section on this -- it is even listed in the contents at the front. Regards Pete

Your problem is that you are not telling WideClient the name of your Server, nor the Protocol you wish it to use. This is only automatic with Win2000, WinXP or, now Vista. With Win98 you need to edit the INI file and add the appropriate parameters, just as in all the older versions of WideFS for the last 10+ years. The system used to find the Server automatically cannot work with WinMe or Win98 or before. Please, please, please check the documentation. Regards Pete

No, not a mistake -- it is the latest on official user release, and it is supported, but the support necessarily leads to me asking you to try the later versions. It is always worth scanning the announcements here because they are used to notify you of possible problems or changes which might affect what you are doing, as well as provide later versions to try, just in case. Well, that isn't "fixed" in my book. More like "hidden" I suspect. In all the things you said you tried I didn't note anything about the main things I would have thought obvious to try. The FS display option "Render to texture" is one option which seems to be problematic, though whether on or off I am not sure. Certainly one way has been known to be a cause of CTDs. Other things are MipMap levels, and the various other settings for stuff like filtering and anti-aliassing -- different combinations of video driver and FS settings work better than others. FS9.0 used to be a minefield of CTDs. It got a lot better after 9.1 but they din't fix them all, and most were/are involved with video rendering on changes of view or aircraft. Regards Pete

If FSBuild is running on the Client PC, not on the FS PC, then that wouldn't be the correct path in any case. The best thing to do is to "share" that path, on the FS PC, with an obvious name, like "FSPLANS", then, on the client PC, tell FSBuild that path is "\\\FSPLANS" where of course you substitute the name of the FS PC. How you actually tell FSBuild this I don't know. Sorry, but I don't have it. Regards Pete

Good! Could you update your message in the other place(s) you posted your message too, please? It may help others and save some extra threads here! ;-) Regards Pete

FSUIPC 3.65 and WideFS 6.47 are pretty old versions now and not supported. Please check the documentation. you will see that WideFS did not support GPSout until version WideFS 6.50 (and even that one was released about 16 months ago!). Please occasionally check the Announcements in this Forum, or even look in the normal downloads page for updates. Please always certainly be sure to try the latest versions before complaining about any problems or something not working. In this particular case you are attempting to use a facility that never existed in the old versions you are using. Regards Pete

Thank you. But I hope you are not misunderstanding me. The "hassle" was only in relation to the registration of applications -- especially the many hundreds of freeware ones. The registration of users, in exchange for the benefits of the many extras, such as the joystick facilities you mention, has been a success and will continue. In FSX, with Microsoft offering applications the SimConnect interface as their longer-term preferred alternative to working through FSUIPC, the prime focus for the future of FSUIPC will be in supporting and developing useful facilities for end users, rather than those for applications, in any case, so the justification for application key checking diminishes considerably. Thanking you for your support, Best Regards Pete

Since you have not registered FSUIPC, and you have no add-ons using FSUIPC, it is actually not doing anything (not sure why you are even installing it). Just because you can make CTDs happen with it installed and not without, doesn't mean it is the 'cause'. It only means that, whatever true problem is actually occurring only results in a CTD when the timing and memory arrangements are just 'so', just as occurring with that partifcular version of FSUIPC installed and not a different one. This sort of thing has happened now and then through the life of FS and FSUIPC, and with and without other add-ons, and from your description is likely to be one of several things: 1. A video driver problem. It may be worth trying to change some of the settings, in the drivers and/or in FS -- things like "render to texture" in the display settings are often very sensitive in this way. It may also be worth trying different versions of the video drivers. Trial and error is the key. 2. A corrupted file. If you had the problem before, then re-formatted the HDD and re-installed everything and still get it, then this is less likely of course. But otherwise known causes are bad WX files, especially if loaded by the default flight (which you cannot stop loading without editing the FS9.CFG file), or a corrupt graphics file, either for scenery textures or aircraft. You could also try using the latest interim version of FSUIPC, 3.716, which can be downloaded from one of the Announcements above. There's as much difference between 3.71 and 3.716 as there was between 3.70 and 3.71 (3.716 will be released as 3.72 before the end of the month). You say: but the first is certainly different ("my fs9 ONLY crashes in MP sessions"), has no mention of FSUIPC at all, and the thread stops after the suggestion "You're not using internet explorer 7 are you? If so then just delete OLEACC.DLL in the FS2004 root folder.", which seems to suggest that this cleared it up. The second reference actually contradicts you in effectively showing it couldn't be FSUIPC: Of those add-ons, the PMDG aricraft and SB3 both use FSUIPC -- no CTDs. GE Pro does not use FSUIPC, it is pure graphics - CTD. That certainly suggests video driver problems or corrupted graphics files. The only posting related to FSUIPC in that thread is your own. You say there "Read pete's forums and other have same problem." but that is very misleading as the only un-resolved post here like that is yours. :-( You also said this I have nothing to do with SimFlight forums other than answering messages in this one and being able to delete and arrange them. Someone in Simflight deals with registrations and user IDs. Then you say but the first gave no other information and stopped immediately the suggestion from Bob arrived about the ATC bug in FS9 which certainly is a known cause of CTDs, and the second is the one you refer to above, which is not even in my Forum and doesn't mention FSUIPC, only GE Pro as the cause. I would be grateful if, when you want support, you always first try the latest updates -- the Announcements at the top of this forum always tell you what is going on, and provide updates which may be good but simply have not made it to full user release status yet. Regards Pete

Correct. It was becoming too much of a hassle. With SimConnect being the MS "preferred" FS interface for the future, and that being "free" (except for new development effort of course), I saw no point in forcing key checks for FSUIPC access any more. No process needed other than you telling your users to use the most recent versions of FSUIPC -- 3.71 or later. ;-) Regards Pete