Late last year, I received a call at work from a customer with a question about their software, and I needed to log in to their system to take a look. I fired up my VPN connection, then opened Remote Desktop Connection and entered the customer’s server information.
When I attempted to connect and log in to that Windows Server 2008 machine, however, I was greeted with the cryptic message, “A device attached to the system is not functioning.” After acknowledging the message, I was promptly and unceremoniously disconnected from the server.
But what does that mean?
Obviously, something was not exactly right, but what? I turned to search engines to try to figure out what was going on.
It turns out this is an old Windows message. Microsoft TechNet has an entry for the message in its Windows 2000 Error Messages Reference which helpfully explains that an attached device is not working for any of a variety of reasons, the first being that “it is switched off, or connected improperly.” Okay, that makes sense, but the recommended solution? “Correct the problem and retry the command.” Wow, thanks. I’ll get right on that once I figure out what the problem is!
Another suggestion I found on a Microsoft forum was to check Device Manager to see if any malfunctioning devices were listed. That actually was not a bad idea, and I would have happily started there, but since I did not have physical access to the machine and could not connect via RDP, that was sadly not really an option.
My search continued, and although I don’t remember exactly where I read it, I eventually stumbled across a snippet that mentioned that Windows will sometimes display this error if the user account that you are trying to use to log in is already logged in remotely but disconnected from that machine. It’s not entirely clear to me why an account being logged in but disconnected would cause Windows to report that “a device attached to the system is not functioning,” but in the context of the sort of remote support we do at work, it seemed feasible that that was what was going on.
As I already mentioned, though, this was a customer’s machine to which I did not have physical access. I could ask the customer’s IT help desk to check, but it could take some time to get a response. Was there any way to check to see if the Windows account I was using was indeed already logged in to that server?
The answer, it turned out, was yes, at least in this particular situation.
Enter PsTools, and PsExec
Microsoft offers a collection of command-line administrative tools named PsTools. Among them is PsExec, which Microsoft bills as “a light-weight telnet-replacement that lets you execute processes on other systems.” Happily, the account that I was trying to use to log in had administrative privileges, so if I could connect, I should be good to go.
The PsExec documentation explains all of the different arguments that can be passed to the program, but a very helpful post on Vlad’s IT Blog put me on the fast track.
After downloading and unzipping the PsTools pack, I opened a command prompt and navigated to the folder containing PsExec. I then entered the following, using the name of the computer to which I was connecting and my username and password on that machine. The cmd at the end can be replaced by whatever program name you want to run—in my case, a command prompt:
psexec.exe {server} -u {username} -p {password} cmd
In no time at all, I was in. The next step was to find out if my account was already logged in; I did that by entering query session, and sure enough, there was my account’s username with a session state of “disconnected”! I typed logoff {sessionid} to log off that session using the ID listed for the disconnected session, then typed exit to get back to my own machine’s command prompt.
Once all of that was done, I again tried connecting to the customer’s server via Remote Desktop Connection, and was able to log in without any further trouble. Problem solved!