Re: Exception in COM - COM Discussion Boards

18-Jun-09 21:31

I use __try and __except in my code to catch exception.But it doesn't work.Who can tell me how to catch exception in COM?Thanks in advance.

modified on Wednesday, July 22, 2009 3:07 AM

Stuart Dootson18-Jun-09 22:08

Stuart Dootson

18-Jun-09 22:08

What sort of exception - what's throwing it?

__try and __except == structured exceptions[^], IIRC.

try and catch == C++ exceptions[^]

COM, on the other hand, doesn't throw exceptions - it returns status codes in HRESULTs. Which is why I ask - where do these exceptinos come from?! Share some code, man!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

denghp18-Jun-09 22:19

18-Jun-09 22:19

for instance, there is a method in COM named f defined as followed
void f()
{
__try
{
int* pInt = NULL:
*pInt = 0;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
printf("exception!\n");
}
}

when I call f(), an exception is raised and the programe crash.

Stuart Dootson18-Jun-09 23:01

Stuart Dootson

18-Jun-09 23:01

That's COM? Mmmmm.

denghp wrote:
int* pInt = NULL:
*pInt = 0;

Look at your code. You're writing to a null pointer. Yes, you get an access violation. What is pInt meant to point at?

The problem you need to solve is not catching the exception - your problem is rewriting the code so it doesn't cause the access violation in the first case.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

denghp18-Jun-09 23:05

18-Jun-09 23:05

I just want to test if __try and __except is in effect, so I write codes like that.The result is it doesn't work.

Stuart Dootson18-Jun-09 23:15

Stuart Dootson

18-Jun-09 23:15

So....your question had nothing to do with COM...OK

Anyway - I wrote this sample program:

#include <windows.h>
#include <iostream>

int f()
{
   __try
   {
      *(int*)0 = 0;
      std::cout << "good!\n";
   }
   __except( EXCEPTION_EXECUTE_HANDLER)
   {
      std::cout << "exception!\n";
   }
   return 3;
}

int main()
{
   f();
}

and compiled it with VS2008 using the command cl -EHa a.cpp (you apparently need -EHa for structured exception handling to work correctly).

As expected, it printed exception! - the structured exception handler was called correctly.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

denghp18-Jun-09 23:25

18-Jun-09 23:25

OK，I will check my project configuration.Thank you very much.

Md. Marufuzzaman6-Jul-09 21:58

Md. Marufuzzaman

6-Jul-09 21:58

Hi,
I think you should through the exception from you COM+ function, & show / manage detail from where you call the function. Like

Try
{
}
Catch(Exception ex)
{through ex;}

Thanks

Md. Marufuzzaman

ATL COM server crash

Harish Pulimi17-Jun-09 5:36

Harish Pulimi

17-Jun-09 5:36

Hi
I haven an ATL COM in-proc server which is crashing randomly. I would not say it as a crash, the server just vanishes after running successfully for 9-10 hours. And then restarts immediately on the next call to CreateInstance() by the clients. I am unable to debug as this is not a crash and happening randomly. Though I'm not providing much details as the code base is huge, any thoughts just to start with would be very much appreciated. I observed that FinalRelease() was called before the server vanishes, but for the initial 10 hours many clients have called FinalCOnstruct() and FinalRelease() without any issues.

Thanks in advance
Harish

Roger Stoltz17-Jun-09 6:42

Roger Stoltz

17-Jun-09 6:42

Harish Pulimi wrote:
the server just vanishes after running successfully for 9-10 hours

I don't understand what you mean by this. How did you reach such conclusion?
As I interpret your complete description it seems like you're describing the expected behaviour.

I'm quite confident that clients don't call FinalConstruct() or FinalRelease() through any interface. Those functions are called internally by the framework. FinalConstruct() is called when the server is created by a client and FinalRelease() is called when the reference count reaches zero and the server consequently should be destroyed.
This means that if you're experiencing a lot of calls to FinalConstruct() and FinalRelease() your server is being created and destroyed multiple times by its client.

If this is not your intention, I suggest you put a breakpoint in FinalRelease() and you should be able to see the origin of the call in the call stack debug window when the breakpoint is hit. It looks like you expected the server to be created once and then stay alive until the application is closed, but this doesn't seem to be the case given your error description.

Perhaps I have misunderstood what you mean by "vanish" and if that's the case please elaborate on the subject a bit. It could mean that CreateInstance() fails after 9-10 hours, but I think you would have written that as a description of the error if this was the case.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Harish Pulimi17-Jun-09 21:46

Harish Pulimi

17-Jun-09 21:46

Hi Roger

Thanks a lot for your reply and apologies for not providing more details.

