From: Richard Hartman [rhartman@realresume.com]
Sent: Wednesday, August 18, 1999 3:49 PM
To: Paul Foster; paul@ultrabac.com
Cc: ntdev@atria.com
Subject: [ntdev] partial answer: NT Services and USER32.DLL

At 10:39 AM 08/18/1999 -0700, Richard Hartman wrote:
>Interesting details: 1) If the service is started manually and the user
>doesn't log out, the error doesn't occur. 2) If the service is started
>automatically by the system at bootup and no user logs in, the error doesn't
>occur. 3) The service continues to run, with no errors, as long as the
>login/logout state of the system is not changed from that in effect when the
>service was started.

Research suggests that the system replaces the winstation/desktop DACL's
when an interactive user logs on or logs off. Note that I didn't say
"updates the DACL's"... it appears to outright _replace_ them, because the
ACE's we're adding are either vanishing or being altered in some way. Our
code normally grants access to the winstation/desktop once, during
initialization. Based on this theory, I altered it to grant access every
time it is invoked. Voila - the problem vanished. We can log in and out
freely and operation continues with no USER32.DLL errors.

This raises an interesting question. What happens if the service is busy
when a user is logging in or out? There will always be a finite amount of
time between our DACL updates and CreateProcessAsUser. If an interactive
user happens to log in or out after DACL update, but before
CreateProcessAsUser, our newly created child process will not have access to
the winstation/desktop and the error will occur. Any ideas on how to avoid this?

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ To unsubscribe, send email to ntdev-request@atria.com with body
UNSUBSCRIBE (the subject is ignored). ]