none
Windows Key + X does not work in Windows 8

    Question

  • I have a number of machines that the Windows + X key combo does not work on, and right clicking the start menu (On the bottom left) does not cause the menu to appear either.

    Is there a computer or user based setting that disables this functionality? Any ideas how to fix this?

    Thanks!

    -Easton

    Friday, February 22, 2013 2:26 AM

Answers

All replies

  • Run Process Monitor and look at the result column of Explorer. Look what fails.


    Also make sure you don't have other software installed which registers this shortcut.


    "A programmer is just a tool which converts caffeine into code"

    Friday, February 22, 2013 5:59 AM
  • Any ideas how to fix this?

    Another diagnostic would be to see if the user can open the directory involved...

    %localappdata%\microsoft\windows\winx

    C.f.

    http://answers.microsoft.com/en-us/windows/forum/windows_8-files/menu-not-working-in-the-start-charm/dd056687-1da5-4834-bbaf-ad4c681a1ae6?page=4&tm=1361241337696

    Apparently it was enough for one user to just add a new item, so I still suspect a permissions problem but doing that may be an easy workaround instead of figuring out the real cause and fixing it accordingly.

     
    Note that I think there may be too much optimization being done to use ProcMon as we normally would.   In that case you should also record what happens when  explorer.exe  is restarted (e.g. via Task Manager, right-click Restart) since it is possible that any permissions issues might only be detected by ProcMon then.

     
    HTH

     
    Robert Aldwinckle
    ---

    Friday, February 22, 2013 7:17 PM
  • As an FYI it's a roaming profile environment.

    However, it looks like the WinX folder does not exist for the users that are encountering this issue.

    Placing the WinX folder resolves this issue.

    Any idea why the WinX folder doesn't exist in the local part of the profile?

    Monday, February 25, 2013 4:48 PM
  • Any ideas how to fix this?

    Another diagnostic would be to see if the user can open the directory involved...

    %localappdata%\microsoft\windows\winx

    C.f.

    http://answers.microsoft.com/en-us/windows/forum/windows_8-files/menu-not-working-in-the-start-charm/dd056687-1da5-4834-bbaf-ad4c681a1ae6?page=4&tm=1361241337696

    Apparently it was enough for one user to just add a new item, so I still suspect a permissions problem but doing that may be an easy workaround instead of figuring out the real cause and fixing it accordingly.

     
    Note that I think there may be too much optimization being done to use ProcMon as we normally would.   In that case you should also record what happens when  explorer.exe  is restarted (e.g. via Task Manager, right-click Restart) since it is possible that any permissions issues might only be detected by ProcMon then.

     
    HTH

     
    Robert Aldwinckle
    ---

    As an FYI, this answer was the solution, it fixed the issue perfectly. Thanks Robert!

    I would however be interested in understanding why the WinX folder would be missing from the Local appdata

    Tuesday, February 26, 2013 8:49 PM
  • What I noticed in my environment is that this is a result of Deploying a Default User profile from the domain "\\<domain>\NETLOGON\Default User.v2" that was originally created under Windows 7.  Copying out "\AppData\Local\Microsoft\Windows\WinX" from C:\users\default on a Windows 8 system to that domain Default Profile seems to fix the issue (at least for future users logging into Win 8/2012 systems) - although I'm not sure if other Win 8 features are affected by the same problem.
    • Proposed as answer by Randroid Monday, May 06, 2013 2:05 PM
    Friday, April 12, 2013 2:22 PM
  • This is clearly a bug in Windows 8(.1). Users logging on with a roaming profile are left with an incomplete local profile since only the %AppData% (AppData\Roaming) part is fetched from servers and %LocalAppData% (AppData\Local) is basically created empty on first logon from domain profile.

    The contents of %LocalAppData% belongs to the local machine and does not roam between machines when roaming profiles are used. The bug is within the code which creates the local profile on first logon. It simply omits the WinX folder and therefore the menu does not work.

    Nearly any software will just create contents in %LocalAppData% on the fly if missing but Windows 8(.1) seems not to follow this principle and leaves users with a non-working system. The same happens if users (or any tool/malware) either on purpose or accidentally delete the WinX folder. In general users can delete basically anything in %LocalAppData% but in this case Microsoft introduced a bug which leaves the Win+X menu broken rather than just restoring the defaults.

    For desktop users this is just annoying if they find their Win+X menu not working after some cleanup or accidental erase of some %LocalAppData% files but for Corporate users with roaming profiles it would leave you with a defective WinX menu for every single user.

    Clearly a bug.

    Wednesday, October 23, 2013 8:17 AM
  • Just noticed another issue with SkyDrive which might be related to the inability of SkyDrive to create %LocalAppData% files when missing (e.g. when roaming to new Windows 8.1 machine).

    See discussion on crashing SkyDrive here.

    Thursday, October 24, 2013 1:04 PM
  • I would like to share my temporary workaround for this issue which is deployed in my environment now.

    Actually it might be possible to also check for the %LocalAppData%\Microsoft\Windows\WinX folder in logon script and copy it from %SystemDrive%\Users\Default\AppData\Local\Microsoft\Windows\WinX if it does not exist. Though this check would have to be executed on each logon and might cause some delay. Moreover not everyone might use logon scripts and this bug might even occur in environments which do not make use of domain authentication.

    So I thought about a more elegant solution. Finally I was starting to use ActiveSetup to fix the issue on my machines. The following lines will add the ActiveSetup component (commands to be executed with elevated privileges):

    reg delete "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /f >NUL 2>NUL
    reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /v Version /t REG_SZ /d "1" /f
    reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\WinX-fix-%COMPUTERNAME%" /v StubPath /t REG_SZ /d "\"%ProgramFiles%\windows-8-fixes\fixWinX.cmd\"" /f


    This will initiate the execution of fixWinX.cmd for every user which logs on first to the machine and does not have ActiveSetup for component "WinX-fix-%COMPUTERNAME%" already applied. I have added %COMPUTERNAME% to the component name since this fix needs to be executed on every machine on first logon. It should not re-execute it on subsequent logons but needs to execute once per machine.

    The contents of fixWinX.cmd look as follows:

    @echo off
    
    :: When logging in with a roaming profile Windows 8.1 "forgets" to copy the
    :: "%LocalAppData%\Microsoft\Windows\WinX" folder to the local profile. As a
    :: result the Win+X menu does not work for those users.
    ::
    :: See <http://social.technet.microsoft.com/Forums/windows/en-US/161692bf-fa57-4ac1-b9b8-4e550ad9c987/windows-key-x-does-not-work-in-windows-8?forum=w8itprogeneral>
    
    if exist "%LocalAppData%\Microsoft\Windows\WinX" goto end
    if not exist "%PUBLIC%\..\Default\AppData\Local\Microsoft\Windows\WinX" goto end
    
    echo Copy WinX folder
    xcopy /S /C /I /Q /H /R /Y "%PUBLIC%\..\Default\AppData\Local\Microsoft\Windows\WinX\**" "%LocalAppData%\Microsoft\Windows\WinX"
    
    :end
    exit /b 0

    Of course this setup needs to be installed on all machines so it's best to pre-deploy it in Windows 8.1 deployment image.
    Saturday, November 02, 2013 8:17 PM
  • I can confirm this is a bug with Roaming Profiles and the Windows 8+ family of operating systems.

    The easiest method I've come up with to deal with this is a script which kicks in on user logon.  To do this, you need a GPO linked to your Workstation and Remote Desktop Hosts OUs, Loopback processing mode must be enabled (Computer Configuration > Policies > Administrative Templates > System > Group Policy: Configure user Group Policy loopback processing mode = Enabled), you must also force logon scripts to apply immediately upon logon (computer Configuration > Policies > Administrative Templates > System > Group Policy: Configure Logon Script Delay = Disabled), and the GPO should be focused to target only Windows 8, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2 via WMI filter (that is, if you have machines with other OSs in the same OUs).

    Script:

    xcopy %SystemDrive%\Users\Default\AppData\Local\Microsoft\Windows\WinX\*.* %LocalAppData%\Microsoft\Windows\WinX\ /S/E/H/D
    

    WMI Filter:

    select * from Win32_OperatingSystem where (Version like "6.2%" or Version like "6.3%") and ProductType="1" or ProductType="3"

    Monday, February 24, 2014 6:30 AM