Norma,
I had forgotten to mention one more option for you. Customizing Winlogon
(GINA):
http://msdn.microsoft.com/library/en...g_winlogon.asp.
This is another way for you to make sure a particular service is started and
running. If not, you can delay the actual user logon (in WlxLoggedOnSAS
implementation) until the condition is met.
KM
>> Also, I do know that I need to find the root cause (and I will!), but I
>> am
>> looking for a "quick, robust fix" because of time to market issues.
>
> I understand. But in my experience, when you do a fix for an issue and
> don't know the root of the issue, the fix is unlikely going to be robust.
>
>> I tried your first suggestion; writing my own winlogon, renaming the real
>> winlogon.exe to ActualWinLogon.exe, and then launching that from my exe.
>> However, it blue screens with "The windows logon process terminated
>> unexpectedly ... "
>
> Please disregard that suggestion. After some thinking I don't believe it
> is going to work that easy as the Winlogon is a crucial part of Windows
> boot process and can't be easy eliminated (you replacement app will have
> to properly communicate with Csrss).
>
> You probably want to try another way and replace Userinit value
> ([HKLM\Software\Microsoft\Windows NT\Winlogon]) with your own app launch.
> Basically you app should check/wait until the DSP service is up and
> running (QueryServiceStatus API) and then start real userunit.exe from
> \windows\system32\.
> This way you make sure user profile is not loaded until DSP service is
> running.
> You app can even be a batch script (or any other supported script) that
> calls to sc.exe to query the status of DSP service and executes
> \windows\system32\userinit.exe at the end (please be aware that
> enviromental variables like SystemRoot are not yet available at this
> point).
>
> KM
>
>> I have searched MSDN and other sites for tips/tricks etc on doing this,
>> but
>> to no avail.
>>
>> Do you know if this really can be done, or where I could find more
>> information?
>> --
>> Norma
>>
>>
>> "KM" wrote:
>>
>>> Norma,
>>>
>>> > Our new, soon to be released, XPE OS is booting 1 minute faster than
>>> > our
>>> > current W2k Server OS. This is causing some timeout issues with our
>>> > 3rd
>>> > party DSP if the user logs in while the DSPs are loading.
>>>
>>> You should investigae what exactly is the root for the conflicts with
>>> the
>>> 3rd party software. Is is the actual user logon? (would be strange then)
>>> Or it is some service load order? Or some Startup items for a user
>>> account?
>>>
>>> Then you would know where to put the patch (fix, workaround, etc.).
>>>
>>> > The best fix would be with the DSPs, but ithat would take too long
>>> > (3rd
>>> > party), so I am currently searching for a "quick" fix.
>>> >
>>> > Is it possible to either:
>>> > 1. Control when the login screen appears (delay it for 1 minute)
>>>
>>> Theoretically, you can make you own app with controllable Sleep API call
>>> in
>>> it. The app should launch an exe like ActualWinlogon.exe.
>>> Rename the app binary toWinlogon.exe, rename the real Winlogon.exe to
>>> something ActualWinlogon.exe.
>>>
>>> > 2. The DSP code is an automatic service -- can I change the order of
>>> > automatic services such that the DSP service would be one of the first
>>> > to
>>> > start?
>>>
>>> Setup service dependencies.
>>> On XPe, it is LoadOrderGroup and Dependencies properties of Service Data
>>> resource (the resouce of the DSP component you've got).
>>>
>>> KM
>>>
>>>
>>>
>
>
Similar Threads
