russdirks

That's weird! I ran it on a clean partition and it worked fine. It has a manifest resource embedded. But like you say, the only thing needed is for it to generate a security warning.

Well, I've done some more experimentation with your program and mine, and a new copy of the Test.dll, and it looks like the workaround I described isn't as effective as I had thought. I set my system to load my program first and yours second, with mine trusted and your's not, and FSX still crashed. Sometimes it does a CTD prior to the first UI screen, sometime it gives an error like "The instruction at "0x20eab106" referenced memory at "0x07bb1054". The memory could not be read". Sometimes I make it into the first UI page, but it crashes during the flight load. So there is clearly something going on here beyond what I understand. MS hasn't even acknowledged this error yet. We really need them to give us some information as to what's going on so we can develope some effective workarounds. In case you want it, I've attached a new copy of the Test.dll. The one I uploaded before was a debug build. Regards, Russ Test.zip

I've done a fair bit of testing with my own modules. I think this is something that all developers are going to have to grapple with and understand. MS may come up with a fix, but that could be some time coming. I've attached an empty DLL I put together to test my code. You can use it if you want.

I've looked at this, and in fact a SimStart event occurs very early on, before or early during the progress bar showing the progress or loading of scenery, textures etc. Are you sure delaying the requests for a few seconds it takes to get to that point works? No, the problem doesn't occur when the flight is loading, but rather when FSX is loading, and all the addons are loading. The key question is, what does your code do right after a successful call to SimConnect_Open? Originally my code would immediately make a bunch of calls to AddToDataDefinition followed by calls to RequestDataOnSimObject. The workaround involved delaying the calls to RequestData until I received a SimStart event. I noticed from the SimConnect log that Bill gave me that your code makes a call to RequestDataOnSimObjectType about 2.9 seconds after SimConnect_Open. If you could delay that call, that might solve the problem.

Hi Pete, I've been working on a SimConnect addon, and I've discovered a bug that could have serious ramifications for all addon developers. I've found that FSX will CTD when one client has already been loaded, and has begun making calls to the SimConnect server, and a second client is in the process of being loaded, but has generated a security warning because it is not trusted. It seems that the combination of one client communicating with the SimConnect server in the background, while FSX is displaying the security warning dialog in the foreground causes FSX to crash. If the second client is trusted and does not generate a warning, everything works fine. I discovered this working on my FS Force program, which is comprised of an .exe and a .dll. I found that whenever I recompiled the .dll and ran FSX, FSX would crash as soon as the security warning came up for the .dll. In this case, the .exe had already been loaded and had begun talking to SimConnect. I just found out yesterday that the same thing happens with your FSUIPC program. I sent an update of FS Force to one of my beta testers (Bill Womack), who also has FSUIPC installed. His dll.xml file was configured to load FSUIPC first and FS Force second. When he tried to start FSX, FSForce.dll triggered a security warning and FSX immediately CTD'd. I checked his SimConnect.log file, and noticed that FSUIPC was making a lot of calls to the SimConnect server immediately after the SimConnect_Open call. I instructed him to disable FSUIPC from loading, and then he was able to start FSX normally, and tell FSX to trust FSForce.dll. Then he was able to re-enable FSUIPC, after which everything worked together just fine. If this is a confirmed bug, then I think this is going to be a big problem for developers and users of addons. Every time a developer issues an updated version that does not have a signed security certificate, it could potentially cause FSX to crash if there is another addon that is being loaded ahead of the updated one. The user will have to go through the hassle of disabling all other addons except the new one so he can tell FSX to trust the new one, after which he will be able to re-enable all the other addons. There is a workaround however. What seems to cause the problem is when the early loading addon makes calls to either RequestDataOnSimObject or RequestDataOnSimObjectType immediately after the call to SimConnect_Open. If instead the addon waits until the simulator has actually started (via a SimStart event, or RequestSystemState), then there are no problems. I hope you will experiment with this to confirm. My suggestion to reproduce the problem is to set up your dll.xml file to load FSUIPC first, and some other .dll second. Make sure the second .dll is not trusted, and then start FSX. If you can confirm all this, then we need to put pressure on MS to fix this as soon as possible. I've bugged it as ID 215790. I think it would also be good to try to get the word out to developers to implement the workaround. Regards, Russ Dirks