Application Dissapearing After Linking With COM
-
I have a COM dll written in c# that is being called from various c++ applications. On only 1 machine so far, I am having the application that calls the COM dll just dissapear and unload. I am unsure what is happening. I have try catches all through the code trying to catch the exception getting thrown, but it doesnt catch, just unloads. What types of exceptions or security issues would cause the entire application to unload without getting caught? It is worth noting that so far the only applications that are failing are VS6 MFC apps. Apps that are built in VS2005, or that are instantiated in a .net environment do not produce this issue. The scenario is this. C++ app calls VS2005 dll which holds refrences to the c# COM dll. 2005 dll calls into c# COM which provides webservice access to the caller. It is also worth nothing that a static method calls a singleton class in the C# COM dll. (Singleton is for websvc access). I know it is not much to go on, but I need ideas about general security problems or COM issues with what I have described, or even what type of exception is uncatchable and unloads the app :). Thanks in advance.
-
I have a COM dll written in c# that is being called from various c++ applications. On only 1 machine so far, I am having the application that calls the COM dll just dissapear and unload. I am unsure what is happening. I have try catches all through the code trying to catch the exception getting thrown, but it doesnt catch, just unloads. What types of exceptions or security issues would cause the entire application to unload without getting caught? It is worth noting that so far the only applications that are failing are VS6 MFC apps. Apps that are built in VS2005, or that are instantiated in a .net environment do not produce this issue. The scenario is this. C++ app calls VS2005 dll which holds refrences to the c# COM dll. 2005 dll calls into c# COM which provides webservice access to the caller. It is also worth nothing that a static method calls a singleton class in the C# COM dll. (Singleton is for websvc access). I know it is not much to go on, but I need ideas about general security problems or COM issues with what I have described, or even what type of exception is uncatchable and unloads the app :). Thanks in advance.
-
Usually an app going *poof* is caused by the instruction ptr sending it off into the Twilight Zone. Most likely your TLB's and DLL's are out of synch. I.e. your application was compiled against a TLB that does not match the DLL.
Depends what is meant by “poof”. Normally, in the circumstance you describe (“instruction ptr sending it off into the Twilight Zone”), you'll get some kind of “this application has performed an illegal operation and will be terminated” dialog before it’s terminated. There are some situations where the damage to the process is such that the OS can’t get that far and the application simply vanishes without any warning whatsoever. One cause of this is a corrupted
EXCEPTION_REGISTRATION
linked list.Steve
-
Depends what is meant by “poof”. Normally, in the circumstance you describe (“instruction ptr sending it off into the Twilight Zone”), you'll get some kind of “this application has performed an illegal operation and will be terminated” dialog before it’s terminated. There are some situations where the damage to the process is such that the OS can’t get that far and the application simply vanishes without any warning whatsoever. One cause of this is a corrupted
EXCEPTION_REGISTRATION
linked list.Steve
Well... I guess I could have my files out of sync... anything is possible at this point. It is one of those issues that makes you pull your hair out. I get no information whatsoever from this. I do know from my tracing that it is blowing away in the COM assembly itself, right when it is about to access the webservice. It always goes away at the same place. It just seems odd that it would only be these 2 MFC apps that would get messed up when at least 8 other applications (VS2005 or .net encapsulated admittedly) use the same assembly. At first I thought it was a security problem, so I demanded unrestricted permission... and no exception. I just wish there was a way to figure out what was going on. This machine does not have VS and can not have it installed, so I have to debug with tracing. Not very helpful for this scenario.
-
Well... I guess I could have my files out of sync... anything is possible at this point. It is one of those issues that makes you pull your hair out. I get no information whatsoever from this. I do know from my tracing that it is blowing away in the COM assembly itself, right when it is about to access the webservice. It always goes away at the same place. It just seems odd that it would only be these 2 MFC apps that would get messed up when at least 8 other applications (VS2005 or .net encapsulated admittedly) use the same assembly. At first I thought it was a security problem, so I demanded unrestricted permission... and no exception. I just wish there was a way to figure out what was going on. This machine does not have VS and can not have it installed, so I have to debug with tracing. Not very helpful for this scenario.
What about the debugging tools for Windows (WinDbg, etc.)? These are not as easy to use as VS, but I have been able to find some deep and nasty problems with them. It was a similar situation where I had to debug in release mode with no VS.
modified on Thursday, March 5, 2009 2:57 PM