And another "bug" in D3D9: I replaced solar system to SolM, and when simulation begins, loading screen don't want to disappear. Simulation works "in background". I just pressed Ctrl+Q, and Orbiter turned off very well.

That's a good news. It's not a bug. Scene rendering is currently disabled and Scene.cpp will require a lot of work until it can be enabled. I am not giving up yet, there must be a reason for failure of Phobos. I'll implement the video tab and if it doesn't solve the problem I'll ask Martin to run the client under a debug version of the Orbiter, that would show the parameters those are used in initialization of the Phobos.dll and Satsat.dll

I have implemented the video tab but it didn't have any effect in the problem with Phobos. It would appear that the "DG Mk4 in Orbit" scenario seems to "crash" in a phobos.dll and "Atlantis cockpit" scenario is "crashing" in a saturn.dll.

This is geting more and more complicated... I placed a wrapper dll between the Orbiter and the Phobos as well as Mars for reference. The parameters passed from the orbiter to the Phobos.dll are the same for both clients D3D7 and D3D9Clients. Of course, some handles are different but they both look good. But anyway the problem is isolated to clbkFastEphemeris() which is called but will never return. There could be uninitialized local variable inside the module, that is for some reason, giving trouble with the D3D9Client. The same problem seems to apply to Saturn.dll, Mimas.dll, Enceladus.dll and probably many more.

I'm trying to fix it, but still no results. As I mentioned earlier, we should write completely new client. Much faster than working out this error.

The implementation that I have been working is only containing online code in D3D9Client.cpp, D3D9Surface.cpp, D3D9Frame.cpp and Texture.cpp. Everything else is offline. These files are rewriten from most parts. Even if we could make a new client based more or less in the existing code of the D3D7Client there is only a very little chance that we will avoid this error. I already re-implemented the D3D9Client.cpp without using the D3D9ClientSurface class, just with a basic surfaces, but it didn't help.

The problem is that I have no means to debug the problem where it manifests it self. The Phobos.dll has been successfully used with the Orbiter very long time, therefore, it's unreasonable to expect that the Phobos.dll and many other modules would have a fundamental bug of somekind.

A Buffer overflow in D3D9Client is unlikely the reason because the Orbiter have not yet loaded the Phobos.dll when the Client runs the splash screen and loads a few textures. There is no client code executed between loading the Phobos.dll and getting stuck in a loop. This is the most frustrating bug I have ever encountered.

I'll try to continue a development without Phobos and Saturn system. Removing them allows to pass the bug or what ever it is. There is nothing I can do about it. But nobody's going to use the client if it won't work with those modules so the problem must be solved. I'll leave the debugging of the Orbiter itself for Martin.

I'm no programmer and have little understanding of the issues discussed, so feel free to shoot me down, but discussion of phobos.dll in relation to graphics clients reminds me of a bug I posted in the D3D7 client http://orbiter-forum.com/project.php?issueid=129. Martin explained at the time that

I made some progress with the Client. The 2D panel cockpit and the glass cockbit is online and working. But there is a terrible performance impact during MFD update. There is still a lot of work with it. There are also problems with the Orbiter like DeltaGlider falling down from an orbit.

Installation note: Place the MeshTech.fx in the Orbiter's root folder.Installation note: Remove Phobos and Saturn system from the Sol.cfgInstallation note: Software Vertex processing must be unchecked from Video Tab