Where have all the COM Ports Gone? - How enumerating COM ports led to me finding a ?misplaced? Microsoft tool

Published: 2011-01-24
Last Updated: 2011-01-25 03:39:34 UTC
by Rob VandenBrink (Version: 2)
14 comment(s)

In my work, I connect to routers switches, firewalls and other network gear daily.  Since laptops no longer come with serial ports (who exactly decided that this was a good idea?), this means that I use USB to serial port adapters.  In fact, I've got a nice collection of these things in the laptop bag - some work better than others for various functions (some do a better job at serial packet capture for instance), but the one thing most of them have in common is that when you plug them in, they'll pick some random serial port to use.

So if I'm working on a router or switch, I plug a dongle in, and then have to fire up windows device manager to go hunting and find out which serial port it got assigned.  This is an exercise of several mouse clicks. While I've gotten pretty quick at this over the years, frankly I'm tired of it.

My thought was - there's got to be a way to do this from the command line with WMIC.  WMIC gives you a unique access to the internals of Microsoft Windows, is available for or is native to all modern Windows Platforms, and is usually very simple to figure out.  Not today though, after 20 minutes of effort, one script prints the first COM port, the other catches the physical COM ports but not the USB ones.  So, in the best sysadmin tradition, after 20 minutes, I’ve (temporarily) given up on WMIC for this and decided to try a different approach.

This 1 line script will echo the serial ports on your machine, and what they are assigned to.  It uses the Microsoft REGDUMP command (this used to be part of the Windows Resource Kit, now part of the Microsoft Logo Tools available from http://download.microsoft.com).  It's a simple "show me the reg keys" script.

COMFIND.CMD



So, a test run with 2 dongles plugged in on my laptop looks like:



 


It ain't pretty, but it finds what I need. 

The downside of the approach I took here is that you need REGDUMP.  If I'm using a customer's computer (this is sometimes the case), I need to fall back on the "go look in device manager" approach.  If anyone out there is having better luck using WMIC for this than I have, by all means post your (better than mine) solution to the comments section !

So what can else do we find in the Microsoft Logo Testing kit?

First of all, our two friends REGDUMP and REGDIFF
RegDump - Dumps specific registry keys, or the entire registry
RegDiff - Compares the two files before and after an operation to give you differences (I generally use REGDIFF against two REGDUMP files, hence the name)
Restart Manager - Allows you to stop most processes in Windows (except for “critical system processes”) by injecting a shutdown message using the rmshutdown api – more info on this tool here  http://msdn.microsoft.com/en-us/library/aa373524%28v=vs.85%29.aspx
RollBack – a set of tools to assist in rolling back an application install (to test the error recovery within an application install MSI file)
ThreadHijacker
- Allows you to crash a process by pausing a process thread, inject binary data into it’s address space, then resuming it.  Again, this is used to measure the robustness of applications.
 

================================== UPDATE ======================================

There was a ton of responses to this diary, both as comments and as emails.  A common message in these is that the Microsoft support for serial port enumeration in WMI is not great - "broken" in the words of many.

Another common message was that i goofed.   Using REGFIND is totally not neccessary -  - the REG command has been in Windows for some time (since XP days).  It's also a command that I use pretty regularly, all I can say is that by the time I gave up on my initial run at a WMI solution, I was frustrated enough that I just plain missed it.  Using REG means that no downloads are required, and the script will run on any computer of recent-ish vintage.
An updated  COMFIND.CMD might look like:



We also got some pointers towards some WMI scripts that can do this.  The best examples of WMI scripts that work actually query the registry (go figure), so there didn't seem much point in replacing a one line CMD file with a 15 (or 50) line VBS or HTA file that does the same thing, even though it's possible

A reader did point me at a decent HTA script, but it lists all the ports you have ever had, not just the ones you have at the time the script run.  Note that the author of this script also notes that the WMI command 'WMI "Select * from Win32_SerialPort' is basically broken, so this script also queries the registry for much of it's information.  It's a good example of all that's possible - just be prepared for a bit of a wait while it runs ==> http://gallery.technet.microsoft.com/scriptcenter/087b4d73-4a5e-4746-b365-ad682911360e


 

=============== Rob VandenBrink Metafore ===============

14 comment(s)

Comments


Diary Archives