EnumPorts() returns strange error on some machines

I maintain an application that uses the win32 EnumPorts() function to help determine the set of serial ports installed on the computer. I have seen cases on some computers where the call to get this information fails with a GetLastError() code of 1722 (RPC server is unavailable). I assume that this has something to do with either registry settings or a required service being disabled but my search so far has been rather fruitless. Has anyonw else encountered this issue?

From stackoverflow Jon Trauntvein

• There are a lot of weird serial ports these days: USB serial cables, Bluetooth, cell phone modems with GPS,... It might be something plugged into the computer and long forgotten since.

  To find out which port is causing the problem you could try going into device manager, select "Show hidden devices" in the "View" tab and deleting them until the problem goes away. That might allow you to zero in on the problem.

  Jon Trauntvein : I have tried that to no avail. The problem appears to be that EnumPorts() isn't able to connect to the local machine (I assume that is why the RPC server is relevant)
  From Andrew Queisser

• I know it's not a direct answer to your question, but have you considered using a different method for enumerating the serial ports? In my applications I use the Setup API, using code from P J Naughter's website: http://www.naughter.com/enumser.html, and I find it works well.

  From ChrisN

• I should point out that I have already replaced the call to EnumPorts() with an algorithm that scans the registry key: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM for serial port names. This should resolve the issue once my software is released. What I am after is pointers that can be given to customers who are using the released package at the present.

  From Jon Trauntvein

• I'm not an expert on EnumPorts, but I strongly advice against relying on registry keys.

  • Key definitions might change in the future.
  • Key definitions might not be what you think.
  • There might be ways to "be a serial port" which don't include those keys.
  • The keys might not reflect up-to-date status, etc. etc.

  You should always rely on the APIs available.

  If an API doesn't behave for you, let's try to figure out why. Maybe with a little extra information we can help better:

  What is it exactly that you need to do with the serial port?

  From Euro Micelli

• In answer to Euro Micelli's comments. I am specifically attempting to fill a pick list that will allow the user to choose an available picklist. To begin with, I relied exclusively on EnumPorts() to provide me a list of potential serial port names. It has proven to be unreliable, however in several senses: It has not always provided the complete set of port names and, as I have recently seen, it can fail to function altogether when the "RPC service is unavailable". Why RPC is needed to find out what ports are available on the local machine is completely beyond me but there it is. This latter problem was the final straw. So far as relying completely on the list of names provided, i filter these names using the GetDefaultCommConfig() function to determine the exact nature of each of the names that I came up with.

  In my experience, the list of names provided by the previously mentioned registry key has been the most reliable method for getting port names. As a matter of fact, I can see the key get updated as I disable port drivers in the device device manager. Under normal experiences, I would agree with the assessment that relying upon a particular key is fraught with peril. In this case, however, M$ has never provided a decent mechanism to evaluate the names of available ports.

  From Jon Trauntvein