Details: Clean Windows 7 Professional, Internet Explorer 9, fully updated. Hardware: HP TouchSmart, touch screen PC. Background: I am developing a custom shell for a touch screen kiosk PC. It utilizes touch gestures of Windows 7 in various places. I have changed the default shell of Windows from explorer.exe to MyProgram.exe. This question, however, is not about my own program or programming. (When I say "touch gestures" I mean things like scrolling controls by dragging them with your finger, touch-and-hold right click and pinch-zooming in IE) My problem: When logging in the user account (without explorer.exe set to run), touch gestures do not work. And instead of the little touch cursor (looks like a little dot), it shows the default cursor. After waiting ~2 minutes, it starts working: Gestures work and the cursor is changed to the little dot. This keeps working, until I log out and log in again, then the ~2 minutes wait time start over. My observations: As far as I can tell, no new processes are created just before it starts working (monitored with Process Explorer). Nor are any services started (Checked in Windows Event Viewer). I highly doubt, though, that services are the cause of this, because the ~2 minutes time is from user log in. The 2 minutes mark is pretty precise within +/- 5 seconds (loosely measured). If I, any time before the ~2 minutes mark, manually start explorer.exe, touch gestures work immediately. Even if I kill explorer afterwards, the gestures keep working. Explorer.exe must rush something upon starting? Do you know why there is this delay? Thanks!

Hi Michael, Please use an advanced monitoring tool named Process Monitor to trace the delay issue. ======================================================= Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. To do this, a. Download Process Monitor from the following link, and extract it from the zip file. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx b. On this affected server, double-click the Procmon.exe file (requires Administrators group membership) to start Process Monitor together, you will see it starting to capture events. c. While Process Monitor is running, please try to reproduce the issue. d. After this issue is reproduced completely, then switch to the Process Monitor window, Click File -> Capture Events to stop it. And then click File -> Save to save the log file. e. Analyze the Logfile.PML to find what has caused this delay issue. Hope it helps! Best regards, Ruby ChengPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Ruby Thank you very much! I hadn't thought of that. Just before it starts working, this happens: WISPTIS.EXE (responsible for touch functions) creates a couple of threads, then loads system32\uihub.dll, then it reads a bunch of relevant settings from registry (such as "TurnOffPenFeedback" and "FlickTolerance" among many other settings), does some more registry reading... and after that, touch gestures are working. So wisptis.exe is indeed doing some very relevant stuff! So thanks for helping me narrowing it down to wisptis.exe! Now I have a question: How do I find out what caused wisptis to "wake up" and do all of this? What triggered it? Wisptis is running when logging in. In other words, it is already running before it "wakes up" Again, thanks!

Hi Michael, Your question falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone Best regards, Ruby ChengPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.