Multi code applications and the clr


I've a multi-code app, with the executable and dlls all built within Visual Studio 2005. The 'chain' is a VB front-end, C# dll, and a VC++ dll.

The app builds and runs fine in debug mode, and in the VC++ dll, again the whole app runs perfectly well whether the VC++ dll is built as managed code (with the clr compile arg) or unmanaged.

However, in release mode not all is well. If the VC++ dll is built as managed the app does run fine, but when I remove the clr compilation args so the dll is unmanaged, the app crashes with no dump file. I've used lint to check for any memory-leaks, race conditions, buffer overruns etc in the VC++ dll but all was fine. This is a high-frequency application, so ideally I need the VC++ dll to be unmanaged. The speed difference between managed and unmanaged is too great to just settle for managed.

Once the VC++ dll has finished its processing, it calls a C# delegate via a function ptr.

Has anyone else experienced this problem with multicode apps or, is using unmanaged code for this purpose not recommended/possible?

Who is Participating?
Joel CoehoornConnect With a Mentor Director of Information TechnologyCommented:
That would explain why managed C++ works- the framework will make sure the pointer is valid.  It also explains why debug mode works, but then the framework is less likely to re-arrange things on you.
Joel CoehoornDirector of Information TechnologyCommented:
Add logging capabilities to your C++ dll, so you can get a picture of where things are as it executes in release mode and at what point it crashes.
oliverskAuthor Commented:
Hi jcoehoorn.

I'd already done that, and whilst it was never the same line of code every time, it was always around the function ptr call to the C# delegate.

But again, no crash file. In debug builds (wth and without the clr) no problems, release mode with clr no problem, but release mode without the clr a crash.
7 new features that'll make your work life better

It’s our mission to create a product that solves the huge challenges you face at work every day. In case you missed it, here are 7 delightful things we've added recently to monday to make it even more awesome.

Joel CoehoornDirector of Information TechnologyCommented:
I'm wondering if maybe your C# delegate isn't property 'pinned'.  In unmanaged C++, when you get a pointer to something all you have is an address.  In managed C#, the framework is free to move things around as objects go in and out of scope.  So an unmanaged pointer to a managed object of any type, including functions, could easily become invalid.
oliverskAuthor Commented:
This is looking promising.

I've now pinned the delegate:

Callback = new Communication.MESSAGECALLBACK(WrapperCallBack);
CallbackPinned = GCHandle.Alloc(Callback, GCHandleType.Pinned);

It all compiles, but when I run the app it crashes on the GCHandle line: "Object contains non-primitive or non-blittable data."

As you can tell I'm still a novice when it comes to .NET so any other assistance you can give is again very much appreciated.


oliverskAuthor Commented:
I've now also tried
CallbackPinned = GCHandle.Alloc(Callback);

This works for 1 callback, but then crashes/exits on all subsequent callback attempts. This is much like the behaviour experienced beforehand without GCHandle.

Thanks again.
oliverskAuthor Commented:
Got me on my way to reading more about garbage collecting with the CLR where I found the correct way to declare my delegate.
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.