I've got this really weird thing I'm running into in my software testing that I don't understand at all. I'm wondering if any of the Windows devs on the board have seen this?

Preface: I spend my day mostly testing how our software interacts with other software and hardware on the same system. In this particular case, I'm testing our software against the Verizon VZ Access Manager (VZAM) software. (VZAM is what's called a "connection manager", the app you use to connect your wireless card to the wireless carrier). One of our tests is to make sure that our software is reading correct and current data (such as the RSSI signal strength) from the Verizon wireless card plugged into the system, and that our data generally agrees with the data VZAM gets. Our software talks directly to the card, just like VZAM talks directly to the card.

So I've got automation that screen-scrapes VZAM and reads the RSSI values from it. Later, the idea is to compare those values to the values that our software has recorded, to make sure that we don't have a bug in the way that we're reading the card's data.

But here's the funny thing. On one particular XP system, VZAM sometimes goes "stale", reporting the same RSSI value over and over again forever. If you know anything about wireless, you'll know that the signal strength constantly fluctuates, even for a device that's standing still. So a "stuck" RSSI is an indication that something's not functioning as expected, and is flagged for closer investigation.

I've discovered that, on that system, when VZAM is stuck in this state, if I move the mouse or use any keystrokes of any kind, then VZAM suddenly starts getting varying RSSI data again as expected.

Aha, so I says to myself. I simply need to edit my automation tool to do some mouse moves and keystrokes to get VZAM to refresh properly.

But here's the weird part!! I can write a program that does automated MouseMoves and clicks and keystrokes like crazy, and VZAM still stays stuck, as if I had never moved the mouse. I can sit there and watch my automation minimize and restore VZAM, watch the mouse pointer move to the corners of the application, and even watch the mouse pointer hover over the signal strength indicator to get a balloon pop-up showing me the raw RSSI values (which are still stuck at the same value). I can watch it do all of those things, over and over again for hours, no change.

And then, at any time, all I have to do is give the mouse, the physical mouse itself, the slightest little move, and bam, suddenly VZAM wakes up like a kid on Christmas morning and starts giving me fresh data. Same thing with a keystroke: I can press the exact same keys that my automation was already clearly doing with SendKeys commands. As soon as I physically press a key, suddenly everything works.

In other words, I have a program that responds differently to actual physical input than it does to simulated input. How is that even possible?

Here's a concrete example. If VZAM is in this "stuck" state I described... If I press CTRL-K in VZAM, it opens up the diagnostics window where I can see the raw RSSI values. If I do this via the actual physical keyboard, VZAM becomes unstuck and gives me fresh values. If I do this via a piece of software automation with SendKeys, the diagnostics window still opens (so I know that VZAM got the keystroke) but the values are stale, stuck at the same values they've been for the last hour.

It's the weirdest thing. How is it that this can be possible? From the Windows operating system level, what's different about sending keystrokes and mouse movements to an application physically versus via automation? Anyone know?

It's interesting how sometimes you need to organize your thoughts by writing them down. Reading back over what I wrote above, I have a new theory to test: Maybe VZAM isn't the thing that's stuck. Maybe VZAM is right, and it's the card itself that's stuck, i.e., somehow the card or its drivers is responding to actual hardware idle time. I need to investigate that.

It's likely because this has nothing to do with the cursor movement or interpretation of keystrokes by software, but something to do with USB/HID. You won't see the issue (or the solution to your issue) until you exercise something on the bus itself - which could also include BlueTooth.

If you have any software that accesses some other USB device, try sending some traffic over an endpoint to see if you get the same results.

I was going to suggest something with USB also. Your mouse/keyboard simulator won't be generating USB traffic

Can you test on another machine preferably with different USB hardware/drivers?

I assume the Verizon "card" is USB?

Yeah, the Verizon card is USB. I'm going to head down this road of investigation. Thanks, guys!

I was actually thinking lower-level than that. It may just be that something is generating hardware interrupts. If the USB thing doesn't pan out, maybe play with something else that will generate interrupts, like a real COM port.

Alternative solution: small motor pressing and releasing the shift key

Or maybe a dippy bird?

If it is good enough for Homer...
http://www.youtube.com/watch?v=oQkSOcPLfP4

An old CPU fan, with some white-out on only one of the fins, with the optical mouse sitting atop it, solves the issue.

But I still wonder why it happens at all in the first place.

Your Verizon app is getting hung up on something. Software issue, USB driver issue, etc..

+1.