On 12/01/2024 15:36, David Grayland (Staff) wrote:
> Hello,
>
> We're seeing a small number of instances of users experiencing an
> issue where their user registry hive is locked at log off or shutdown
> on Windows 10, which subsequently stops them logging into the device.
> Reboots often, but not always, clear the issue and we've seen
> occasions where just logging in as another user clears the issue
> too.
>
> We've created an Intune remediation to check for the event indicating
> the issue has occurred and can conclude from this that it occurs over
> different minor and major versions of Windows, different hardware
> model types, and different build types (staff or student). Cursory
> checks of the software used by the users would indicate there's no
> pattern there.
>
> Bit of a needle in a haystack situation and online searches haven't
> turned up anything concrete, so we were wondering if anybody else
> here had experienced anything similar?
Hi,
In general this is an issue with a long history, going back to the NT
4.0 days, I think.
There can be two separate problems here though:
#1 Some process has left open a registry handle such that the registry
hive doesn't unload properly at logoff.
UPHClean used to be the solution to this, although I think there are
things built-in to windows these days to give similar functionality. I
don't think we've had problems in this area for a while.
If I remember correctly, there is stuff in event viewer (system log)
about this if windows has to force close handles at logoff.
#2 If using roaming profiles or equivalent functionality, or folder
redirection for shell folders, windows will happily save things to the
network during logoff or shutdown, and then shut itself down without
closing the file handle on the server.
This leaves the file on the network in-use until the server times out
the connection and frees it. For redirected folders this can leave the
desktop.ini locked, which causes problems if the user moves to another
PC before the lock times out.
I'd guess you're more likely to be hitting #1, except a reboot should
always clear that. If it's surviving a reboot, that implies the lock is
elsewhere (#2) or has some other way to persist or reinstate itself
after the reboot.
One thought - is this maybe related to whatever security or monitoring
software you're using. E.g. if some software agent has got a handle into
the user's HKCU, and is able to save and restore its state so that it
picks up where it left off after a reboot, that might give the behaviour
you're seeing.
Mike
--
Mike Sandells (he/him)
Email: [log in to unmask] (*Preferred*)
The University of Liverpool - IT Services
https://www.liverpool.ac.uk/it/
########################################################################
To unsubscribe from the WINDOWS-UK list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=WINDOWS-UK&A=1
This message was issued to members of www.jiscmail.ac.uk/WINDOWS-UK, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
|