Vertical scroll bar keeps jumping to the bottom of the screen

I'm now using a USB mouse. After about 1 hour of use, I have yet to see it exhibit the scrolling defect that was increasingly-frequent in my bluetooth mouse.

I dunno yet whether it's a hardware issue, or a software one (due to the difference between the driver-stack in a USB vs a bluetooth connection to a mouse). I'm thinking it's most-likely a hardware fault; anyway on my round-to-it list is to purchase another bluetooth mouse. I'll post my findings here.

Mice are not 100% reliable!

OK that's good. On my platform, the defect behaves differently. After a clean boot, without running my Outlook client, the scroll wheel started to misbehave after a few minutes of using Acrobat. Anyway: if you can reproduce the defect immediately after launching only Outlook after a full restart, I hope you'll take the time required to use the in-app defect reporting system in your Outlook client (assuming it has this feature). In my current build (in which I'm still avoiding the use of the "new Outlook" interface, as I'm tired of retraining my wetware to cope with novel requirements of software ;-), the in-app reporting is in the menu bar as a "Contact Support" button.

My current workaround *attempt* is to fiddle with the detailed mouse settings, getting a bit of joy in Acrobat by setting it to scroll only one line at a time. However the scroll wheel is still misbehaving badly in Firefox. I can't see any easy way to disable the wheel but AFAIK there aren't any UIs I'm using where it's absolutely required... and I now think of my mouse's wheel as an "attractive nuisance" which I'd have to retrain my wetware to avoid using!

Intriguing! Perhaps: the Windows server which is running your instance of a (remote) outlook client is misrouting the interprocess signals from its (remotely-hooked) mouse driver process?

Or perhaps some process on that server (and on my laptop) is generating spurious mouse scroll-down signals?

And/or perhaps there's a dll versioning problem in both "your" Windows server and my laptop which is the root cause of the confused signalling?

So many possibilities... and we're not gonna localise this defect in a chat stream! However AFAIK it's still nonreproducible -- occurring sporadically, often enough to be a major annoyance to users but quite-probably not often enough to be localised -- so I'm not gonna hold my breath for Microsoft to repair the defect. Instead I'll be trying to collect enough info about *my* platform's exhibition of this defect that I can create a defect report that'd be helpful to MS's QA team.

A (2002!) slideshow from Rational offers the following advice to QA teams when writing defect reports:

"Analyzing Non-Reproducible Errors

"Always report non-reproducible errors.

"If you report them well, developers can often figure out the underlying problem.

"Describe the failure as precisely as possible.

"If you can identify a display or a message well enough, the developer can often identify a specific point in the code that the failure had to pass through."

I have the same problem.

One more to add. Seems like it started the last week of May. Very annoying and not efficient for the end user.