Dell MOCZUL mouse issue

I have put up this page in the hopes of helping anyone else that has seen weird sleep issues when a Dell MOCZUL model mouse is attached to your system. The unfortunate part is that I have no simple solution except to replace the mouse with a different make/model.

We replaced a lab of 21 Lenovo Thinkcenter M90 PC's (model 3853-RZ4) in mid December 2016. The new systems were Dell Optiplex 7040 SFF with 24" Dell panels, Dell keyboards, and Dell MOCZUL mice (part# 01KHD8). We imaged these with a custom built Windows 7 image. These systems are set to "high performance", no system sleep, panels set to sleep after 45 minutes, and the ".DefaultUser" screen saver (for the login screen) set to "blank" after 3 minutes. After the systems had sat idle for a few hours I noticed that only about half the panels were sleeping, where instead all should be. And some would come out of screen saver or sleep back to the login screen. Very atypical behaviour!

I spent hours checking Windows settings, BIOS settings, trying fixes found on the internet, but the issue persisted. It was when I disconnected the mouse and keyboard that the panels went to sleep. The problem was finally isolated to the mouse... it was doing something to prevent panel sleep. The original Lenovo mice never had this problem. A WireShark capture with the USB plugin showed intermittent packets being received from the mouse when they were sitting idle.

2----5093.301997-----2.3.1----host----USB----32----URB_INTERRUPT in
3----8550.278919-----2.3.1----host----USB----32----URB_INTERRUPT in
4----9848.094253-----2.3.1----host----USB----32----URB_INTERRUPT in
5----11740.561620----2.3.1----host----USB----32----URB_INTERRUPT in
6----11858.808830----2.3.1----host----USB----32----URB_INTERRUPT in
7----12695.555248----2.3.1----host----USB----32----URB_INTERRUPT in

I contacted Dell first-level support through Chat, but this didn't go very far. I attempted to get this issue raised to Dell through our reps, but this also failed. Since I never found a resolution, I simply pulled all the Dell mice and replaced them with the old Lenovo mice, and the panels slept fine.

Fast-forward a few months to April 2017... still no resolution and a second lab of Lenovo's are being replaced. Once again I see the sleep problem caused by the MOCZUL mice. Still no resolution, so I install the Lenovo mice and move on.

Fast-forward now to September 2017, and this issue is still gnawing at me. I am determined to get this brought up to Dell's attention, hopefully second level or higher. The earliest MOCZUL date code mouse I could find was 02-2016 (Feb 2016), and the latest was 05-2017 (May 2017), a 16 month span. Now I have about 5 different production dates to test. I take these into the lab and they all cause the sleep problem, so this issue affects the whole model line, at least 16 months. I also tested some other Dell mice like the MS116T and the 4K93W (which from the top looks identical to the MOCZUL) and these all work fine.

The best part in all this is that the mouse also affects non-Dell systems. I set up a Lenovo Thinkcenter M90 on my bench with a MOCZUL mouse and Wireshark captured the USB results. It also caused the same issue on the Lenovo system. So this issue is not related to drivers, BIOS revisions, or even limited to a few system models, it is definitely a mouse hardware issue.

One of the last tests I did was also the most telling. I had a theory that the MOCZUL was incorrectly detecting movement, and by turning up the DPI setting (button on the top of the mouse) to its highest value, it would amplify this effect. I reinstalled the Dell MOCZUL mice and turned up the DPI switch so all mice were set to 1600DPI (very fast movement). I then let the systems go idle and watched them for 120 minutes. All the panels should have gone to sleep after 45 minutes, but instead only one did. Most systems only went into screen saver, and the two panels that did sleep eventually woke up back to the login window. This test proved my theory!

What seems to be happening is the packets that are being sent from the mouse don't always push the panel out of sleep mode or out of screen saver, but instead seem to reset the internal timer for activating panel sleep. Sometimes they are enough to stop sleep, or screen saver. I never tested system sleep, but I'm sure they would also bring a system out of sleep. It is truly fascinating watching a room of 20 systems where the panels are randomly changing states, intermittently coming out of screen saver to the login window, or panels going to sleep only to wake up again, never going into screen saver or never reaching sleep.

So far I have found MOCZUL mouse part numbers 01KHD8 and 049TWY. These mice all seem to have the same hardware ID of VID_0461 PID_4D51 REV_0717. They all fail.

As of late September I have finally reached someone at Dell above level 1, and am in the process of diagnosing the issue.

I am completely convinced that the entire production run of the Dell MOCZUL mouse has a design flaw and must be recalled and replaced. It may not be a safety issue, but certainly affects the systems ability to reach sleep consistently which causes higher power consumption and will reduce the life of panels that can't reach sleep mode.

UPDATE Nov 17, 2017: Putting the mouse on a rough nylon mousepad really brings out the issue. In our training labs all the mice are on mousepads, but I've been testing on an anti-static mat when on my bench. Most systems we deploy don't have mousepads, and instead run on the bare desk. The training lab has angled keyboard/mouse trays and we always use pads to keep the mouse from slipping off the tray, and to prevent the mouse feet from scratching the tray. Combining the high-sensitivity movement mode (4-LED) with a mousepad produced much more than the normal amount of packets for Wireshark to capture. I saw about 340 packets in about 2 hours, compared to about 60 packets in 6 hours on the same mousepad but running in normal sensitivity mode (1-LED).

University of Waterloo Home | IST Home | Last updated: Nov 17, 2017