Same COMExceptions thrown by Visual Studio for different actions?

Question

Background:

Within my VSPackage I have process.Attach() instruction. I also have UAC (User Account Control Settings) set to default level:

Use cases:

1. When I run sample application under admin privileges:

   

   and then attach to such process using my VSPackage from Visual Studio running under lower, current user privileges (non-admin), I get following COMException:

   

   Which is correct I suppose and indicates I'm not authorized to perform such attach operation.

2. When I run sample application as current user:

   

   and then attach to it – everything works as expected (debugger is attached). Then if in the second instance of Visual Studio (also started under the same, current, non-admin user) I make an attempt to attach to the same process once again, I get following COMException:

   

   The HRESULT is the same as before...

Question:

As you can see the HRESULTs are same for these 2 different actions. Why? How to distinguish the fact that in the second case I’m trying to attach to process to which the debugger is already attached (which is different that first case - attaching to process to which we simply have no rights)?

Answer 1

HRESULTs are COM's weakness, error codes don't scale well. At least part of the reason that Java ate Microsoft's lunch.

The error code doesn't mean anything more than "could not attach debugger", there isn't any room to also unequivocally explain why it couldn't be attached. Nothing similar to, say, an InnerException. So you just get a diagnostic for what couldn't be done, not a diagnostic for why it couldn't be done. It is as good as its going to get, maybe they'll implement IErrorInfo some day so you'll at least get a textual description. More likely is that the Visual Studio extension model is going to get a major overhaul first. Which is the way the wind is blowing, add-ins were deprecated in VS2013.