Windows Start Menu Locked Up, unable to restart machine.

Thank you for contacting Sophos Technical Support. Please see below summary of our investigation:
On a test Remote session we have replicated the issue and verified that by uninstalling interceptX and rebooting the endpoint issue was resolved. This verifies that its related to the known issue in the article below provided to you previously:
            "https://community.sophos.com/kb/en-us/124988#Windows 10 RS3 - Start UI fails to run during first login session"
As per article:

This issue occurs on computers not joined to a domain. Investigation has shown to be a possible Microsoft issue. A reboot may resolve the issue. The following two options will also prevent the issue from occurring:

• Locally, under User Accounts logon settings, by disabling the setting Use my sign-in info to automatically finish setting up my device after an update or restart.

The setting for  'Use my sign-in info to automatically finish setting up my device after an update or restart' was still turned ON on the endpoint in question. The workaround is to turn it off.

This is a known issue and is being investigated by our Dev team and Microsoft. Any further details will be updated in the known issues article.

This could be related:

https://twitter.com/markloman/status/967066016135172096

https://www.wilderssecurity.com/threads/hitmanpro-alert-beta.394398/page-40#post-2740104

"Fixed an issue with the Windows 10 Start Menu".

For those that have seen it.  I assume it's all Intercept X installs, I.e. those with HMPA installed.

Woohoo!!  I see it's beta though...  I hope this will be considered high priority for Sophos, so we won't have to wait another 3+ months for this fix to be released to Sophos Intercept and Home Premium users.

I guess it would be interesting to see if this fixes it?  Can you reproduce the issue reliably to know it helps?

As a test (ideally on a test computer but this should all be pretty safe) I would do as follows:

1. Check you don't have a pendingfilerenameoperation value under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\
If you do, reboot until it is gone.

2. Download http://test.hitmanpro.com/hmpalert3b734.exe to say C:\hmpatest\ but it doesn't really matter, I will just reference this location for guidance.

3. Open an Admin prompt in C:\hmpatest\ and run:
hmpalert3b734.exe /upgrade

4. The following location should be now populated with the new files:
C:\Program Files (x86)\HitmanPro.Alert\Update Files\

5. The registry key in step 1 will also be created with the entries to put the new files in place at restart.

I would then suggest moving the C:\Program Files (x86)\HitmanPro.Alert\Update Files\ directory to C:\hmpatest\ and delete the pendingfilerenameoperation key.

Essentially up until now, this is just extracting the files from the installer and moving the files and deleting the registry key responsible for making the switch from the old to new files on restart.

If this is just a test computer/snapshot you're happy to blow away if it all goes wrong you could just reboot and "all" the new files will be put in place.  I.e. the service, the driver, the dlls.

If you're being more cautious and interested which file specifically may have fixed it, you could replace each file as a test.

For example - If it's the DLL file that is significant, i.e the file injected into each process, you could rename: C:\Windows\System32\hmpalert.dll to C:\Windows\System32\hmpalert.dll.orig and copy in the new C:\hmpatest\Update Files\hmpalert_x64.dll and rename it to C:\Windows\System32\hmpalert.dll.  Is this enough, etc...

Maybe replace the driver, service exe, next etc...

Hopefully this makes sense.

Regards,

Jak

I guess it would be interesting to see if this fixes it?  Can you reproduce the issue reliably to know it helps?

As a test (ideally on a test computer but this should all be pretty safe) I would do as follows:

1. Check you don't have a pendingfilerenameoperation value under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\
If you do, reboot until it is gone.

2. Download http://test.hitmanpro.com/hmpalert3b734.exe to say C:\hmpatest\ but it doesn't really matter, I will just reference this location for guidance.

3. Open an Admin prompt in C:\hmpatest\ and run:
hmpalert3b734.exe /upgrade

4. The following location should be now populated with the new files:
C:\Program Files (x86)\HitmanPro.Alert\Update Files\

5. The registry key in step 1 will also be created with the entries to put the new files in place at restart.

I would then suggest moving the C:\Program Files (x86)\HitmanPro.Alert\Update Files\ directory to C:\hmpatest\ and delete the pendingfilerenameoperation key.

Essentially up until now, this is just extracting the files from the installer and moving the files and deleting the registry key responsible for making the switch from the old to new files on restart.

If this is just a test computer/snapshot you're happy to blow away if it all goes wrong you could just reboot and "all" the new files will be put in place.  I.e. the service, the driver, the dlls.

If you're being more cautious and interested which file specifically may have fixed it, you could replace each file as a test.

For example - If it's the DLL file that is significant, i.e the file injected into each process, you could rename: C:\Windows\System32\hmpalert.dll to C:\Windows\System32\hmpalert.dll.orig and copy in the new C:\hmpatest\Update Files\hmpalert_x64.dll and rename it to C:\Windows\System32\hmpalert.dll.  Is this enough, etc...

Maybe replace the driver, service exe, next etc...

Hopefully this makes sense.

Regards,

Jak

Is anyone still having an issue as long as the sign on option is disabled with the latest IX?

We have done several machines and as long as we disable that first we are good to go.

All our systems seem fine now after disabling the sign on. We still have our case open and escalated with Sophos though until it is fully resolved.

I was prepping a computer with a fresh Win10 install this week and the issue occurred when the sign on option was disabled.  So far, it only triggered the one time and I rebooted it at least 6 times.