Windows 7: Shift and Control (not Caps Lock) Key Stuck On - Slow Keyboard Response

I had a problem, in Windows 7, that apparently afflicted Windows XP users as far back as 2005.  For some reason, on a system that did not previously have this problem, I would be typing along and suddenly thE DAMN THING WOuld start and then maybe stop typing in all caps, like that.  A search indicated that a fair number of people were having this problem.

There was the usual assortment of suggested solutions.  One was hardware, notably the keyboard.  I had replaced keyboards and found that didn't solve the problem for me -- not to mention that I was having the same problem, arising at about the same time, on two different computers.  Some observed that rebooting would fix the problem, at least temporarily.  If that was working for me, I would have to emphasize the "temporarily" part.  Some noted that Control Panel > Ease of Access Center > Make the Keyboard Easier to Use might be set to turn on Sticky Keys.

These were not solutions fo rme.  I did a virus scan and found no problem.  It seemed that some rogue program may have screwed things up.  I might eventually figure out which one.  If not, one solution would be to roll back to an earlier System Restore.  But System Restore was not functioning well; I had only a few recent restore points, not predating the problem.  I could do an image restore from some weeks earlier, but I was hoping for something less drastic.

There were some other, funkier suggestions.  One involved a sort of phantom limb theory, like when a person has a bad itch on his/her right arm but cannot scratch it because the arm has been amputated.  The concept here seemed to be that Caps Lock was on when an external or alternate keyboard was removed, so now the computer was still feeling the pain of that setting, and the solution was to plug in that other keyboard and turn off the Caps Lock.  That seemed possible; I had recently plugged in a USB keyboard because my PS/2 keyboard was not responding during a reboot with a certain kind of boot disk.  But trying again with the USB keyboard, with or without the PS/2 keyboard, after reboots, did not seem to fix the problem.

Two other suggestions offered simple solutions.  One suggestion was just to use the other shift key once.  That is, I always used the left-side Shift key, so now I used the right-shift key one time.  The other suggestion was to bring up the On-Screen Keyboard and click once on each of its two Shift keys.  Together, these two suggestions seemed to say that the solution was to use each Shift key on a keyboard, whether physical or onscreen.  (The onscreen keyboard was at Control Panel > Ease of Access Center > Use the Computer without a Mouse or keyboard.)  I found that the physical keyboard solution seemed to work, but only temporarily.

As this problem went on, I learned more about it. It wasn't only the Shift key. It was also the Control key. It seemed to be a problem of slowness. The computer was processing Shift and Control keypresses belatedly. For instance, I would select several files in Windows Explorer, using the Control Key; and then, when I would try to select another one, if I didn't allow time for the system to process the Control keypress, clicking on an additional item would deselect all the others.

A search led to the suggestion that I should see if I had the same problem when using the onscreen keyboard. This seemed impractical, since (as I confirmed in a brief trial) I would not have the same feel through the Onscreen Keyboard (Start > Run > osk.exe). It was also suggested that I see whether the situation persisted in Safe Mode. If there was no problem in Safe Mode, then the prescription would be to perform a clean boot.

It seemed the problem might be due to my KVM (keyboard-video-mouse) switch.  That is, I had one keyboard for two computers.  I switched back and forth by using a hotkey.  It was an IOGear PS/2 KVM.  Right around this time, I did variations on having the KVM connected to only one computer.  My notes are imperfect, but it seemed that this may have made a difference.  I did replace the KVM around that time as well because it was defective, so maybe this stemmed from that.

I also reinstalled Windows 7 around this time.  Maybe that was part of the solution too.  Not sure.

A Two-Computers-Per-User Desktop Arrangement

I was spending a lot of time at my desk, doing word processing and other typical desktop work.  For this purpose I was using a customized Windows 7 installation on two networked computers for maximum productivity.  This post describes that setup.

I had previously thought that, ideally, I would have four computers:  one laptop; one test machine to hook up the occasional hard drive or other component for wiping, testing, etc.; and two desktop machines running side-by-side.  Since then, however, I had switched from Ubuntu back to Windows and had found this to be a good move.  So now I was doing very little testing and tinkering with hardware.  Therefore, I dismantled and sold the parts from the fourth computer.

With almost all of my work happening on just two computers, and with a stable Win7 installation on each, the focus now was on getting the most out of them.  I was using two desktop computers instead of one because there were still many occasions when a computer would experience downtime.  I would be doing drive maintenance or imaging, or would still have to reboot Windows now and then to clear its head or to complete a program installation or upgrade, or Win7 would be running just fine but there would be some scanning or something else going on that would tend to monopolize the machine for practical purposes.  I was not yet very impressed with multiple desktop software and was considering a return to VMware or some other virtual machine software, perhaps in a virtual appliance, though I wasn't sure I wanted to get back into the performance issues that had prompted me to try to use a native and/or bootable virtual hard disk or RAID array to improve the really bad performance I had started getting in VMware.  So the second computer was also useful as a simple way of having a pretty solid alternate desktop.  I could start up a project or leave a set of folders open there and just visit it occasionally, when the primary computer was doing its own maintenance or was otherwise unavailable for a while.

The starting point for this two-computer arrangement was to set up two machines that were almost identical in terms of hardware and software.  In previous years, I had thought it was best to have dissimilar machines, so as to maximize resources.  One machine or the other would have the right hardware or software to deal with almost any kind of system problem.  That belief was probably justified for some purposes.  Now, however, I was less patient with that, and it also seemed less necessary.  A lot of the old problems had gone away.  Meanwhile, it was much easier to learn how to maintain and troubleshoot just one set of problems, rather than have to learn the whys and wherefores of divergent sets of hardware and software.  For purposes of getting my work done, Windows 7 was a significant improvement over operating systems I had used previously, including Windows XP and Ubuntu 10.10, in terms of networking and other capabilities.

