Determine if running during logon process.

[ShawnTassie]

Folks, First post here - sorry if wrong forum or has been asked before. I'm looking for an API call or "a strategy" to allow my program to determine if it is being run during a normal interactive Windows logon process (for example, as part of a logon script) versus afterward. This program will only be run on W2K and above. Been looking at the LSA functions, not seeing anything obvious. Thinking about things like enumerating processes and like, looking for some kinda context. Anyone see anything about doing this kinda thing, on this board or elsewhere. -Shawn

[Toby Opferman]

If you want to determine if you are being run during logon by a script you may want to look at your parent processes. I believe, don't remember right now, but during logon the scripts are executed by USERINIT.EXE and not WINLOGON.EXE (If they are executed by WINLOGON.EXE USERINIT.EXE will still be present and it goes away after you have logged in). So, either a) your parent process or parent's parent will be USERINIT or it will be WINLOGON and USERINIT will still be running and present on the system. You should do some experiments with walking your parent process. USERINIT does not go away until all logon scripts have run (They are synchronous unless you start a seperate process and don't wait). So, even if USERINIT is your parent after logon, USERINIT goes away so you will see it as the parent of explorer, but the process will not exist anymore. This is one way; there are other methods which can be attempted some more complex and require system components. 8bc7c0ec02c0e404c0cc0680f7018827ebee

[ShawnTassie]

Toby, Yes, this is exactly the information I was seeking (except you filled in the details so eloquently) ... I will try this strategy this weekend and report back. Thank you again. -Shawn

[Rama Krishna Vavilala]

You can find the logon sid of window station winsta0 if that is same as the logon sid of the process it means that the process is running in interactive logon session. I have some code in the following article http://www.codeproject.com/buglist/dbgfix.asp[^] There is some code that finds out whether the user is interactive user or not

[ShawnTassie]

Thanks Rama, Well, it not so much that I want to find-out if the user is interactive or not. Its more to do if whether he is currently being logged-in or not. Point being - I have an executable i want him to be able to run from his login script, but not afterwards ... And if this user was to manually kick-off his login script (therefore this program) later, that it would detect this, and the program would alert. Do you still think there is anything in your article worth investigating because to be honest, my ideal solution would be something more "straight-forward" like your suggesting. -Shawn

[Toby Opferman]

WlxActivateUserShell() will start the USERINIT process which occurs after the user has logged in and I also believe at this time switches to the interactive desktop. Then the login scripts are run (I don't remember if they are run on the interactive desktop or security desktop but I belive the interactive desktop). If this is true, this means that you would not be able to determine if you were run during the login process/scripts by using this detection as you would already be logged in. You also couldn't find out what the current desktop is to determine this if you are already on the interactive desktop when the scripts are run, which I believe is the case. 8bc7c0ec02c0e404c0cc0680f7018827ebee

[Rama Krishna Vavilala]

I am afraid that will not work. You have to find out the parent process of your script and see if it is userinit.exe as suggested by Toby. -- modified at 15:50 Friday 20th January, 2006

[Rama Krishna Vavilala]

I misunderstood the question. The logon scripts are run in interactive desktop so my method will fail.

[ShawnTassie]

Toby, Rama You guys are great help. The other thing is, this strategy has to work with both Windows XP Professional Fast Logon Optimization AND with login scripts running synchronously or non-synchronously. So again, looks like my best bet is enuming userinit. Cant say thanks enough. -Shawn

[Toby Opferman]

You can also look if explorer is running yet (unless the shell was replaced) as a backup verification. 8bc7c0ec02c0e404c0cc0680f7018827ebee

[ShawnTassie]

Ok gents ... just walked my procs on a typical logon ... here's are the results (proc.exe is my proc). pid=1484 proc=proc.exe pid=3412 proc=cmd.exe pid=3120 proc=userinit.exe pid=972 proc=winlogon.exe pid=892 proc=smss.exe pid=4 proc=System pid=0 proc=[System Process] so looks like userinit is the ticket, unless you guys see something else I should be keying in on.

[Toby Opferman]

Just make sure in Windows 2000 that USERINIT goes away after starting the shell; I don't remember if it does or not but in XP it does. 8bc7c0ec02c0e404c0cc0680f7018827ebee

[ShawnTassie]

Good point. Walking my procs from the command line, after being logged in yields this: pid=2704 proc=proc.exe pid=472 proc=cmd.exe pid=3188 proc=explorer.exe Like you say, this is on XP as well. Will do both these tests on Windows 2000 and advise.

[ShawnTassie]

Here is my first stab at a function - LogonMode returns 1 if running during logon, 0 (zero) otherwise. #include LONG LogonMode() { LONG pid = GetCurrentProcessId(); PROCESSENTRY32 pe; pe.dwSize = sizeof(pe); while((pid = GetParentPid(pid,&pe)) != 0) { if(_tcsncicmp(pe.szExeFile,"userinit.exe",12) == 0) { return 1; } } return 0; } LONG GetParentPid(LONG pid, PROCESSENTRY32* pe) { LONG lRet = 0; HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(hSnapshot != INVALID_HANDLE_VALUE) { if(Process32First(hSnapshot, pe)) { do { if(pe->th32ProcessID == pid) { return pe->th32ParentProcessID; } } while((lRet = Process32Next(hSnapshot,pe))); } } return lRet; }