creating a COM object is taking a long time

I have a standalone application that has a COM interface to a power supply. Running the standalone works fine. I've used the attached code in a VC6 project. The line
IPowerSuppyPtr PScom(__uuidof(PowerSupply)); takes approximately 12 seconds to execute. I have run this code while in the debugger and noticed that when executing this line, the debug window shows a couple of "first chance exceptions" before the command finishes. Any ideas what might be causing the delay or the exception messages? Or how to debug it?

But here is the interesting part. The command, once finished produces a valid IPowerSupply object that works correctly. The remaining lines in the code run correctly and are accurate.  

Thanks, Brian

#import "kvdpowersupply.tlb" no_namespace

bool TestHeadPowerIsOn()
{
	try{
	HRESULT hr=CoInitialize(NULL);
	if (!SUCCEEDED(hr)) {
        CoUninitialize();
		return false;
	}
	IPowerSupplyPtr PScom(__uuidof(PowerSupply));

	long result;
	PScom->get_PowerSupplyIsOn(&result);
	CoUninitialize();
	return result==1;
	}
	catch(...)
	{
		CoUninitialize();
		return false;
	}
}

Open in new window

BrianDumasAsked:
Who is Participating?
 
jkrConnect With a Mentor Commented:
I'd cfheck if your app tries to locate DLLs/components for that COM object on remote drives etc. - you can pretty much rule out first-chance exceptions, because 'First-chance exception in xxx...' just means that a function from within the 'xxx' caused an access-violation exception that was handled successfully inside the SEH frame that was active when the exception occurred. You can think of it being the same as if you use code like this:

long l;

__try // set up current SEH frame
{
CopyMemory ( &l, 0, sizeof ( long)); // read from 0x00000000
}
__except( EXCEPTION_EXECUTE_HANDLER) // handler for current frame
{
puts ( "We knew that this would go wrong...");
}

So let's hope that the MS progrmmer knew what they were doing ;-)

(Additional info: MS KB Article Q105675)


The article can be found at http://support.microsoft.com/support/kb/articles/q105/6/75.asp 

A first chance exception is called so as it is passed to a debugger before the application 'sees' it. This is done by sending a 'EXCEPTION_DEBUG_EVENT' to the debugger, which can now decide whether it is passed to the apllication to handle it or 'ignore' it (e.g. like an 'EXCEPTION_BREAKPOINT' aka 'int 3'). If the exception isn't handled, it becomes a '2nd chance' exception, the debugger 'sees' it the 2nd time and will usually terminate the program (without using a debugger, these exceptions end up at 'UnhandledExceptionFilter()' which will also signal the exception to the user with one of these 'nice' message boxes and terminate the program, also...)


In short: This message is only generated by a debugger & you can safely ignore it...
0
 
ambienceConnect With a Mentor Commented:
When the COM object is created, the dll on loading might be doing some initialization stuff like initializing and detecting hardware devices like power-supply. Depending upon the implementation it might also be doing some other stuff that could take a long time.
What happens if you run two instances of the app: the second one exhibits the same delay?
0
 
BrianDumasAuthor Commented:
Never did get a solution, but these two response provided helpful information
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.