Mouse stops responding within User Session (Win 7)

So I'm having this little problem that's preventing me from getting some work done, and I'd like to resolve it without a reinstallation of Windows (if possible).

I originally posted about this issue on the forums I usually hang out on: http://fearless-assassins.com/topic/70595-mouse-stops-responding-within-user-session-win-7/

This is also similar (but not exactly the same) to a problem posted on the TechNet forums: https://social.technet.microsoft.co...active-window-wont-respond-until-ctrl-alt-del

Here's the problem in a nutshell:

Launching Visual Studio Professional 2013 U4, Microsoft Expression Web 4, RivaTuner, Tropico 5 Launcher, or the EvolveHQ IM client causes the mouse to stop responding to any input whatsoever. No movement, or clicks are registered. The issue is somewhat replicated in the Expression Ultimate 4 installer, however the mouse responded while the installer window was active (the topmost or selected window).


I can temporarily re-gain control of the mouse by entering the Windows Security screen (Ctrl+Alt+Delete), however once I click Cancel to return to the Desktop, the mouse freezes up again. I have found that if I Log Off, the mouse works normally again, and I can log back into my User Profile and the mouse will continue to work perfectly until I launch one of the affected programs.

I have found that the issue is still present while booted into Safe Mode. MouseKeys do not work while this issue is present. The device manager does not show any device errors while the issue is present.

The good ol' hardware specs:

-Gigabyte GA-78LMT-USB3 Rev 5.0 Motherboard

-AMD FX-8350 CPU

-Crucial Ballistix Sport RAM- 1x8GB DDR3

-AMD Radeon R7 250 GPU

-Windows 7 Professional x64

-Roccat Isku FX Gaming keyboard

-Logitech G700s Gaming mouse

This is what I have tried (so far) to resolve the problem:

• Using a different USB port, on a different hub
• Using the mouse in 'wired' and 'wireless' modes
• Reinstalling the mouse driver
• Reinstalling the keyboard driver
• Updating my Chipset driver
• Updating my USB controller driver
• Running SFC
• Running Tweaking.com's Windows Repair Utility

I have also tried using a different mouse, with the same problem replicated. I am unsure whether all of the Logitech mouse drivers were removed before trying the second mouse, however.

There was once that I was able to regain control of the mouse, and have it work while Visual Studio was running.

Per usual, starting VS 2013 froze my mouse input, so I used keyboard controls in Visual Studio to launch Spy++ 64-bit. I set it to monitor mouse inputs, and it ran for awhile. I moved my mouse around, clicked some buttons, and noticed that there was no output in the Spy++ console/log, such as a WM_MOUSEMOVE call.

This was followed by an error message from Spy++, saying that a problem had been encountered in the Message Hook, and it had been disabled to prevent the system from hanging. I had to press [Enter] to acknowledge the dialog box, but after I did that, the mouse started to respond again.

I'm at my wit's end as to how to fix this problem, and nobody at Bleeping Computer has offered to help after over two months of waiting, so I've come here.

I've got a background in Windows and speak tech, so feel free to ask for more details or for any logs (DDS, FRST, USBTrace, Combofix, etc). MSE, MBAM, and MBAR scans have come back 100% clean.

Thank you so much in advance!

 

Looks like I made a bit of a typo there... :innocent What I meant was that I tried a different port which is on a different controller. The mouse is plugged directly into the computer; it shows up under a different root hub.

 

When the mouse stops responding, unplug it from the USB port, wait a few seconds, and plug the mouse back in. Is it still unresponsive?

 

Hey, it's all good. I was pretty unclear, and sometimes my phrasing in English just well... kinda flops. LOL

Unfortunately, the mouse cursor and buttons still have no response.

I've tried a few various things to troubleshoot, and here are the results:

1. Deleting the drivers, and using the Windows generic ones.
2. Deleting the drivers, reinstalling a fresh set.
3. Unplugging the mouse, removing battery.
4. Changing ports, moving from USB2 to USB3 controller.
5. Unplugging the mouse, and replacing it with another USB mouse.
6. Rebooting the computer with another mouse plugged in.

...All of which make no difference. The mouse stays unresponsive.

Now when I unplug the mouse the Device Removal sound plays, and the same things happens vice-versa when I plug it in. The Device Manager also updates, so everything seems normal as far as the rest of the OS responding.

 

Do you mean when you plugin the mouse, drivers are installing?

 

No, the device list updates akin to if one clicked "Scan for hardware changes".

 

You've done so much and I'm really stumped. This is a long shot (2) but worth a try.
1. Click Start > All Programs > Accessories > System Tools > System Information. Check the status of everything is OK.
2. Turn off the PC, unplug from the power outlet, open the case, and remove the CMOS battery. Check the voltage - it must be 3.0V. If it's fine, put it back after about 10 minutes.

 

I just checked the status of everything in the Hardware Resources, everything is reporting back as "OK".

You know, it's interesting that you mention the CMOS battery... I once worked on a server for someone, and it ran just fine until it was unplugged- after that, it wouldn't even turn on (that's why they brought it to me). I went through PSU tests, swapping components, you name it. The culprit? The darned CMOS battery.

I'll test the battery and let the caps drain on the motherboard, and see if it makes any difference.

 

Xernicus...

Seems like it's hardly ever this, but could this be related to your security software? This is what makes me think it could:

It sounds like experiences I have had with Comodo Internet Security when it is trying to make a decision, only I wonder if one of your security programs is trying to block a service of another one. Comodo couldn't even be turned off fully, and you might have a couple of security programs like this. So, if this happening, maybe it could be security programs fighting each other.

Anti-keylogging features can cause problems if you have the feature enabled in more than one program and then if one of them sees the other as a keymonitoring risk. Like your Spy++ output could be seen on some level as key monitoring by another security program. Spy++ wouldn't even have to be running (the GUI), if there is a service associated with the program...