Rage? Please.

First of all, I don't think you're correct. When I un-installed Logitech's software, it removed all registry references to iPoint and Mouseware, the "support" software that it installs. What it appeared to leave, however, were references to the bare Logitech driver for the wired Logitech mouse that I still use, i.e. just a standard driver USB wheel mouse driver with no frills. This, of course, supported my Logitech mouse just fine but, apparently, its presence was enough to "fool" the Microsoft software into thinking that the entire Logitech suite was installed, and it tried to uninstall it and crashed.

When I removed all the Logitech references, the Microsoft software installed but, not surprisingly, the wired Logitech mouse stopped working. I got it working again by updating the driver and allow the O/S to go "on line" to get it, i.e. it got the Logitech driver from Microsoft through the standard update process. After I did that, both the Microsoft and Logitech mice worked -- even simultaneously. This means two things:

1. The Microsoft software did not need to uninstall the Logitech driver, which was all that was left on my machine. If it was well written software, it would simply have disabled the driver during the install and the re-enabled.

2. However, I don't think even that needed to be done. Obviously, Microsoft knows about Logitech drivers -- it provides them! Clearly, Vista is quite happy with both drivers installed, so more than likely it didn't need to do anything about a driver that Microsoft already knows about.

My guess is that either this was sloppily written software or, more likely, it's another Microsoft marketing "feature" -- if you want Microsoft hardware it will, for no other reason, uninstall other manufacturers' hardware. Microsoft has pulled this kind of stunt before in the past and I don't trust it not to do it again.

On the contrary, I have. Off the top of my head, here are some companies whose tech support I've called within the last year:

1. Sling media -- no hold time, immediately connected to a knowledgeable tech who knew his company's hardware and software intimately, and was able to resolve a rather knotty problem that was the result of running dual monitors on a laptop in a docking station.

2. Highpoint -- no hold time, immediately connected to a knowledgeable tech who knew his company's hardware and software intimately and, though unfamiliar with the specific issue I had -- running a PCIe RAID controller on a thin client under XP embedded -- was able to provide me with sufficient information, suggestions and hints as to what was going on for me to figure out the problem myself.

3. Adobe -- minimal hold time (maybe 3-5 minutes), connected to first tier tech support who quickly (within a minute or two) determined that the problem I was having (CS4 was displaying white as a cream tint) was not due to what I would call "typical naive user errors," put me through to second tier, again with minimal hold time. I was connected to a knowledgeable tech who knew his company's software intimately, and was able to immediately resolve the problem.

These are all examples of good tech support that, each time, resulted in my spending no more than 10 or 20 minutes on the phone, and resulting in knowledgeable assistance and successful result.

Yes, but see #3, above. Adobe's first tier rep actually listened to me -- I told him the problem, but I also told him the steps that I had taken to resolve it. He asked me about one or two more and quickly determined that (1) I did know what I was talking about, and (2) I needed second tier assistance. My time wasn't wasted, I wasn't on hold for ridiculous amounts of time, and the end result was that I was put through to someone who solved the problem. I wasn't told that someone would call me within the next 3 days, but they couldn't say when.

Do you have 3 days free to wait for technical support for a mouse? It would have been a more efficient use of my time to take the Microsoft mouse back to the store, get my money back and buy another manufacturer's product. The only reason I didn't was I didn't feel like driving back to Fry's and dealing with THEIR return process, and I also took it as a personal challenge to get the $%*() thing working.


I only call tech support as an absolute last resort. However, as I said, I'm not an IT guy, just a geek with an expensive hobby, and I'd like to at least believe that the company that makes a product knows more about it than I do.

I'm willing to put it with first tier PROVIDED that, once you've proven to them that you know more than they, they don't screw around and pass you on to second tier. Even AT&T which provides my DSL in San Francisco and uses off-shore first tier techs does this for me.

It was perplexing. I searched on "ctor.dll" and "could not find module." It produced only 2 hits, and none were applicable. I also searched on "Presenter Mouse 8000," and found lots of people with the same problem I had, but very solutions were presented and those that were, e.g. "Try using restore to a point before you installed the conflicting software," were clearly not practical for me.

The problem, of course, was not with ctor.dll -- apparently, it's just a dll that gets called during a system-initiated uninstall. I did a search on just "ctor.dll" and found that a lot of people had problems with the dll not existing on their hard drive -- there were lots of links to download it. In my case, ctor.dll was exactly where the error message said it was. That's actually what clued me in -- it wasn't ctor.dll that the uninstall routine couldn't find, but the parameters passed to it. That suggested to me that the Microsoft only thought the Logitech software was installed, even though it wasn't. That, in turn, caused me to search the registry where I found the above-mentioned Logitech references, though none to the iPoint or Mouseware software.

