UAC blocks windows messages

[Martin]

We have a system that is comprised of 3 executables. They're all about
controlling displays.
1) Service.exe -- A service (running as local system)
2) Main.exe --The main app which is run as as local system too, but
within the interactive user's Session and attached to the user's
input desktop.
3) UI.exe -- A UI executable which runs under the interactive user's
account.

Service launches Main.
Main launches UI, using CreateProcessAsUser(), getting the
QueryUserToken().

UI.exe tries to broadcast WM_DISPLAYCHANGE at certain points which
needs to be heard by Main.exe.
But Main.exe's listening window & thread do not receive that message
if control-panel's UAC is checked on.
(BTW: On XP & win2k all is fine, and also on Vista when UAC=Off.)

Strangely calling ChangeDisplaySettingsEx() in the UI will
successfully cause WM_DISPLAYCHANGE to be heard by main.exe

Using Spy I can see that, for example, the frame of Notepad.exe does
receive the WM_DISPLAYCHANGE message, even though the window-procedure
in Main.exe does not.

I've tried using SendMessage, PostMessage, SendNotifyMessage, all
aimed at HWND_BROADCAST. All suffer the above problem under UAC.
I can add more details on how the processes are created if needs be.

Any suggestions of what's going on, and how I can fix it?
Thanks for any advice. I've been looking at this for a week now.

 

[Martin]

I'll begin to answer my own question, for the benefit of anyone else
baffled by this.

It seems that UIPI (User Interface Privilege Isolation) is the cause.
In summary: a lower privilege process cant send windows-messages to
higher privilege processes.

Its defined in the document: "WindowsVistaUACDevReqs.doc", which can
be downloaded from a link on:
http://technet.microsoft.com/en-us/windowsvista/aa905108.aspx

I'd still like any advice on a possible fix.
Is it possible to have the higher privilege process (Main.exe) that
launches the lower privilege process (UI.exe) open up a deliberate
chink in this UIPI armor?

 

[Martin]

OK, I got there in the end.
Sorry for the noise.
The answer appears to be call ChangeWindowMessageFilter().

 

[Jimmy Brush]

OK, I got there in the end.
Sorry for the noise.
The answer appears to be call ChangeWindowMessageFilter().

You may already know this, but running interactive programs on the
user's desktop running as system is considered a bad thing, even with
Vista's new security.

I'm sure you have a reason for doing so, but it would be better from a
security perspective if all the privileged code was running in your
service, and the only programs running on the users desktop was
running in the context of their user account.

- JB