Determine if running during logon process.

[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; }