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

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

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 frozenduring 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

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

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

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

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

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, 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

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

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

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.

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.

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.

Have you tried to see if this issue exists in Safe Mode?CESabarre Free Tech Support through Email.

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.

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.

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?

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.

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?

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