If applications will not connect to FSUIPC in Vista

[metamarty]

Hello,

I've been breaking my head over this problem, but found the answer and maybe somebody will helped by this post.

The problem I was experiencing is that after a successful FSUIPC install in FSX/Vista, FSUIPC seems to run fine, but no applications can connect to it. Turning on logging shows no attempts of programs to connect.

This situation occurs if you're running FSX in elevated permissions (run as administrator), while the clients programs do not. This makes all connection attempts fail silently. The solution is to either run FSX without elevated privileges, or run your client programs as administrator too.

Maybe this should be pointed out in the manual.

Thanks,

Marty

[Pete Dowson]

This situation occurs if you're running FSX in elevated permissions (run as administrator), while the clients programs do not.

Thanks for the information, but why are you doing that? It should never be necessary to run a Vista-aware program such as FSX in elevated administrator mode! I don't understand why you are doing it?

Regards

Pete

[metamarty]

You are right that is should not be necessary. There is a problem with FSInn that causes FSX to exit with an error if it is closed down. This seems to be solved by running both programs in elevated administrative mode. It's ugly, but because there is not much active development on FSinn, it's the only thing I have at this moment. I'd rather run all software without elevated privileges though.

[Pete Dowson]

You are right that is should not be necessary. There is a problem with FSInn that causes FSX to exit with an error if it is closed down. This seems to be solved by running both programs in elevated administrative mode. It's ugly, but because there is not much active development on FSinn, it's the only thing I have at this moment. I'd rather run all software without elevated privileges though.

Hmm. Thanks for the explanation.

I'm wondering why there's no connection to FSUIPC from different privilege levels. All I can assume is that either the normal search for a Window with a specific Class Name deliberately hides those Windows with a hight privilege level, so the applications don't even try to connect because they don't see FS running at all, or Windows deliberately won't allow a memory-mapped file to be shared by two programs of a different level. The latter sounds the most likely, presumably to make it all more secure.

Did you try switching off UAC (User account control) at all? That seems to remove some of these sorts of checks.

Any way, I'll remember to make a note in the documentation somewhere.

I wonder if this also affects SimConnect-interfacing programs using the SP2/Acceleration Named Pipes connection, as that, too, involves shared memory. Of course it would affect those written only to use the RTM or SP1 version of SimConnect as that uses TCP/IP protocols, even locally.

Regards

Pete

[trisager]

Marty, did you try this: http://www.mcdu.com/forum/viewtopic.php?p=22204

Tom

[metamarty]

Marty, did you try this: http://www.mcdu.com/forum/viewtopic.php?p=22204

Tom

I've tried it, but it didn't solve the problem.

I think the problem will go away without UAC, but I think turning it off is worse than having only FS with elevated privileges. Simconnect programs seem to be able to connect to FS, regardless if FS has elevated privileges or not. I think vista as part of UAC will block any attempt if FS is elevated. In unix there is a similar access system with shared memory. It might be configurable though.

[Pete Dowson]

I think the problem will go away without UAC, but I think turning it off is worse than having only FS with elevated privileges.

Really? Having UAC on makes vista almost unusable for me. It's just a P.I.T.A. Vista is much nicer without it. What are you afraid of? Are there other users accessing your system with your user log-on credentials? UAC only protects you from you, and that makes it very restrictive and for me completely unnecessary.

Simconnect programs seem to be able to connect to FS, regardless if FS has elevated privileges or not.

Pretty much all current SimConnect programs are designed to work with FSX RTM and SP1 as well as SP2/Acceleration, so they don't take advantage of the improved efficiency of the shared memory/pipe system available in SP2/Acceleration. The latter may well fall foul the the same protections.

Regards

Pete

[metamarty]

I think the problem will go away without UAC, but I think turning it off is worse than having only FS with elevated privileges.

Really? Having UAC on makes vista almost unusable for me. It's just a P.I.T.A. Vista is much nicer without it. What are you afraid of? Are there other users accessing your system with your user log-on credentials? UAC only protects you from you, and that makes it very restrictive and for me completely unnecessary.

Yes, I feel quite restricted, but coming from a unix background, I would like a general user to simply be able to run every software and unable to write to things he doesn't own. This would stop any kind of malicious software. I do have quite a lot of problems with UAC in vista as it is at this moment, but I don't yet want to give it up completely. The concept is fine.

Simconnect programs seem to be able to connect to FS, regardless if FS has elevated privileges or not.

Pretty much all current SimConnect programs are designed to work with FSX RTM and SP1 as well as SP2/Acceleration, so they don't take advantage of the improved efficiency of the shared memory/pipe system available in SP2/Acceleration. The latter may well fall foul the the same protections.

