After doing some digging, I found that OpenInputDesktop, which is the function that the Login Agent code uses to determine if the screen is locked or not, was coming back that there is active desktop while Windows was sitting on the lock screen. I also noted that a screenshot taken via Graphics.CopyFromScreen likewise returned successfully while on the lock screen (as opposed to throwing an invalid handle exception, which is usually what happens). The desktop would go inactive briefly while locking and also while typing the password in to unlock, but would remain active while the lock screen was up and no input was being made.
The issue seems to be related to the version of Windows. Unbeknownst to me, this particular VM had Windows 10 Pro installed instead of Enterprise. It seems that in Enterprise, the desktop is inactive when the screen is locked, whereas on Pro, the desktop is still active even on the lock screen (perhaps this is due to a configuration somewhere).
What ultimately resolved this was changing the code that the Login Agent object uses to determine if the screen is locked. I came across a
StackOverflow post with exactly the issue I was running into that pointed me in the right direction. I replaced the Is Locked code in the Login Agent object to check if the logonui process is running instead of using OpenInputDesktop:
Locked = System.Diagnostics.Process.GetProcessesByName("logonui").Length > 0.
This seems to be working like a charm so far. It seems the only "official" way to determine if the lock screen is active or not would be to create a service and subscribe to the SystemEvents.SessionSwitch events. As far as I can tell, there is no Windows function to determine directly if the screen is locked or not, which seems unfortunate. Anyway, I hope this helps if someone gets caught in a similar situation.
------------------------------
Nicholas Zejdlik
RPA Developer
------------------------------