The customized Win7 installation (see link above) was not as easy as a canned, plain-vanilla installation, but once I had it set up, it had some advantages.  One important step was to make my work files available on both computers.  My first attempt in this regard was to use a Synology network-attached storage (NAS) unit as a simplified file server, but that hadn't worked so well for me.  In the second attempt, I used my home network (basically, just a router and cables to the two computers, though possibly a crossover cable would have sufficed even without the router).  After some contemplation, I went with GoodSync to keep the two computers directly synchronized with one another.  This was an important development.  When combined with appropriate program settings (e.g., setting Microsoft Word to AutoRecover files every minute), it meant that, if the computer I was working on suddenly crashed or otherwise became unavailable, I could usually switch over to the other machine and pick up right where I left off.

I used GoodSync to synchronize my data partition (drive D), not the program partition (drive C).  I also used it to synchronize parts of the INSTALL partition, including particularly the funky but advantageous shared Start menu.  GoodSync did not need to be running on both computers, so I installed it on computer A.  As the installation evolved, I found that computer A was handling most of my computer maintenance and other functions, while I did more of my moment-by-moment productivity stuff on computer B.  In particular, computer A was becoming my backup hub.  I would save a file on computer B; GoodSync would copy it to computer A; and then my backup software would copy it to other drives.  After a variety of unpleasant backup surprises, I had evolved to two distinct backup systems running on computer A.  In the first backup system, I was using Robocopy, as part of my customized installation (above), to make frequent, incremental backups to a separate partition on computer A.  This was one of the few regards in which computer A differed from computer B in terms of hardware:  it had three hard drives rather than two, so as to speed this internal copying (since it was faster to copy from one hard drive to another, rather than between partitions on the same drive) and make it safer (since a failure of one drive would usually not affect the other).  In the second backup system, I was using Beyond Compare to do daily manual backups to an external drive that I could carry or store offsite as needed.  These were manual in the sense that I had to click things to make them happen, and could therefore examine or at least spot-check what was going to be changed, if I wanted to.

Again, I could still use either computer to do my work, since they both had the same synchronized files and nearly identical software installations.  Nonetheless, as the functions of the two computers diverged, I found that I was not really utilizing both monitors most of the time.  On computer B, I tended to be opening PDFs, Word docs, Excel spreadsheets, Windows Explorer sessions, and webpages, among which I would copy text, links, and other materials.  I could open some of that stuff on computer A instead, but it was cumbersome to have this happening on two different computers, and for the most part it actually was not happening on computer A.  That computer, and its associated monitor, were mostly just sitting there, working up a file comparison in Beyond Compare or otherwise doing things that did not really need to be watched constantly.

What I really wanted was to make monitor A available for computer A, when I wanted to see what was happening on computer A, but to have monitor A also available for computer B, when I was doing my ongoing work on computer B.  This called for a keyboard-video-mouse (KVM) switch.  The PS/2 type of KVM was better for purposes of providing keyboard and mouse input during BIOS setup and in programs that would boot from a CD (e.g., Acronis Drive Image) and would therefore be at least partly unresponsive to a USB mouse and/or keyboard.  Unfortunately, I did not realize that the type of motherboard I had installed in both computers did not have two PS/2 ports, so I had to use a USB KVM.  It also seemed that I might have to spring for a more expensive DVI-compatible KVM, since I'd gotten some poor video performance when I had connected the monitor to the computer using the older D-Sub rather than the newer DVI kind of cable.  In recent months I had been using the KVM only for the keyboard, while leaving each monitor dedicated to one computer and experimenting with having a separate mouse for each computer, so that I could click without having to transfer keyboard (and, optionally, monitor) focus between computers.  It had lately occurred to me, though, that the D-Sub video quality problems might just be due to the quality of the video circuits on the motherboard.  So at this point I was planning to get a dedicated video card for each computer and see whether its D-Sub connection would work acceptably, in which case I could use the USB/D-Sub KVM for the keyboard and for D-Sub video with monitor A.  In other words, monitor B would continue to be dedicated to computer B, but monitor A would run to the KVM and could thus toggle between computers A and B.

This left the problem that, as I had discovered, when I was not seeing events on computer A, I tended not to use that computer.  That was not terrible -- it would still be there as a running backup, ready to jump into service when I needed it, unless it hibernated itself in the meantime -- but experience suggested that, if I could not just glance to see what was happening on computer A, I would tend not to toggle over there on the KVM and take a peek.  I thought of two solutions to this.  One was to set up a reminder that would prompt me, every hour or two, to interrupt what I was doing on computer B, toggle the KVM, and look at events on computer A as displayed on monitor A.  I suspected I might tend to disregard that kind of reminder, but I decided to give it a try.  An alternative was to get a small, dedicated monitor that would just always be displaying events on computer A, though I realized its tiny resolution would not very well display all the stuff that would tend to appear on my widescreen monitor A.  It looked like I could get a monochrome 10-inch Miracle Business MT209A CRT on eBay for $25 including shipping, but I didn't want the clutter or the extra power consumption.  What seemed like a more practical option was rather to go with a full-sized monitor dedicated to computer A.

That's where this matter rested for the time being.

Windows 7: KVM in a Multimonitor Setup