The architecture is like I have an exe which keeps track of all the servers that will be created by the clients through CreateInstance() calls. This exe needs to run all the time and if not already started, it will start through the next CreateInstance() call made by a client. The problem is that the exe runs fine for around 10 hours and after that it suddenly vanishes i.e. the process just stops, there is no crash reported and the exe immediately starts with the next CreateInstance() call but loses all the previous data. This happens only on some PCs, so I tried putting my debug build on that PC, but still there is no exception, no crash reported, so I thought this could be a heap corruption.

To reproduce this, I have created a test harness where around 100 clients continously bombard the exe with CreateInstance() calls and I could get an exception as follows, not sure whether this is the same crash but it seems like similar to the actual problem. Any idea how to debug the exceptions in OLE32.dll?
First-chance exception in AniteLicenser.exe (OLE32.DLL): 0xC0000005: Access Violation.
OLE32! 77600f3b()
OLE32! 77600ee9()
OLE32! 77600ba0()
OLE32! 7752ad31()
OLE32! 7752ac56()
OLE32! 776007f5()
OLE32! 77602df3()
OLE32! 77600715()
RPCRT4! 77e794bd()
RPCRT4! 77e79422()
RPCRT4! 77e7934e()
RPCRT4! 77e8a384()
RPCRT4! 77e8a3c5()
RPCRT4! 77e7bcc1()
RPCRT4! 77e7bc05()
RPCRT4! 77e76caf()
RPCRT4! 77e76ad1()
RPCRT4! 77e76c97()
KERNEL32! 7c80b713()

One time I could get the following call stack, seems something is going wrong in the Release() call, but the same exe runs fine for around 10 hours (100s of instances were created and released successfully in the meantime) and on a different PC, this exe ran fine for around 3 days:
ATL::_QIThunk::Release(ATL::_QIThunk * const 0x0171d440) line 2734 + 11 bytes
OLE32! 7750d339()
OLE32! 7750d09a()
OLE32! 7752deb3()
OLE32! 7752dcc8()
OLE32! 7752db6a()
RPCRT4! 77e799f4()
RPCRT4! 77ef421a()
RPCRT4! 77ef4bf3()
OLE32! 77600c15()
OLE32! 77600bbf()
OLE32! 7752ad31()
OLE32! 7752ac56()
OLE32! 776007f5()
OLE32! 77602df3()
OLE32! 77600715()
RPCRT4! 77e794bd()
RPCRT4! 77e79422()
RPCRT4! 77e7934e()
RPCRT4! 77e8a384()
RPCRT4! 77e8a3c5()
RPCRT4! 77e7bcc1()
RPCRT4! 77e7bc05()
RPCRT4! 77e76caf()
RPCRT4! 77e76ad1()
RPCRT4! 77e76c97()
KERNEL32! 7c80b713()

Roger Stoltz18-Jun-09 0:57

Roger Stoltz

18-Jun-09 0:57

Harish Pulimi wrote:
apologies for not providing more details.

No worries. There's no point in posting a lot of details before it's clear what to provide the details for. Smile | :)

I don't really understand your architecture and how this mysterious "exe" keeps track of the running servers. It seems like the "exe" is a COM server itself.... Unsure | :~

Harish Pulimi wrote:
I have an exe which keeps track of all the servers

How is this accomplished if CreateInstance() isn't called from this "exe" in order to create the other servers?

Harish Pulimi wrote:
This exe needs to run all the time and if not already started, it will start through the next CreateInstance() call made by a client.

How is the "exe" started?
Is it an out-of-process COM server and "started" with CreateInstance()?
Perhaps you should consider to have it running as a service.
If the "exe" is an out-of-process COM server that doesn't run as a service, it is quite expected that it will terminate if its reference count reaches zero unless you've provided functionality to prevent it.

The call stack snippets you've provided implies that the call to the server is made in an RPC-thread which means that you're using a multithreaded solution.
In such case it's fairly reasonable to suspect thread synchronization issues, but first we have to agree on how the apartments are set up. So I have a couple of questions for you...

Are you certain that every thread that uses any kind of COM related stuff contains a call to ::CoInitialize() or one if its equivalents?
Are you certain that every thread that instantiates a COM server has a message pump that will not be blocked?
What threading model have you registered below the server entry in the registry?
In other words; what value is assigned to the registry value "ThreadingModel" in the registry entry HKCR\CLSID\{<your server CLSID>}\InprocServer32?
How is the apartment initialized from which you create the server?
I suspect it is initialized as a multithreaded apartment.
Are you using proper marshalling? How?

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Harish Pulimi10-Feb-10 2:28

Harish Pulimi

10-Feb-10 2:28

Finally found the bug. In the client code COM library was not being initialized properly.
Because of this, it is unable to tear down the connection to the server. Now everything works as expected.