Regards

Pete

I wasn't aware of a new interfacing system in SP2, so it's hard to tell if there are already applications using it directly, but they might indeed have the same problems. If shared memory between simconnect and clients is used, I think there must be a way in the OS to set access control on this memory and allow everybody to use it. Maybe simconnect fails to do this, or it is hidden in an obscure configuration option.

[Pete Dowson]

I think there must be a way in the OS to set access control on this memory and allow everybody to use it. Maybe simconnect fails to do this, or it is hidden in an obscure configuration option.

I'd be interested to know more about this, if you do find out. However, in FSUIPC's case it is the application which creates the memory file and tells FSUIPC about it so it can open an access to it to retrieve the request data and dump back the results. The application keeps it, FSUIPC doesn't know about it except whilst processing the requests. That way each application has its own area, nice and tidy.

Since it is that way round, I don't see how the higher-privilege process (FSX) can mark the area as safe for lower-privileged access when it is a lower-privileged process which created it and owns it.

I suspect the same would apply to SimConnect, as each application instance would, again, need its own space, presumably created when it calls and opens SimConnect.DLL.

Regards

Pete

[metamarty]

I'd be interested to know more about this, if you do find out. However, in FSUIPC's case it is the application which creates the memory file and tells FSUIPC about it so it can open an access to it to retrieve the request data and dump back the results. The application keeps it, FSUIPC doesn't know about it except whilst processing the requests. That way each application has its own area, nice and tidy.

Since it is that way round, I don't see how the higher-privilege process (FSX) can mark the area as safe for lower-privileged access when it is a lower-privileged process which created it and owns it.

I suspect the same would apply to SimConnect, as each application instance would, again, need its own space, presumably created when it calls and opens SimConnect.DLL.

In this case, I don't think shared memory protection is the cause of the problems here. As there is no indication of an errors, it looks like the initial contact between the client application and FSUIPC fails. This would be before any shared memory is accessed. I don't know the mechanisms in which a client application contacts FSUIPC, but the behavior is similar to when FSUIPC is not running, so it looks like a lookup is failing somehow.

Marty

[Pete Dowson]

In this case, I don't think shared memory protection is the cause of the problems here. As there is no indication of an errors, it looks like the initial contact between the client application and FSUIPC fails. This would be before any shared memory is accessed. I don't know the mechanisms in which a client application contacts FSUIPC, but the behavior is similar to when FSUIPC is not running, so it looks like a lookup is failing somehow.

There's only ever one actual contact no matter what -- Sending a message, using "SendMessageTimeout" (the timeout is there to prevent the application hanging if the receiver never replies). The application first needs to get the window handle for window class "FS98MAIN", which is FS.

The Message sent provides an Atom ID, registered with Windows, which allows the memory filename to be reconstructed by FSUIPC so it can open the same memory file, already created by the application.

That's it, nothing else. If the application can't connect, as if it never sees FSUIPC, it is surely because of one of these reasons:

1. Windows prevents higher privileged Windows from being detected (which I certainly cannot believe), or

2. Windows refuses to allow messages to be sent to them and forces them to timeout instead (which I also find hard to believe), or

3. Windows allows all that but won't allow FSUIPC to open the memory mapped file.

Actually, there's a way of finding out. If you go into FSUIPC's Logging options and enable IPC Read and Write logging, it logs any errors trying to establish the connection when it receives the message. If it never receives the message then one of 1 and 2 above are correct. Otherwise there should be an error, one of these:

IPC ERROR: zero Atom Id

IPC ERROR: Atom Id not recognised

IPC ERROR: Offset >= 65534

IPC ERROR: Cannot OpenFileMapping (Error=N)

The third is a simple data error and not likely here. The last is the one I suspect. The error number will be one of Windows system error numbers.

Regards

Pete

[metamarty]

Thanks for the info. The answer is in the usage of the window handles and SendMessageTimeout().

I've found this PDF on UAC: http://pascalfonteneau.developpez.com/aDelphi.pdf

The important part is this:

* General guideline – “lower” can not access “higher”

* A lower privilege process cannot:

– Perform a window handle validation

– SendMessage or PostMessage

– Use thread hooks to attach

– Use Journal hooks to monitor

– Perform dynamic link-library (DLL) injection

I don't think this issue really needs resolving, as it would imply rewriting the SendMessage() part and I have no idea if there is another way to do this. Warning users to run FSUIPC software at the same privilege level as FS should be enough.

Marty

[Pete Dowson]

* A lower privilege process cannot:

– Perform a window handle validation

– SendMessage or PostMessage

...

Phew! That is restrictive!

Thanks

Pete