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

Alex

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.

6 Replies

Know the answer? Post it — somebody with the same question will find it here.

Sam Hobbs14y ago
Thank you for the follow-up. I am sorry that I was not more help.
Alex14y ago
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.
Alex15y ago
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 Hobbs15y ago
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.
Alex15y ago
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 Hobbs15y ago
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.