And that's fine, though there should be a decision-point in the script that says, "Does customer understand the problem better than you? If so, skip steps 10 through 39 and forward directly to second tier."

Even if step 39 provides the answer, a knowledgeable customer will be so frustrated by having to answer, "Are you sure your computer is turned on?", that the company will already have poisoned itself.

If, by "they," you mean the first tier tech, he did and was patient with him . . . the first time I called. This was a Microsoft failure, not a failure of the person I spoke with (though the "supervisor" desperately needs a course on phone etiquette -- I'm not used to call center supervisors treating me like some kind of inferior menial).

See above. And, yes, I'm pretty tech-savvy and, at my company, I'm the person people come to when they want hardware and software recommendations. Do you think I'd recommend the Microsoft mouse?

I put myself through law school working in law library where I managed the library LAN and also provided computer support to the students. I'm well aware that the overwhelming majority of support issues are either user errors or naive users who really don't know what the big red switch on the side is for. First tier support is fine for this. The point, though, is that Microsoft first tier support would have failed completely for a naive user with the same problem I had and second tier support is so hard to reach that, even after 3 days, they hadn't bothered to call.

www.microsoft.com/hardware/vistaupdate

It has a link for a "reliability stack update" for the various versions of Vista and specifically lists the Presenter 8000 mouse. It links to a download page that, in turn, links to the support article. This is what it says under, "Symptoms":

You may receive a Stop error message that resembles one of the following after you resume a computer from sleep or from hibernation:

Error message 1:
STOP 127 PAGE_NOT_ZERO_NVIDIA_USB
This error occurs on a computer that uses 2 gigabytes (GB) or more of RAM and an nVidia nForce EHCI controller.

Error message 2:
STOP 0x1000007E usbhub.sys SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
This error occurs because of a race condition in the Usbhub.sys driver. This condition occurs if a USB device driver tries to enter a selective suspend state when a previously canceled selective suspend request has not yet been fully processed.

Obviously, this is not, in any way, relevant to the problem I was experiencing.

Yes! That's my point! It's just a stupid Bluetooth mouse.

First, as I've explained, I'm pretty sure that's not what happened. Second, Logitech mouse drivers aren't exactly obscure; Microsoft should be able to cope with Logitech software even if the Logitech uninstall was incomplete. Finally, I suspect that the only reason the uninstall routine is included in the Microsoft software is as a marketing ploy and has nothing to do incompatibility between the two products.

I Logitech mouse drivers installed -- the same Logitech mouse drivers that the Microsoft automatic driver update routine installed after I installed the Microsoft Intellipoint.

Oh, you were talking about Bluetooth stacks? My Vaio uses the Toshiba stack, but that's irrelevant. The stack is relevant to the receiver, not to Bluetooth devices that work with receiver. Microsoft's stack doesn't fully support all Bluetooth services, but Toshiba and Widcomm do. Regardless, the Microsoft stack will support a Bluetooth mouse.

That's the whole point of Bluetooth -- to provide a standardized interface for low-power radio links to peripherals.

Blue Soleil is sold with cheaper Bluetooth adapters. I don't particularly like it because of the user interface, but I've found it completely reliable. My Vaio has built-in Bluetooth, so I've no need to install any stack other than the Toshiba, which Sony provides OEM. On my Acer, I have a third-party Bluetooth adapter in one of the USB ports. It came with th Widcomm stack, which is the one that I prefer. Unfortunately, my Acer is in the shop, so I haven't had a chance to try to install the Microsoft mouse on it. I'll try when I get it back -- it's also been used with a Logitech Bluetooth mouse.

I think it's very clear. When I was researching ctor.dll, I saw a lot of examples of the proper syntax when it's called from another routine. ctor.dll requires an argument that includes, along with some switches, the qualified path to uninstall data originally installed by the third-party software. In this case it was obvious what was happening: either the incorrect argument was passed, or the correct one was passed but the uninstall data wasn't there. This makes sense, because it was removed when I ran Logitech's uninstall routine. This caused Intellipoint to crash with the "Couldn't find module" error message referencing ctor.dll. The module that it couldn't find wasn't ctor.dll, but whatever was referenced in the parameters that were passed to it in the argument.

If you look in Program Files/Common Files/Install Shield/Engine, you'll see one or more numbered subdirectories. These contain ctor.dll, along with a couple of other files. I found other references to this particular version of ctor.dll that were related to other software, though not Logitech. I'm going to guess that these subdirectories are something that the O/S creates for a program when it is installed for the first time. Install Shield is an O/S function.

See above. I can't say, 100%, this is what happened but I'm so sure I'd put money on it.

Try the search I listed above.

As I said, I found a number of hits in which people reported this problem.