none
Slow On-Screen Keyboard start

    Question

  • On-Screen Keyboard, as well as Magnifer, takes about 30 seconds to start. Machine equiped with C2D E8500 CPU and 4 Gb of RAM.

    During On-Screen Keyboard startup two additional processes listed in Task Manager: consent.exe and utilman.exe, CPU consumtion is about 4%. Already checked for malware and have turned off all tray applications -- no luck.

    What the reason may be?

    Serge
    Friday, September 04, 2009 4:42 AM

All replies

  • Consent.exe is program of UAC, and utilman.exe is the program Ease of Access Center. 

    Please try the following method to disable all startup items and third party services when booting. This method will help us determine if this issue is caused by a loading program or service. Please perform the following steps:
     
    1. Click the Start Button type "msconfig" (without quotation marks) in the Start Search box, and then press Enter.
     
    Note: If prompted, please click Continue on the User Account Control (UAC) window.
     
    2. Click the "Services" tab, check the "Hide All Microsoft Services" box and click "Disable All" (if it is not gray).
    3. Click the "Startup" tab, click "Disable All" and click "OK".
     
    Then, restart the computer. When the "System Configuration Utility" window appears, please check the "Don't show this message or launch the System Configuration Utility when Windows starts" box and click OK.
     
    Please test this issue in the Clean Boot environment, if the issue disappears in the Clean Boot environment, we can use a 50/50 approach to quickly narrow down which entry is causing the issue.

    However if the issue persists in Clean Boot Mode, please let us know how many keyboard input languages you have installed. Because during the start process of the osk.exe the program utilman.exe need to check and include all the language input settings, the more input you installed, the more time it will consume to configure the settings. You may create a new test user account, only install one or two input languages and check the result again. 


    Arthur Xie - MSFT
    Monday, September 07, 2009 5:25 AM
    Moderator
  • Have tried clean boot and new user account, situation not changed.

    I think that the problem is in the consent.exe, it takes the longest time in startup sequence: consent.exe appears in task list for about 20 seconds, then utilman.exe makes its work in few seconds and osk.exe finaly starts. Start Menu is frozen during that time, except user picture box.

    There is another strange observation, if I try to start osk.exe from 32-bit applications, Total Comander for example, I get the "Could not start On-Screen Keyboard" message from osk.exe.

    Serge
    Monday, September 07, 2009 8:42 AM
  • Please try ShellExView.  

    Important Note: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

    Run ShellExView, in the pane sort the entries with manufacturers. Disable all non-Microsoft *.dll files, and check the result. If the issue does not occur, one of the files can be the culprit. We could narrow down it one by one.

    If it does not help, please try Process Explorer.

    Please run Process Explorer. Then run osk.exe. Then, in Process Explorer, click View->Show Lower Panes, and View->Lower Pane View->DLLs. Please then click on Explorer.exe, in the lower pane, check if there is any non-Microsoft dlls. Please let us know the information of the dlls. You may click File->Save As, save it to a text file and check files in it.


    Arthur Xie - MSFT
    Thursday, September 10, 2009 8:12 AM
    Moderator
  • There are no non-Microsoft DLLs in the list, but the problem still persists.

    Maybe startup time of 20-30 seconds is a design decision for Ease of Access features. The only question is why that time was significantly smaller (less than 5 seconds) during first week after Windows 7 installation.

    Serge
    Thursday, September 10, 2009 9:29 AM
  • It should launch promptly. Also considering that you cannot launch osk.exe directly, it is not a normal or by design behavior.

    An useful tool to help us track the process of launching on-screen keyboard. You may try Process Monitor.

    Process Monitor v2.6 

    There will be plenty of captured process. You may just check the processes related osk.exe, consent.exe and utilman.exe. Otherwise, run osk.exe directly until error message pops up. Then check the processes to try to find the reason why it failed to start.

    If the reason cannot be found from Process Monitor, we can try a simple way to repair the whole system. Please do an In-place Upgrade. It does not remove programs and personal data on your computer. However I still suggest that you backup your important data in the user profile folders before doing the repair.


    Arthur Xie - MSFT
    Friday, September 11, 2009 3:25 AM
    Moderator
  • Seems like consent.exe tries to connect to some strange hosts (like *.deploy.akamaitechnologies.com) in loop with 2-3 seconds delay between attempts while firewall blocking them. Is that normal?
    Serge
    Friday, September 11, 2009 9:09 AM
  • I think I may be having a related problem.  I'm trying to run osk.ex from a C++ program (which is running with admin privileges I think as UAC is turned off, VC++ has (Administrator) in it's title bar too.

    ShellExecute( NULL, "open", "osk.exe", NULL, NULL, SW_SHOW );

    Pops up an error dialog (in the background strangely) which says: "Could not start On-Screen Keyboard".  Is this related?  Any ideas?

    Thanks,
    Jesse
    Tuesday, September 15, 2009 7:49 AM
  • Hi,

    I suspect that spyware exists on the computer. You may google  *.deploy.akamaitechnologies.com and can find much information regarding it. Please run Windows Defender to see if it can help.


    Arthur Xie - MSFT
    Tuesday, September 15, 2009 10:21 AM
    Moderator
  • I think I may be having a related problem.  I'm trying to run osk.ex from a C++ program (which is running with admin privileges I think as UAC is turned off, VC++ has (Administrator) in it's title bar too.

    ShellExecute( NULL, "open", "osk.exe", NULL, NULL, SW_SHOW );

    Pops up an error dialog (in the background strangely) which says: "Could not start On-Screen Keyboard".  Is this related?  Any ideas?

    Thanks,
    Jesse


    Hi Jesee,

    Can you open osk.exe manually? If so, this issue should be different. In this case please create a new thread and discuss there in order to avoid confusion.

    By the way, if manually running the program does work, the most possible cause is the program itself. If you can control the code of the program, I suggest you create threads in our MSDN forum.


    Arthur Xie - MSFT
    Tuesday, September 15, 2009 10:23 AM
    Moderator
  • Same symptoms as here, but applied to consent.exe and Windows 7. Even some of the hosts are the same. Should I trust the reply marked as answer in that topic?

    Have scanned system with Windows Defender, AVG and ClamWin, no threats found.

    By the way, I use standard Windows Firewal in advanced security mode.

    Serge
    Tuesday, September 15, 2009 3:24 PM
  • When creating a new set of Windows 7 images, I encountered this same 30 second or so delay with starting the built-in On-Screen Keyboard and I just have the English language installed.  I was also able to duplicate the problem on a whole another machine with a clean boot enviroment as well as on a clean machine.

    It did require a specific set of conditions though.  I needed to have UAC enabled and no Internet access available.  If I disable UAC -or- disable the network connection, then the OSK launches promptly.  Also, if I provide Internet access, there's a similar delay initially, but then the OSK launches promptly on subsequent attempts.

    These conditions are also going to be the norm for a lot of these computers, so I would like the issue investigated further.  Especially since spyware isn't the case here.  Appreciate the help then and thanks in advance.

    Friday, August 13, 2010 9:13 PM
  • It's been a couple weeks and I am still experiencing the OSK delay as described above, so I'm hoping to get a response on the matter.  Thanks again in advance.

    Thursday, August 26, 2010 12:45 PM
  • Since I wasn't making any progress with this forum posting, I've recently opened a technical support incident with Microsoft and am currently working with them to resolve the issue.  I'll let you know the outcome of that investigation.
    Monday, September 27, 2010 4:46 PM
  • Have you tried to see if this issue exists in Safe Mode?
    CESabarre Free Tech Support through Email.
    Monday, September 27, 2010 7:18 PM
  • Recently ran into this issue when testing our Windows 7 Embedded OS image. Took the master image and installed it on two (supposedly) identical pieces of hardware. One version of the image has the 30 second delay prior to showing the OSK and the other does not. Still trying to isolate the source of this issue and will update with my findings.
    Wednesday, December 15, 2010 7:30 PM
  • Sorry for taking so very long to update this thread, but as planned, I worked with Microsoft last fall about this issue during which they were able to duplicate the problem, identify the cause, and supply me with a workaround.

    This is actually a known issue that goes back to Windows Vista (see http://support.microsoft.com/kb/940856) and the delay can occur when any digitally signed EXE file tries to validate the certificate revocation list (CRL) for the signed EXE file.  This also explains why, as mentioned previously, I only observed it under a specific set of conditions.

    Therefore, Microsoft's suggested workaround is to configure a valid proxy server for the local system account. One can do this by running the following Administrative command at a Command Prompt:
     
    netsh winhttp set proxy <ProxyServerName>
     
    where <ProxyServerName> is the name of a valid proxy server (e.g.proxy.microsoft.com).

    Unfortunately, given the viability of a workaround, Microsoft would NOT issue me a hotfix for Windows 7 even though one had been previously been generated for Windows Vista and then included with Windows Vista Service Pack 1.

    By the way, one can remove this workaround by running the following Administrative command at a Command Prompt:

     netsh winhttp reset proxy

    Again, sorry for the delay, but I hope everyone finds this information helpful and accordingly I'm going to propose it as answer to the problem.

    • Proposed as answer by Bryan Bridges Friday, February 11, 2011 2:00 PM
    Friday, February 11, 2011 2:00 PM
  • Sorry for taking so very long to update this thread, but as planned, I worked with Microsoft last fall about this issue during which they were able to duplicate the problem, identify the cause, and supply me with a workaround.

    This is actually a known issue that goes back to Windows Vista (see http://support.microsoft.com/kb/940856) and the delay can occur when any digitally signed EXE file tries to validate the certificate revocation list (CRL) for the signed EXE file.  This also explains why, as mentioned previously, I only observed it under a specific set of conditions.

    Therefore, Microsoft's suggested workaround is to configure a valid proxy server for the local system account. One can do this by running the following Administrative command at a Command Prompt:
     
    netsh winhttp set proxy <ProxyServerName>
     
    where <ProxyServerName> is the name of a valid proxy server (e.g.proxy.microsoft.com).

    Unfortunately, given the viability of a workaround, Microsoft would NOT issue me a hotfix for Windows 7 even though one had been previously been generated for Windows Vista and then included with Windows Vista Service Pack 1.

    By the way, one can remove this workaround by running the following Administrative command at a Command Prompt:

     netsh winhttp reset proxy

    Again, sorry for the delay, but I hope everyone finds this information helpful and accordingly I'm going to propose it as answer to the problem.

    Hi,

    again thanks for your answer, but do be honest, I do not really completely understand it. :) First of all, the KB article you refer to is about a problem in Windows Vista, which is claimed to be fixed in Vista SP1 already, and should not reoccur in Windows 7, right?

    The next thing I understand is that you suppose that the delay is caused, because some process (which one?) tries to connect to the internet. So you need a proxy for the system account, but which proxy should I enter? I have a machine that is supposed to have no internet connection at all.

    Besides, I am talking about the onscreen keyboard not appearing in time for the logon user, i.e. the keyboard that is supposed to be displayed before the user logs on to Windows 7, which I currently can turn on and off in (Powershell syntax):

    Set-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Accessibility"  -Name "Configuration" -Value "osk"

    Again to explain what happens here:

    -> I have a system running Win7 x64 that has two users, both require a login password, and therefor they need a onscreen keyboard before logon

    -> my system is not connected to the internet

    -> It takes around 55 seconds for the OSK.exe to appear on screen after the logon screen is visible, which is inacceptable for our customers

    I am really willing to try lots of things to solve it, but please explain to me what I can try.

    -> Which Windows-process is actually responsible for bringing the OSK.exe up for the logon user? Can I change its priority?

    -> Which other processes are started before, and which of them could cause this problem?

    -> If a signed EXE trying to connect to the web cause the problem, what could I enter as a proxy for an offline system?

    Friday, February 24, 2012 5:13 AM
  • The issue was originally found & fixed after Windows Vista's release, but unfortunately that fix was not ported to Windows 7, so the problem continues there and our only solution in this scenario of not having Internet access is this proxy setting workaround.

    Since you won't have Internet acccess though Erik78, it doesn't matter what you enter for the proxy server, so the suggested one of "proxy.microsoft.com" is as as good as any other value.  With that in place, the OSK will launch promptly.

    • Edited by Bryan Bridges Monday, February 27, 2012 3:55 PM Minor correction.
    Monday, February 27, 2012 3:52 PM
  • Hi Ryan, thanks again for your explanation.

    I have now found some time to work on that problem again, and the situation is really annoying: even though I entered a proxy for the systemuser (as suggested proxy.microsoft.com), the startup of the osk.exe for the first login after the system was rebooted is still very slow, takes 30-55seconds, depending on the machine.

    Is there any chance to figure out which process actually is slowing the whole process down?

    Wednesday, March 07, 2012 1:37 PM
  • I add that the same problem:
    I use a CNC machine connected to a network without internet
    the keyboard functions correctly until I connect to the machine, at this point, the keyboard is delayed by about 30 sec. even if I get disconnected, if I disable the network card and everything works correttaente rehabilitated until I connect to the machine, you can solve this annoying problem?
    HOME or professional win7 32 64-bit does not change.

    Deni

    Wednesday, July 04, 2012 2:50 PM
  • I was experiencing the same problem on all of the machines in my environment and was able to narrow things down a little bit.  First off, my network consists of Server 2008R1, Server 2008R2 and Windows 7 Machines.  We were seeing the Slow launch (~45 Seconds) for the Magnifier and the On-Screen Keyboard on all of the machines, so I did some testing. 

    First off, all of the machines will launch the OSK quickly with a clean O/S install until I configure networking (without an internet connection), at which point the Slow OSK Start problem occurs.  Using input from this forum I was able to determine that as long as my computers were configured as part of a workgroup, that I could fix the slow OSK problem 3 different ways.

    1. Use device manager to delete my NIC card. (obviously not a good fix)

    2. The proxy fix: i.e. from a command prompt C:\> netsh winhttp set proxy proxy.microsoft.com

    3. Completely Turn off User Account Control (UAC)

    I also found that this changes if your computers are members of a Domain.  I think deleting the NIC still works, but I did not try it.  The proxy fix no longer works.  The computer will take and remember the proxy setting, but the On-Screen Keyboard will still take ~45 Seconds to Start.  Disabling UAC still works though.  The Default Server 2008 Domain Settings fully enable UAC for all members, and therefore the OSK will be slow to launch (unless you are connected to the internet, in which case it is fine) The OSK can be made speedy again by Turning off UAC on each local machine, but if your Security Settings prevent the users from Disabling UAC then disabling the following group policy setting will effectively do the same thing and your OSK will speed up. 

    Under Security Options the setting to change is:

    User Account Control: Run all administrators in Admin approval mode = Disabled.

    As long as the domain member computers have been running long enough for the Action Center to be online, you can then run from the command line c:\>gpupdate /force and the action center will tell you to reboot to turn off UAC.  Reboot and walla, a fast On-Screen Keyboard (and Magnifier)

    What a pain.  Hey MS please fix this.

    Jason

    Wednesday, August 08, 2012 11:11 PM
  • I know it's an old thread, but I wanted to reply with my solution, to hopefully help anyone else experiencing this problem.  Same symptoms - On-Screen keyboard takes 15-20 seconds to launch (I am launching it from inside a dotNET 4.0 app).  The computer is Win7 32 bit on a factory automation network without internet access.  Setting the proxy server did work, but was unacceptable because it broke other essential networking applications.  What worked for me was turning off "Automatically detect settings" in Internet Options -> Connections -> LAN Settings

    • Edited by bvandrasik Monday, October 29, 2012 9:39 PM
    Monday, October 29, 2012 9:39 PM
  • >>>What worked for me was turning off "Automatically detect settings" in Internet Options -> Connections -> LAN Settings

    Thank you a lot, great solution.

    Tuesday, January 21, 2014 11:01 AM