CoGetClassObject gives many First-chance exceptions in ATL project. Should I worry?

Question

Hello, I have written a COM object that in turn uses a thrid party ActiveX control. In my FinalConstruct() for my COM object, I instantiate the ActiveX control with the follow code:

  HRESULT hRes;
  LPCLASSFACTORY2 pClassFactory;
  hRes = CoInitializeEx(NULL,COINIT_APARTMENTTHREADED);
  bool bTest = SUCCEEDED(hRes);
  if (!bTest)
   return E_FAIL;
  if (SUCCEEDED(CoGetClassObject(__uuidof(SerialPortSniffer), CLSCTX_INPROC_SERVER, NULL,
   IID_IClassFactory2, (LPVOID *)(&pClassFactory))))
  {  ... more set up code

When I step over the line if (SUCCEEDED(CoGetClassObject(__uuidof(SerialPortSniffer), ..., I get 20+ lines in the Output window stating:

First-chance exception at 0x0523f82e in SillyComDriver.exe: 0xC0000005: Access violation writing location 0x00000000.

I also get the lines:

First-chance exception at 0x051e3f3d in SillyComDriver.exe: 0xC0000096: Privileged instruction. First-chance exception at 0x100ab9e6 in SillyComDriver.exe: 0xC000001D: Illegal Instruction.

Notice these are first-chance exceptions. The program runs as expected I can access the third party methods/properties. Still, I'm left wondering why they are occurring. Perhaps my way of instantiating the ActiveX control (for which I want use of it's methods/properties and not it's GUI stuff) is incorrect? Besides the code I'm showing, I also put the line

#import "spsax.dll" no_namespace 

in the stdafx.h That's all the code necessary for my simple demo project. I noticed this problem because I had (inadvertently) set the "break on exceptions" options in my "real" project and it was breaking on this line. Once I removed it, it also works.

If you're read this far thank you, and perhaps I can ask one other minor question. In my demo project, if I right click on SerialPortSniffer and "go to definition", it takes me to the file C:....\AppData\Local\Temp\spsax.tlh. Can someone explain that? Finally, in my "real" project, right clicking on SerialPortSniffer and going to difinition leads to "The symbol 'SerialPortSniffer' is not defined". It doesn't seem to affect the program though. Is there some setting I've messed up?

By the way, all my code is written w/ VS2008.

Thanks, Dave

Answer 1

It's usually nothing to worry about.

When an exception is thrown, the debugger is notified and depending on the debugger configuration, it may stop the application or let the application resume normally. This is a "first-chance" exception. If the application resumes, then it may catch the exception, and do whatever is necessary in the exceptional case.

If the application does not handle the exception, it becomes a "second-chance" exception and the debugger is notified again. The debugger is usually configured to stop the application at this point to let you see what went wrong.

So if you get a first-chance exception and not receive a second-chance exception later, it's usually means that nothing is wrong, and the application is handling exceptions in a "graceful" matter.

(Also see http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx)

Answer 2

These are definitely the worst kind of hardware exceptions that you'd ever could encounter in a Windows program. There is absolutely no reason that something as simple as a serial port sniffer should ever throw exceptions like that, let alone catch them and handle them.

Still, it does and there's nothing you can do about it. You can only hope and pray that this doesn't byte you in the ass some day. Personally, that component would quickly end up on my thrash heap.

The #import statement auto-generates code from the COM type library. It generates a .tlh file with declarations and a .tli file with COM method wrappers. The .tlh file contains smart pointers (xxxxPtr) to make instantiating the COM object and calling its methods easy. That's why "Goto Definition" takes you to that file.