Latest C# build of COM object crashes C++ application

Question

Hello everybody I've got some general problem while calling of interfaces of COM object written under .NET (C#) from my C++ application. I'm using Visual Studio 2005. Anytime I'm calling functions from these COM object my C++ application crashes with some …run-time error…. But it happens only on machines where Visual Studio has not been installed which of course are client machines. On any machine with Visual Studio installed – no problem. And another thing - this COM object (dll) which was built 1-1.5 years ago is working fine on all machines including machines without Visual Studio I don't do changes in this COM objects often so I cannot tell exactly when it started to happen roughly as I mentioned before 1-1.5 year ago. So I figure something's been changed during the build process because if the COM dll was built 1.5 years ago it works fine. But if I build exactly same dll with exactly same code without any smallest changes now this dll will crash my C++ application. Thank you in advance for any suggestions/advices. R.

Sam Hobbs · Answer

Thank you for the follow-up. I am sorry that I was not more help.

Alex · Answer

Hello Sam Because you'd spent some of you time trying to help me with this problem I feel obligated to inform you what was causing it. A couple of years ago I'd started to work on another interface related to Crystal Report to be implemented in the same COM object. This implementation required adding some CrystalDecisions references. For example CrystalDecisions.Shared. I haven't finished this implementation yet but corresponding references are still there. And now finally I've figured that this CrystalDecisions were crashing my program on machines where Visual Studio was not installed. Indeed on machines with VS this CrystalDecisions being added to the system along with Visual Studio but on machines without VS some extra installation of Crystal Reports SDK or something is required. Anyway now everything looks Ok Thanks again for your time Best regards R.

Alex · Answer

Thank you Sam again but I cannot get away from the fact that I have an archive of the project which was used to build a good COM dll which is working on all machines and if I'm using exactly same project (from archive) to build same dll today I'm having this problem. Moreover because this is C# forum I didn't mention that I have EXACTLY SAME problem with my VB COM object which addresses completely different issues has nothing to do with my C# dll. But exactly same problem nothing I can change in it lately because application crashes while old version of this VB COM is working fine!!?? This bugs me most of all and tells me that the ssue probably has nothing to do with the code of this COM objects. So the only thing probably I can do - build another COM project adding one function by one always making sure that applications can use it and maybe at some point the reason of my troubles will come up... Best regards Alex R.

Sam Hobbs · Answer

It is not clear to me where (whether the COM object or the user of it) the error is occurring and I don't know what type of error it is in terms of whether it is a .Net error or something else. If it is a .Net exception then there is often an InnerException that might help. What is the source code that is located where the error is occurring? What is it that is getting the error? It is possible that the COM object is using something else such as another COM object that is built with a debug configuration. Do you know how to look at a call stack? That might help but only a possibility I admit it is not likely to help.

Alex · Answer

Thank you Sam for such a quick reply. Honestly I didn't expect any answers so fast but normally I'm trying to describe the issue as detailed as possible. The error I'm getting – is meaningless something like ...because of runtime error… application will be shutdown…. Same error one can get while trying to call COM functions without actually registering this object. Now here is the thing which is hard for me to explain. I have .dll (and .tlb for build) from March 2010 which can be run successfully on any machine. I also have an archive (backup) of this COM project for the same date. But if I'm going to use this archive to build these .tlb and .dll files NOW it won't work. The only explanation I can think off – it's if something was changed (some settings) in my Visual Studio 2005 environment though I couldn't find any. And I also made sure that for my C++ project I'm using .tlb and .dll from Release folder rather then Debug. There is no also any problems with the code itself because for the testing purpose I've added to this interface function which doesn't expect any parameters and the only thing this function does – is saying Hello world!. And after I call just this function - C++ application still crashes. And there is no problem for me with the licensed software because I'm MSDN subscriber and using full VS version. Anyway thanks for your suggestions will try to write another COM object from scratch and see if it will work. Best regards R.

Sam Hobbs · Answer

Absence of a crash does not determine the certainty that the problem did not exist prior to the crashes happening. It is entirely possible that the bug has existed loinger but without causing a crash. Note that it is very frustrating for people that try to help when a question says crash (and other things like that) without details. Vague descriptions such as that can only result in vague responses. Since it only happens in systems without VS it sounds as if there are debug versions of the runtime libraries. If someone has copied the debug version of libraries to systems without VS then that is a violation of the licenses and it has obsured the real problem. Please ensure that there are no debug versions of the C++ runtime iinstalled in the systems without VS. Also ensure that there are no debug configurations used in the builds fo your projects. Another possible explanation is that your program is doing something that is getting an error but the error is being ignored and that results in a subsequent catastrophic failure. It is likely that the problem is a combination of more than one that I am suggesting here.