This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows Start Menu Locked Up, unable to restart machine.

Have a situation where installing SOPHOS causes the Start Menu of Windows 10 1709 to stop working, also seems to stop all "User Experience" things, such as Settings Page etc. When you try to restart, you get the error:

task host is stopping background tasks windows 10 Device install reboot required

You have to hard kill it to reboot/shutdown the machine. 

This is a fresh installation of USB
Installed Acrobat Reader, Media Player classic, Irfran View, GreenShot, Chrome and Java.

Used the new Deployment from SOPHOS MSP Admin Console and the "Download Complete Windows Installer"

Used the following command to install:
SophosSetup.exe --customertoken="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx" --mgmtserver="dzr-mcs-amzn-us-west-2-fa88.upe.p.hmr.sophos.com" --products="antivirus;intercept" --quiet

I seem to be able to "jostle" the start menu by right clicking on the start button.  

At this stage, I am unable to install SOPHOS AV



This thread was automatically locked due to age.
Parents
  • 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

Reply
  • 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

Children