This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(70.4, 50%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELB%3C/text%3E%3C/svg%3E)
Recently, I was developing a Windows service program using C #, and after detecting changes in computer operation, I did some processing. The problem I encountered was, Some computers trigger the sessionLogon+sessionLock event when they are only powered on and have not entered their user name and password to log in. When they log in, the sessionUnlock event is triggered again, Some computers do not trigger the above three events when they are only powered on and logged in without entering their user name and password. Until they actually log in, they will trigger the sessionLogon event, I would like to ask, what is the reason for this difference? Is it an operating system issue or a computer hardware issue? Can you adjust the settings and unify them into one situation?
By default Windows will logon the last interactive user automatically and lock the session when the system is started. This can be controlled through group policy as shown in the image below -
Thank you for your answer. I set it up as you said, but it still doesn't work
No sessionLock event was captured。
One possibility is that your service is not starting early enough. In such cases the system has logged on the user and locked session but your service will not see the events.
Sorry, but I don't understand the text displayed in the above image.
Generally, the sessionLogon is captured before the sessionLock is performed,
My computer can capture “sessionLogon“, but cannot capture “sessionLock“
If you can share a sample without private information I will see if I can reproduce the issue you describe.
protected override void OnSessionChange(SessionChangeDescription changeDescription)
{
switch (changeDescription.Reason)
{
case SessionChangeReason.RemoteConnect:
writeLog(logger, "RemoteConnect", "info");
break;
case SessionChangeReason.RemoteDisconnect:
writeLog(logger, "RemoteDisconnect", "info");
break;
case SessionChangeReason.SessionLogoff:
writeLog(logger, "SessionLogoff", "info");
break;
case SessionChangeReason.SessionLogon:
writeLog(logger, "SessionLogon", "info");
break;
case SessionChangeReason.SessionRemoteControl:
writeLog(logger, "SessionRemoteControl", "info");
break;
case SessionChangeReason.SessionUnlock:
writeLog(logger, "SessionUnlock", "info");
break;
case SessionChangeReason.SessionLock:
writeLog(logger, "SessionLock", "info");
break;
case SessionChangeReason.ConsoleConnect:
writeLog(logger, "ConsoleConnect", "info");
break;
case SessionChangeReason.ConsoleDisconnect:
writeLog(logger, "ConsoleDisconnect", "info");
break;
}
}
running result：
computerA:
SessionLogon
computerB:
SessionLogon
SessionLock
One thing to keep in mind is that even if the system is configured to logon the last interactive user and lock the session this will not happen if the user logs out of Windows before shutting down/restarting the system. In such cases all your service will see is the user logging on.
I could not reproduce your issue.
Automatic logon/lock (default policy setting) -
Logoff then restart (default policy setting) -
Group policy for automatic logon/lock disabled -
Thank you very much for your answer,
The project is implemented using the SessionChangeReason in the c # language, and the events captured by different computers are also different, which makes me very confused
The language used for the Windows Service doesn't matter.
My sample service also referred to the SessionChangeReason.
For your information, my sample service ran under the LocalSystem account.
What versions of Windows 10 are you working with on the computer that exhibit different behavior? My test was conducted on Win 10 22H2.
sessionLogon + sessionLock + sessionUnlock:
Windows 10 Pro 21H2
Windows Feature Experience Pack 120.2212.4190.0
19044.2486
==============================
sessionLogon:
Windows 10 Pro 22H2
19045.2364
Windows Feature Experience Pack 120.2212.4190.0
So on the Win 10 Pro 22H2 system what was the group policy setting that was referred to above (Not Configured, Enabled, Disabled)? Did you reboot the system after making GP changes?
After changing to enabled, shut down and restart without any changes
Are these systems standalone or joined to a domain? Is it possible that domain policies are in effect?
The computer has two accounts, one that is joined to a domain, and the other that is not in the domain. I logged in using an account that is not in the domain. Does this have any impact?
Is the 21H2 system that receives the expected events standalone or domain joined?
That's the customer's computer, not very clear
As far as I know domain group policies take precedence over local group policy. I don't know if a domain joined system will default to last interactive logon/lock or not and whether changes to local group policy for this setting should be effective or not. This stuff is outside my area, I'm not a network administrator type.
Perhaps you can consult with your own network admins for the domain vs. standalone answer. If you can't find a standalone physical system for your own tests you might be able to use a virtual machine for testing.
This is a good idea. Thank you for your suggestion.
I would also like to ask, if not in the domain, will it definitely work?
For example, if I take my computer home, use my WiFi at home, and change the settings, will it work?
I looked at the information and found that the settings are for restarting, but what I want is not only to restart, but also to work when starting up
If the device is joined to Active Directory or Azure Active Directory, this policy only applies to Windows Update restarts.
I interpret this statement from the above documentation to mean that for other than Windows Updates the policy is not generally applicable for domain-joined systems other than for Windows Update.
I would also like to ask, if not in the domain, will it definitely work?
I have observed that Windows can behave differently depending on how the system was shutdown/restarted. First, remember that if the user logs out before shutdown/restart that the policy is not applied at the next boot and only a logon event will be seen by a service.
When a standalone system is shutdown from the start button a subsequent boot will generate the logon/lock sequence. Similarly, a restart from the start button also generates the logon/lock sequence.
However, Windows can also be shutdown or restarted from Alt+F4 dialog -
My observation in these instances is that the subsequent startup only generates a logon event. The session is not locked.
I have not tested how Windows behaves if shutdown/restart is programmatically invoked.
Thank you very much for your answer
I'm very sorry for the late response
I have tested it with the program. As you said, if you log off before shutting down, there will only be a sessionLogon event when starting up
Does that mean that computers with only sessionLogon events will automatically log off before shutting down?
Does that mean that computers with only sessionLogon events will automatically log off before shutting down?
I'm not sure what you are asking above? So I'll repeat what I said earlier. On a standalone system when the automatic logon/lock policy is in effect if the user manually logs out before initiating a shutdown/restart (or uses Alt+F4) then only a session logon event is generated during the subsequent restart and the session is not locked.
Otherwise, the system will automatically generate a logoff event when the user shuts down or restarts the system. For example,
If this lengthy discussion of the logon/lock policy has answered the initial question that you asked kindly accept my earlier response as an Answer.
Thank you for your answer. I set it up as you said, but it still doesn't work
No sessionLock event was captured。
Are you speaking about a domain joined system or a standalone system? We seem to be going around in circles.
Thank you very much for your answer. I understand