I was using two monitors with two computers.  After reflecting on multiple monitor possibilities, I installed an ASUS EN210 video card in each computer.  This allowed me to connect dual displays.  I decided that monitor A would be available to both computers, and monitor B would be available only to computer B.  To make this happen, I connected monitor A to a keyboard-video-mouse (KVM) switch.  So computer A was visible only on monitor A, whereas computer B was visible across the two monitors (assuming that's where I had the KVM set).

Problem:  every time I switched back to computer B on the KVM, monitor A would go blank.  This was not a problem when I was using the KVM only to switch the mouse and keyboard, leaving each monitor dedicated to one computer.  It arose only in the dual-monitor setup.  It seemed that the computer was not remembering the dual-monitor settings for monitor A on computer B.  Each time, I had to go back into Control Panel > Display > Change Display Settings > Detect.  (This KVM problem also seemed responsible for screwing up Adobe Acrobat 9. It was no longer remembering my toolbar settings the way I had previously set them. This seemed to be fixed by going into Acrobat's Help > Repair Acrobat installation.)

A search led to the suggestion that the problem I was having with monitor A was with the KVM:

It is a problem found with those KVM switches which did not pass the console display's EDID and DDC information to all the systems connected to the KVM switch. ...
Windows 7 checks display and display card constantly different from what XP and other operating systems did.
To solve this issue, just replace the KVM switch with those KVM switches supporting FULL TIME Active DDC function.
Please check ConnectPRO new UR or PR serial KVM switches which support Active DDC function to all the ports.

That post pointed me toward a Microsoft webpage with more technical information.  I did another search and saw references to ConnectPRO there too.  A different search suggested that lots of users were running into this problem.  Newegg's Power Search didn't offer an operating system selection, and they didn't seem to carry ConnectPRO KVMs.  A Google Shopping search led to two ConnectPRO KVMs, each costing at least $130.  I ran across a workaround suggestion to hit Win-D before and after switching with the KVM, but apparently that worked only with XBOXes, or anyway it didn't work for me.  There was another workaround, too technical for my blood.  Another thread prompted me to check for the most current driver for my ASUS EN210 graphics card.  As I recalled, the usual advice was to look for the latest drivers on the chipset manufacturer's webpage, so after consulting the details on the EN210, I went to the NVIDIA website and searched for GeForce 210 drivers.  I went with the most recent WHQL-certified driver.  After reboot, I saw that this did not solve the problem.  Note:  the machine had all current Windows updates at this point.

It seemed I had a choice.  I could go back to using one monitor per computer, or I could look for a hardware multimonitor solution.  Going back would mean waiting for Microsoft to fix this problem with Win7.  There was no guarantee that that would ever happen.  Basically, if I wanted multimonitor support for KVM-type functionality for two computers running Win7 (as distinct from one Win7 and one WinXP), it seemed I would either have to buy an expensive KVM or maybe come up with some other kind of funky plugging and switching.  For instance, I wondered whether I could make a go of it with two keyboards, two mice, and a switch just to flip monitor A from one computer to the other.  But this wouldn't circumvent the problem that Windows 7 was constantly polling the monitor, and that was the only thing that counted.  I found a device called the Geffen DVI Detective, which for $80 would remember the EDID and therefore defeat the problem (but only for monitors using DVI connectors).

Then I saw that Amazon carried a bunch of ConnectPRO KVMs, and some were far less expensive.  They did not carry the PR-12, which was the one PS/2 (as distinct from USB) KVM that ConnectPRO offered for my humble purposes:  two computers, one keyboard, one monitor, one mouse.  USB did not work reliably for both keyboard and mouse when Win7 was not running -- when, for instance, I was booting from a CD, or was adjusting the BIOS settings before the operating system booted.  But then I remembered that my new motherboards had only one PS/2 port, and the PR-12 would definitely require two (one each for keyboard and mouse).  I did have the option of using USB mice, one dedicated to each computer, and in fact had been doing that for a while, partly for the reason of pre-boot capability just mentioned and partly to reduce the strain on either wrist.  Another option was to use an adapter or some other gizmo to give me a second PS/2 port.

From ConnectPRO's product comparison page, it seemed there were several options to consider.  One was the choice between VGA and DVI.  DVI provided superior video, but VGA (using D-Sub connectors) was functioning well for me at the moment.  (DVI achieved using DVI-VGA adapters had, in my impression, the same risk of video problems as plain old VGA.)  It seemed that a couple of inexpensive video cards had eliminated problems of ghosting that I was getting when I had the monitors connected directly to the motherboards.  There was also the choice of two- or four-computer KVMs.  I needed only two.  Switching via hotkey was preferable to having to reach up and punch a button on the KVM in order to switch between computers.  All of the relevant ConnectPRO KVMs had All-time Full DDC, which was evidently the core need behind this KVM search.  ConnectPRO's Pro line of KVMs apparently did not have the Dynamic Device Mapping (DDM) technology that would remember attached USB peripherals (e.g., speakers, mice) and would thus eliminate lag time required for the switched computer to re-detect the devices.  It was confusing, shopping among these devices on Amazon, because there were various "kit" options that were described as "new" and yet did not appear on ConnectPRO's website, and also because now it started to look like some of these products did not have Full DDC and/or DDM.  What I came up with was a choice, for me, between the UR-12 PRO, with VGA and DDC but not DDM and no hotkey option ($102 with shipping from ConnectPRO through Amazon); the UR-12 PLUS, with VGA, DDC, DDM, and a hotkey option ($176); and the UD-12 PLUS, which was the same as the UR-12 PLUS but with DVI (and therefore with VGA as an option, via adapter) ($191 from a couple of sellers).

Since I was having no video issues at the moment, and might not have any again for some time, I decided to go with VGA rather than DVI, all other things being equal.  If I did get video problems, I could sell one KVM and upgrade to another later.  So then it was a question of whether I was willing to pay an extra $74 for DDM and a hotkey option.  DDM was nice -- I had noticed the lag in responsiveness at some point, hard to recall at the moment but apparently when I had upgraded from Windows XP to Windows 7 -- but that was not really bothering me much at present.  Those delays, and the hotkey, were especially important when I was doing a lot of switching between computers, which happened primarily when I was testing or tinkering with hardware or software on one machine and logging the developments on the other.  I was not presently doing much of that, and didn't plan to be doing much of it anytime soon.  It occurred to me that, if the DDM lags did bother me at such times, I could always dedicate one mouse, one monitor, and one keyboard to each computer at those times.  I could arrange that on my desk, and then the only lag would be the time needed to reorient my hands on the other keyboard.  Indeed, for purposes of working with the BIOS and such, I could simply keep a PS/2 keyboard always plugged in and standing off to the side of each computer, in addition to the USB keyboard connected to the KVM.  (PS/2 was not hot-swappable; it would be necessary to reboot to have the keyboard be recognized if it were not plugged in at time of bootup.)  Looking at the choice again, I reconsidered that the price difference between the UR-12 PLUS and the UD-12-PLUS was only $15.  From that perspective, I would choose the latter over the former, so as to wrap up the best product at not much additional cost; and in that case, the price difference between the solution with or without DDM, hotkey, and DVI was substantial:  the UD was almost twice the price of the UR.

As long as I was sure I did want to use dual monitors on computer B, sometimes swapping monitor A between computers A and B, I would need Full DDC, and it seemed the choice was then to spend $102 on a ConnectPRO UR-12 PRO KVM.  If I hadn't gotten the video cards for only $18 each, the decision to add dual monitor capability (with KVM and video cards) would then have cost me more than $150.  It was worth it -- dual monitor capability added a lot to a workspace -- but it was turning into more hassle and expense than it should have been.  I belatedly realized that perhaps I should have looked for a motherboard with dual monitor capability and with enough video memory so that the computer would not struggle to switch between windows on the same monitor, as computer A had been doing before I added the video card.  Desk space permitting, that kind of expense also raised the question of perhaps having three dedicated monitors -- one for computer A and two for computer B, and recabling one of the latter to computer A if a multimonitor need arose there -- thereby reducing the KVM need to a simple $20-30 device that would swap keyboards and mice, assuming those were not likewise dedicated to single machines.  The temptation to just get a third monitor and forget about the Full DDC KVM would be even stronger if I were looking at the nearly $200 price tag for a ConnectPRO UD-12 PLUS KVM.  But even without that, as I considered the time I had devoted to screwing around with KVMs, on this and on previous occasions, I did think that possibly the best approach would be to go with the third monitor, wait for someone to compete with ConnectPRO and/or for Microsoft to get its act together -- to buy a third monitor as an interim solution, in other words, and to sell it when and if a superior KVM alternative emerged.

Adding a PS/2 Port

I had always used PS/2 rather than USB mice and keyboards.  USB had the drawback of not being functional in some circumstances (e.g., when I was booting from some kinds of CDs, or was adjusting the BIOS settings before the operating system loaded).  This seemed to be true even when USB devices were enabled in BIOS.  Unfortunately, my new motherboard had only one PS/2 port.  I would now have to go with at least one USB device.  Between the two, USB mice seemed to function better than USB keyboards in the environments just mentioned, so I could live with a PS/2 keyboard and a USB mouse.

Problem:  I had two computers, and was using a keyboard-video-mouse (KVM) switch to share my mouse, keyboard, and monitor between the two computers.  Now I needed two PS/2 connectors unless I wanted to get a USB KVM, mouse, and keyboard.  I didn't want to spend the money, and I liked the PS/2 KVM better than what I was seeing in the USB KVMs.  So there was a question:  could I add a second PS/2 port to a computer with just one PS/2 port?

I tried using Y-splitter cables, which were physically able to connect two PS/2 devices to one PS/2 port.  But they didn't work:  only one device or the other (i.e., mouse or keyboard) would operate.  I ran a search and saw some references to adapters that would convert the computer's serial port to PS/2, though apparently that could have its complications.  The pictures looked familiar.  I dug around and found that I already had something like that.  I didn't want to reboot the computer right then to try it out, so I searched a bit more.  There seemed to be some USB to PS/2 adapters; presumably those wouldn't have the serial port problems.  I also found a PS/2 adapter backplate, which would have required an unused PS/2 header on the motherboard.  I wasn't sure if my mobo had one of those, but I could scope it out when I did shut down.

I wasn't sure which of these solutions I would ultimately wind up using, or even if I would definitely try to stick with PS/2 rather than USB.  This is as far as I took the question at this moment.

Two Computers, Two Displays, Together and Apart: TeamViewer, KVM, and Input Director

I had just installed Windows 7, after working out networking hassles between two computers.  I had set up a home network.  Now, following up on a previous post, I wondered whether I could use TeamViewer and Input Director to permit smoother use of those two machines.  The general idea was that I had two networked computers, each with its own monitor, and I wanted to use one or both of those programs to facilitate a seamless desktop experience.  This post describes my exploration of related possibilities.

I decided to start with Input Director.  The purpose of this program was to let me use a keyboard and mouse on computer A to do work on both computers A and B, without needing a keyboard-video-mouse (KVM) switch.  To give this a whirl, instructions advised installing Input Director (ID) on each computer.  I started ID on computer A, turned aside for a moment to attend to something else, came back to computer A, and found that ID had disappeared.  I restarted it and clicked "Enable as Master," and likewise enabled computer B as slave.  I started to change the default hotkey from the way they had it set up, which looked very complex but apparently just meant left-Ctrl-Alt-Break -- but then ID disappeared again!  It wasn't in the system tray either.  It had just died.  But on retry, it was OK.  I wasn't sure what happened there.  I went into Master (or Slave) Configuration.  Not to much to do there.  On computer A, I clicked Add and then tried to figure out what I should use as Hostname and Port for the slave I was trying to attach.  I tried just using the name of computer B.  This brought an error, "Slave 'ComputerB' didn't respond," and on computer B I got a popup balloon saying this:

Unauthorised access
A request to direct input by the unauthorised system ComputerA was rejected.

I thought maybe this was because computer B wasn't set up yet.  So in its Slave Configuration tab, I clicked "Allow computers only on this subnet to take control."  It asked for Network and Mask, which I wasn't sure of, so I clicked "Select from list."  I had VMware on this computer, so there were a couple of options for that, but I went with the one for the Realtek PCIe GBE Family Controller.  I also clicked on Add and typed in the name of computer A as Master Hostname.  Now both computers were visible in the Master Configuration tab on computer A.  In the Master Preferences tab, I cleared hotkeys, since I didn't think I would want to use them and didn't want them interfering with other programs.  And then, what do you know, it was working.  The mouse on computer A was able to keep going rightwards, past the right edge of the computer A display, and move across onto the monitor for computer B and do things there.  The keyboard was still going where my KVM set it, so I unplugged it from the KVM and plugged it directly into the computer.  Wow, just like that, the monitor that I selected with the mouse was also the monitor where the keyboard was active.  If I moved the mouse to the monitor that was plugged into computer A, I had a keyboard on computer A.  If I moved the mouse over to computer B's monitor, I had a keyboard there instead.  Basically, a mouse-controlled KVM.

To get adjusted to this new arrangement, I unplugged and rearranged mice and keyboards and rebooted both machines.  Now, suddenly, computer B was unable to go online.  It had been fine until now.  I disabled Input Director and rebooted.  The disabling was not persistent; ID was back.  I uninstalled Input Director and rebooted again.  Now, for a moment there, my customized Start Menu was broken.  I still was not able to go online.  Unfortunately, I now discovered that System Restore had somehow gotten turned off -- on computer B only, despite having set it up from a mirror of computer A, where System Restore was still working -- so I had to restore an image of computer B.  While nothing is certain, these problems were new.  They seemed likely to be due to Input Director.  As soon as the mirror was restored, I uninstalled ID.  The problems did not recur in the next 24 hours of fairly intensive work, so it looked like ID was the culprit.

Without Input Director, I hoped that something of my multiple desktop vision would remain.  From my understanding of TeamViewer, it did not seem that I would have the option of switching my two computers and two monitors back and forth between dedicated and dual-monitor formats.  But maybe I still could, with a KVM.  To investigate that, I had to get TeamViewer working first.  I installed and ran it on both computers A and B.  It started with a dialog that gave me a Remote Control tab containing a session ID.  I typed the session ID appearing onscreen in computer A into the dialog box on computer B and chose the Remote Control option.  It said, "You have entered the ID of your own computer."  Well, that was true.  Both machines were showing the same ID.  So apparently I was not doing this right.  But there did not seem to be an alternative.

I stepped back and reviwed the concept.  I wanted to use computer A to control either computer A or B.  This, again, was to be a KVM-type solution without using a KVM.  Instead of switching between computers (e.g., changing the focus of my mouse and keyboard from computer A to computer B) by hitting a hotkey or physical button linked to the KVM, I would switch between computers by clicking on a button onscreen or by hitting a hotkey linked to Teamviewer via the network cable.  In this way, I would not need the KVM.  But I was not sure TeamViewer was ready to play this game.  The solution, someone said, was to click on Extras, at the top-right corner of the first Teamviewer dialog, and go into Options > General tab > Incoming LAN connections > accept.

Instead of doing that, at this point I decided that I was already getting the functionality I needed for the time being.  Hence, I decided to shelve this project until later.  The KVM situation was acceptable.  GoodSync had recently begun to provide much of what I had thought I wanted from Teamviewer.  Also, that brief taste of Input Director had caught my attention.  That seemed to be the next step forward in this area.  The Teamviewer concept, or an alternative, seemed to be something that I should review later, after I had some experience with this setup, and after waiting a bit for possible improvements to Input Director or for good alternatives to it.

VMware Workstation 7.1 Unrecoverable Error

I was using VMware Workstation 7.1 on Ubuntu 10.04 with a Windows XP SP3 guest.  I had a WinXP virtual machine (VM) open, and suddenly it crashed, with this error message:

VMware Workstation unrecoverable error: (mks)
Unexpected signal: 11.
A log file is available in "/media/VMS/VMware VMs/WXMUProjectC/vmware.log". Please request support and include the contents of the log file.

To collect data to submit to VMware support, select Help > About and click "Collect Support Data". You can also run the "vm-support" script in the Workstation folder directly.
We will respond on the basis of your support entitlement.

I pursued that option, but it turned out I didn't have a support entitlement, so I turned to this process of researching the solution on my own.  I had gotten a similar error message once before.  I wasn't entirely sure what I had done to solve the problem in that case, other than to keep flailing around until something clicked.  But as I reviewed that previous post, I did recall a different error message that I had gotten when starting the VM.  I started it again and saw this in the lower right-hand corner:

Could not connect Ethernet0 to virtual network "/dev/vmnet8"
More information can be foun din the vmware.log file.
Virtual device Ethernet0 will start disconnected.

I tried a search for that error and came across some possible answers.  One was just to reboot, but I had already done that.  Another was to use the Virtual Network Editor.  I found a VMware video on that.  It told me that vmnet8 was associated with NAT, which was the kind of network connection I had selected in VM > Settings > Hardware tab > Network Adapter.  The video then started to talk about adding a network adapter.

It seemed that this could have two implications for me.  First, I had just put a network interface card (NIC) into the computer, as an alternative to the motherboard's onboard network connector.  I had done that in an attempt to deal with a networking problem that turned out to be just a bad cable.  I did think that, previously, I had been getting the second error message previously, the one just quoted, "Could not connect Ethernet0."  But I had not been getting the crashes previously.  So probably I could fix that error by just removing the unnecessary NIC, instead of trying to figure out how to configure it as described in the video.  Second, I had preserved my Ubuntu /home directory during this most recent installation of Ubuntu.  I had also recently installed a new motherboard.  Possibly the settings that I had saved in that /home directory were still dreaming of the old days, with the previous motherboard; perhaps I would have to configure the VM's ethernet adapter anyway, so as to make it comfortable with the new motherboard.

I started by shutting down the machine, removing that unnecessary NIC, and restarting.  (Before shutting down, I checked Ubuntu's System > Administration > Update Manager, just in case there were updates that would make my life easier in unknown ways.)  I powered up the VM.  No Ethernet0 error message.  OK, one problem solved.  Would it crash?  I worked with the VM for a couple of days, but then it did crash again.  It seemed that the frequency of the crashes was much reduced, so maybe removing the NIC helped.

This time, I took a look at the log file.  It was in the folder containing the other files for the VM, including the .vmdk file, and it was named simply "vmware.log."  It contained a large number of entries, going back days, including what looked like several hundred, at the end of the file, that all occurred within the last second before the crash.  The first one in that last second was "Caught signal 11 -- tid 3652."  There hadn't been any others for several minutes before that, and I also noticed that the "11" was the same number as appeared in the error message onscreen (quoted above).  This did seem to be the beginning of the end.  After that "Caught signal 11" message, there in the log file, I saw many repetitions of a few other types of messages, like these:

mks| SIGNAL: stack B6CE1AE0 : [etc.]
mks| Backtrace[0] [etc.]
mks| SymBacktrace[0] [etc.]
mks| Panic: dropping lock (was bug 49968)
mks| Unexpected signal: 11.
mks| Core dump limit is 0 KB.
mks| Child process 19031 failed to dump core (status 0x6).

mks| Backtrace[0] [etc.]
mks| SymBacktrace[0] [etc.]

where [etc.] refers to various sets of computer gibberish (e.g., 0xb7823410).  It went on from there, but now we seemed to be at the point of no return, where the log showed VMware giving me the "Unexpected signal" error message onscreen.  A search led to a thread in which people were saying that they avoided this error by tinkering with their screen resolution.  When I saw that, I figured that we were talking about a kind of general reaction to somewhat incompatible hardware:  could be the NIC, could be the screen resolution, etc.

I had noticed that this particular crash occurred when I used my KVM to switch from the computer in question to a different computer.  It was a new KVM, an IOGear GCS72U.  I had previously been using a PS/2 KVM without problems, but my new motherboard did not have two PS/2 sockets, so I had to switch to this USB KVM.  Had I installed the KVM before or after taking out the NIC?  I couldn't remember.  But the KVM was a suspect.

Another suspect was the keyboard.  I had also had to get a new keyboard and mouse -- because, of course, I was using PS/2 devices previously, and now I had to have USB devices.  It was an inexpensive keyboard, a Logitech K120, and I had noticed that it did not work consistently on the other computer.  It would be working fine, and then there would suddenly be no more keyboard input.  The mouse was still working, but not the keyboard.  At that point, it didn't matter whether the keyboard was connected to that other computer through the KVM or was plugged into it directly; either way, it wouldn't work.  But I hadn't done a scientific study to determine whether it was the keyboard or the USB KVM that was screwing up.

So, putting it together, what had happened in this case was that I was using VMware on computer no. 1 (C1).  The keyboard and mouse had been working fine on both C1 and C2.  I hit the KVM switch button to move to C2.  That's when VMware crashed; and at the same time, suddenly the keyboard was not working on C2.  But the USB mouse would still work.  So it seemed that either the keyboard or the KVM was sending a funky keyboard-related signal to C2.

C2 was an older system, and I was in the process of upgrading it, and I thought that might solve the problem.  But in the meantime, I plugged my old PS/2 keyboard into C2 and rebooted, with the new keyboard and KVM still connected to both computers.  In this setup, over a period of days, I observed that the PS/2 keyboard continued to work consistently throughout, but the USB keyboard would sometimes stop working on C2, like before.

Then I had another VMware crash on C1, and that made me decide to try another angle.  I unplugged the KVM from C2.  By this time, I had replaced C2; now it was pretty much the same computer as C1 (same kind of motherboard, CPU, and case).  So now the mouse and keyboard connected to the KVM would work only on C1.  On C2, I kept using the PS/2 keyboard, and added a USB mouse.  If there were still crashes or freezes, I would have a better idea of whether the problem was the new USB keyboard or the new USB KVM.  At this writeup, a couple of weeks later, my recollection was that I did not have any further crashes.

I decided to send the KVM back to IOGear.  In the interim, I connected my old PS/2 KVM to both computers, and used it only with the PS/2 keyboard.  So now I had a separate USB mouse for each computer, but only one keyboard for both of them.  It took a while to get used to switching mice when I switched the keyboard from one computer to the other, but the point here is that there were no further crashes.  I had to wait for the replacement KVM to arrive from IOGear before I could say for sure whether it was the keyboard or the KVM; but by that point I had decided to stop using VMware on Ubuntu,

Windows 7: Multiple Monitors, Multiple Computers: Possibilities

I planned to be using Windows 7 on two computers.  At the start, I had two monitors, each dedicated to its own computer.  I wondered if I could set up the system so that I could use both monitors for computer A, and could also use both monitors for computer B.  I also wondered if I could use monitor A to see what was happening on both computers A and B at the same instant.

My first search led to ads for KVM switches, but that wasn't what I wanted.  I did look into KVM switches at Newegg, just in case someone had invented a switch that would do everything.  But then realized I wasn't going to read through all those product descriptions to see if any of them had the possibilities I wanted.  A different search got closer to what I wanted.  Actually, it went well beyond it.  There were possibilities I hadn't even imagined.

One possibility was that of Synergy, which had originally been Synergy and then became Synergy-Plus and was now back to being Synergy.  It looked like the Synergy concept ws that I could have two or more computers, each having its own monitor, and I could have just one keyboard and one mouse, and would move among these computers simply by moving the mouse to the left or right, until it left one monitor and then appeared on the next.  No KVM switch; just move the mouse to switch computers.  The connection was by ethernet -- just get all computers on the same network.  They said you could also copy and paste between the computers.  But apparently Synergy wasn't entirely stable yet; that was their stated goal for 2012. For that reason, I decided I would prefer a KVM for now, if necessary.  Presumably a problem with the network would render all computers other than the server (i.e., the one to which the keyboard and mouse were connected) unavailable.  Bruce Tyson pointed out that there would also be a problem if the user wanted to access the BIOS of a slave or client computer during bootup.  It seemed like it might be a good idea to have a spare keyboard and mouse handy.  Another possibility:  Input Director.  This Windows-specific freeware application seemed to have the same concept as Synergy.  These sorts of programs seemed to have the same idea as a KVM switch that would allow one keyboard (e.g., that on a laptop) to take control of another computer even if it did have its own keyboard and mouse.

Bruce Tyson also pointed me toward web-based sharing services, Virtual Network Computing (VNC), and remote desktop software.  These apparently all were, or could be, variations of "headless" computing, where the keyboard, video, and mouse (KVM) are all connected to just one computer, which is then linked to others whose contents may display on that monitor.  He also noted that some monitors have dual inputs, which could be plugged into separate computers, but that the user would have to switch between them using buttons on the monitor.  That would prevent simultaneous viewing of two computers and would also be klunky in daily use.

It seemed that GoToMyPC.com was one of the leading web-based services.  But when I looked into it, these appeared to be simply ways of accessing the computer remotely.  At $10/month or more, it was pricey.  LogMeIn and others seemed to offer good free alternatives.  I decided I didn't want a web-based service, even if it did exactly what I wanted, because it would be relatively slow and it would be vulnerable to anything that might go wrong with the modem, the network connection, etc.

According to Wikipedia, VNC was both platform-independent and remote-capable, and some versions were "optimised for Microsoft Windows."  A list of versions indicated that UltraVNC (free) was the most advanced mainstream version and was the basis for several others.  Current alternatives for connecting a few Windows PCs included EchoVNC (free), RealVNC (free+), SmartCode VNC Manager ($129+), SupportAnyPC ($149), TeamViewer (free), and TightVNC (free).  Among these, a RealVNC feature comparison page indicated that its free version was not compatible with Windows 7.  Wikipedia pages for the free versions indicated that RealVNC was similar to UltraVNC, but the latter had more features; EchoVNC differed from UltraVNC in being more firewall-friendly; Teamviewer was mostly for remote control of computers; and TightVNC likewise had spun off a firewall-friendly variant, RemoteVNC ($25 per computer), among others.  A Wikipedia comparison page, only in it formative stages at this point, named Skype, TigerVNC, and xpra as other free Windows-compatible remote desktop programs.  The Wikipedia pages just linked for those additions indicated that TigerVNC was a fork of RealVNC; that Skype was (of course) primarily for VoIP; and that xpra (currently a beta product) used an approach that differed from that of VNC; but it later looked like xpra was not for Windows.  For my purposes, the survivors of this discussion were EchoVNC, TigerVNC, TightVNC, and UltraVNC.

I looked at a Wikipedia page showing a comparison of Java remote desktop projects. I was not sure what this was about. The project that seemed most feature-rich at this point was WallCooler VPN, so I looked into that. This actually led to a page for Vedivi, which seemed to be in the business of giving people access to remote computers at a low monthly price.

Eventually I figured out that there are many remote desktop protocols.  VNC was one; Remote Desktop Protocol (RDP) was a Windows-specific alternative.  There were others.  I eventually found a chart that, although officially for Mac, pulled together some of this.  Revisting the Synergy and Input Director webpages (above), I saw that Synergy was not a VNC project; I was not clear what type it was, and likewise for Input Director.  Supposedly Microsoft's own version of RDP was currently called Remote Desktop Services, previously Terminal Services; but when I went looking for it, I wound up in Remote Desktop Connection (RDC).  A search led me to a description that sounded like what I was looking for.  I wondered why someone would have bothered creating Input Director, with its Windows orientation, if this feature already existed in RDC.  I decided to start by trying to use RDC, to see what would happen.  That would be the subject of another post.

Multiple Computers: Remote Desktop Connection, Input Director, TeamViewer

In a previous post, I looked at various ways to control two computers with one keyboard, and for mixing monitors among computers, without using a KVM switch.  I came away thinking that I should start with the Remote Desktop Connection (RDC) option in Windows 7 (not available in Home editions).  I had lots of questions about the best way to combine two computers for maximum efficiency without too much complexity.

As I revisited RDC, I now wondered whether it offered the best solution for my purposes.  RDC would apparently give me just what its name implied:  a way to connect to the desktop on one computer while working at another.  In a home network setting, I would be looking at the same physical display unit(s) as I switched my attention between the two computers located under the desk.  It was tempting that RDC came built-in with Windows 7.  I was not entirely sure what its "continuous resolution" feature was about, but it sounded interesting.

To get a clearer understanding of RDC, I looked at some YouTube video demonstrations.  The ones I looked at were more in the nature of tutorials on how to set up RDC, as distinct from what it was like to use it.  They were still informative.  I hadn't fully registered that I could use RDC in Windows XP, in case I wanted to do that.

The basic idea seemed to be that, in RDC, I would choose to be working in computer A, or perhaps in computer B; and whichever I chose would be the one I would see onscreen.  If I chose to work in computer A, I would see the computer A desktop.  So then hopefully I could rig up multiple monitors to show a big spread of what was happening on computer A, and I could switch and have those monitors show a big spread of what was happening on computer B.

A video of Input Director clarified things somewhat.  Input Director had preliminarily seemed, to me, to be the leading alternative to RDC.  The difference that I found striking was that Input Director would let me move from one computer's dedicated monitor to the next, just by moving my mouse, and the keyboard would tag along.  So computer A would have its own monitor(s), and computer B would have its own separate monitor(s).  The other nice feature of Input Director that emerged in that video was that you could copy text in one computer and paste it into the other.  Unlike RDC, where the computers could be halfway around the world from each other, the computers in Input Director would be more or less next to each other, connected by a router (in e.g., a home network), so that the user could view their respective displays.

As I was browsing around, I found a discussion containing enthusiastic endorsements of TeamViewer.  I had actually used that in a tech support call a few months earlier, when someone basically used it to take control of my computer and make changes so that the item in question would work.  So I wound up watching a video about TeamViewer too.  It seemed to be similar in concept to RDC, though at this point I was thinking TeamViewer might be a better-quality option than RDC, and was available across multiple operating systems.

For purposes of tinkering and initial investigation, then, it was a choice between Input Director and TeamViewer.  There was no question the latter was vastly more widely spread around the world.  For me it was mainly a question of which features I wanted or needed most.  If I always wanted to see displays that would show me what was happening on two or more distinct computers, then it had to be Input Director (or, someday, maybe Synergy).  If I wanted to focus both (or all) of the available monitors on one computer, then it would be TeamViewer.

There seemed to be a way to use both.  I could start with two separate computers at my desk.  Events on computer A would appear on display A; events on computer B would appear on display B.  In that setup, Input Director would let me switch the focus of the keyboard between computers, as I moved the mouse back and forth between displays.  Then, that situation could be changed.  I could equip display B with a KVM switch.  As long as I left display B connected with computer B, the situation would be as just described.  But if I pressed the button to change the focus of display B so that it would be covering computer A, now I would have a dual-monitor presentation of events on computer A.  Finally, if I had TeamViewer running on computer A, then I could use it to provide a dual-screen view of computer B as well.  In other words, by using the KVM switch I would free display B from having to follow along to whatever computer TeamViewer was focused on.  The switch would make it possible to *not* do multi-monitor work, in which case Input Director would be useful.  This approach would let me switch display styles to match the nature of the task and my preferred work style, without needing the cost and desk space required for a third display.

Whether the reality would match the theory was another question.  But this was the scenario I would explore further in a subsequent post.

Two Computers: Dividing the Workload

In this post, as part of my New Year's housecleaning, I introduce several investigations, involving various ways of setting up two computers in a workspace.

*  *  *  *  *

KVMs and Monitor-Sharing Options

I had developed the habit of working with two computers, using a KVM switch so I needed only one mouse and keyboard.  A KVM switch would let me use just one monitor with two computers:  it would be showing me what was happening on the computer that the mouse and keyboard were then connected to.

I had two monitors.  I didn't have them connected to the KVM.  Instead, I connected them directly to the two computers, one for each.  So the KVM switch would have me working on computer A or computer B, but monitor A would continue to show what was happening on computer A, and monitor B would continue to display the state of things on computer B.

Actually, one KVM had started malfunctioning, and I had replaced it with another.  In the process, I decided to disconnect the mouse from the KVM too.  So now the KVM just controlled the keyboard.  It made sense:  the keyboard was big.  I couldn't fit two keyboards on my desktop.  But I could fit two mice.  Mouse A, on the left side, was controlled by my left hand, and was controlling computer A, while mouse B was preoccupied with computer B on my right.  I wasn't sure if I liked this arrangement.  It had its advantages.  It gave my hands a more equal workout.  I could glance over at the other computer and click something, to make some process move ahead, without having to hit ScrollLock twice, which was how the KVM switched the keyboard back and forth.  The main problem was that it was hard to tell which computer the keyboard was controlling at any given time.  I was still occasionally hitting the Del key and deleting things on computer A and wondering why they weren't disappearing from monitor B.  It was a bit nutty.  But I was adapting and, like I say, it had its advantages, at least until I worked out something better.

The monitor situation was OK, too.  I had widescreen monitors, so I was able to accommodate a couple of different open windows at the same time on each of them.  But there were times when it would have been helpful to have both monitors attuned to just one computer.  I had previously used an arrangement where monitor A was dedicated to computer A, but monitor B was connected to a second KVM switch, so I could reach up and punch the button and switch monitor B back and forth between computer A and computer B.  This would let me use a multiple monitor approach on computer A, so as to spread out my work.  The problem with this was that, when there was no monitor turned on to computer B, I tended not to use it.  That was a problem because the purpose of having two computers was to let me continue to work when one of them would crash or need maintenance or get involved in some process, like scanning or rendering, that would make it virtually unavailable for other purposes.  I also used this arrangement to write these blog posts, tinkering with one machine and recording the steps in the other.  I found that, if I got too fixated on one computer, the other one tended not to be organized and capable enough to take over when I needed it.

There didn't seem to be a way to share one monitor between two computers simultaneously, with computer B running in a little window in the corner -- a real "monitor" as distinct from a big display.  There was the option of buying a little display, connecting it to the second DVI connector on computer B, and putting it off to the side, so I would always have that information about what was happening on computer B.  But that little monitor would cost more than $100.  I could probably go down to Goodwill and pick up an old CRT for less than $10, but the other problem was that it would still be more clutter, more heat, more power consumption.  And the desk didn't have room for it, so it would have to go onto a side table or shelf or something.  I would also need a video card, since my motherboard only supported one monitor.

A decision on that question of how to use multiple monitors would await the outcome of an investigation of various non-KVM strategies.

*  *  *  *  *

Dual-Booting and Virtual Machines

Over the past couple of years, my two computers had different missions.  Computer A was running Windows XP in a VMware virtual machine on Ubuntu.  Computer B was running WinXP natively.  Now I was moving away from Ubuntu and back to Windows.  I had planned to just install Windows 7 on both.  I'd been having problems with my WinXP installation on computer B, even when I restored from an image, so it seemed like a good time to upgrade rather than continue to fight it.

I liked the idea of dual-booting WinXP and Win7.  Actually, though, I rarely used my dual-boot setups.  I pretty much always went with one or the other.  Right now, for instance, I already had a dual-boot Ubuntu and WinXP setup on computer B, but I couldn't remember the last time I had gone into Ubuntu there.

Meanwhile, on computer A, it seemed like I should consider just replacing Ubuntu with Win7:  continue to run WinXP in a virtual machine (VM), that is, but run it on Windows 7 instead of Ubuntu.  This would give me access to the familiar way of doing things in WinXP, while easing the transition to Win7.  I looked into the VM option in more detail.  It looked like I would be able to use the Windows version of VMware Workstation as long as I wasn't using my Workstation license in Ubuntu.  So the tentative plan was to have WinXP running in VMware on Win7 on one machine, while just running Windows (either XP or 7) natively (i.e., without a VM) on the other.

Although I was moving away from Ubuntu, it occurred to me that this strategy would leave a door open for a possible return to Ubuntu.  Ubuntu had been far more stable than WinXP.  Assuming the virtualization setup worked, I could install Ubuntu as a VM on Win7, essentially reversing what I had tried to do previously, and I could thus continue to identify projects and programs that Ubuntu could handle just as well as Windows for my purposes.

*  *  *  *  *

Differences Between Machines

The decisions described above meant that, contrary to my assumptions, I probably should not set up identical hardware on both computers.  Computer A was probably going to need more muscle to handle the VMs.  WinXP on computer B had been struggling to run video editing software, though that may have been due to a flawed installation.

Part of the tradeoff here was simplicity versus options.  The more operating systems and hardware arrangements I had in play, the more different ways I had of configuring things, and the more time it would take.  I had always viewed the computer hobbying as a means to an end of being more productive, while having its own intrinsic interest too, and for that reason I had tended to think, in recent years, in terms of getting myself set up for the next six months or a year.  During that kind of timeframe, the problems of a setup would tend to emerge and sometimes become overwhelming.  The current Windows XP installation was a case in point.  I had been able to nurse it along despite its obvious dysfunctionality, occasionally replacing its current state with an Acronis image backup, but it was now crashing one or more times per day.  So, oddly, in this case it was the simpler installation that had become the more problematic.

The switch from Windows XP to Windows 7 probably meant that I would be spending quite a bit of time getting up to speed on the best way to configure the latter.  I was probably going to install it in a RAID array, for purposes of performance, with an external backup option.  There would be some things to figure out and play with.  Most likely, some hardware would be getting shuffled around.  So, contrary to my first thoughts during this particular housecleaning, it did not appear likely that the two computers would take on any clear definition:  they would not be mirror images of one another, in hardware terms, so as to simplify maintenance, and they would also not feature one being considerably more powerful than the other.  The plan for the coming six months to a year was just to make them both capable and to explore options without investing more time than I wanted to spare for this kind of project.

Since I was now in a period of computer housecleaning, it seemed likely that my posts over the next few weeks would explore these considerations in more detail.