ExcelDNA / Excel / Other libraries = crash on exiting

329 views
Skip to first unread message

stefan barrett

unread,
Nov 1, 2011, 4:16:07 AM11/1/11
to Excel-DNA
I have a existing workbook, sort of large, which calls into various
COM & Excel libraries to get data - and which works.
I wanted to add some more functionality to it, so decided to write a
C# addin exposed via COM & ExcelDNA.
I'm using ExcelDNA v0.29, and using ComServer functionality to ensure
that everything is loaded into same AppDomain.

The first version only uses VBA (Actual Excel functions comes in next
release), and wanted to do something with Excel, so did:

var excelApp = ExcelDnaUtil.Application;

and other things.

The application ran correctly, no issues.
Until I ran it standalone (not launched from VS), where it crashed
when closing Excel.

Microsoft Office Excel has encountered a problem and needs to
close etc......................

Debugging reveals that there has been a memory corruption, but gives
no clue where/why the problem happened.

Running either the existing code, or the ExcelDNA related code
seperately works ok.
I reduced it down to a test app, which does nothing except get the
Application object, and refers to our existing libraries, and still
get the crash.

Does anybody have any suggestions for how we could diagnose the
problem?

I might have 1 clue, namely that to bypass the problem, for the
moment, I took ExcelDna out and passed in the Application object from
VBA to C#.
Unless we cleared up every single reference count, we seemed to get
the same crash. This did make me wonder if ExcelDNA could be failing
to manage the reference counts correctly - had a quick look at code,
and nothing obvious.
I've not seen anything which suggests I can't use
ExcelDnaUtil.Application from a COM called function...

Govert van Drimmelen

unread,
Nov 1, 2011, 4:42:00 AM11/1/11
to Excel-DNA
Hi Stefan,

It sounds like a complicated mix you have. Simplifying the
interactions, e.g. moving more stuff into the .NET side, or not
accessing Excel from the .NET COM exposed components, might be the
easiest way to stabilise things.

Excel-DNA does very little intervention when you use the COM
automation interface. The main Excel-DNA specific issue is how the COM
objects, particularly the root Application object, gets marshalled
between different apartments. E.g. there is a big difference whether
you use the COM model from the main thread in an Excel-DNA add-in only
- which always seems to clean up properly even if there are
outstanding references, vs. using the COM interface from another
thread, where you have to clean up each and every COM interface before
the Excel process will close properly.

Anyway, I have some ideas you can explore:
The ways ExcelDnaUtil.Application gets that Application object might
mean that it gets marshalled into the .NET apartment from the main
Excel thread. I suspect if you are calling Excel-DNA from VBA, then
calling ExcelDnaUtil.Application, you are effectively getting a
marshalled version of the COM interface. Avoiding that might help.
Correlating threads between the Excel-DNA add-in's AutoOpen and the
VBA calls might shine some light.

You can experiment with getting the Application object in different
ways:
1. Get and keep it in your AutoOpen.
2. Retrieve it every time you need it.
3. Add an ExcelRibbon-derived class or ExcelComAddIn-derived class
(with the workaround discussed here:
http://groups.google.com/group/exceldna/browse_thread/thread/143bd77dec8e6579
or the latest version from the CodePlex source). This will keep the
Application object passed to the COM connect event, and pass this back
every time you call ExcelDnaUtil.Application from the main thread.

Now, your crash sounds a lot like the problems that arise when
embedding into other Office apps. This was discussed here:
http://groups.google.com/group/exceldna/browse_thread/thread/7374ccad1fae0436
with some resolution here: http://groups.google.com/group/exceldna/browse_thread/thread/5b5e5948f46d402a.

I think the conclusion is that using NetOffice (http://
netoffice.codeplex.com) gives you a way to manage the outstanding COM
references better.

But I still vote for just simplifying stuff a bit.
I look forward to hearing what you discover.

Regards,
Govert

Stefan

unread,
Nov 1, 2011, 5:41:50 AM11/1/11
to exce...@googlegroups.com
On first glance, storing the Excel Application in a static variable from
either a Addin.AutoOpen or from a Excel function works ok.
But if I then call a COM exposed function, which accesses the application
object in the static variable (and returns Application.Name.Length), Excel
will crash on close.

Will explore the options mentioned below.

Thanks

Hi Stefan,

Regards,
Govert

--
You received this message because you are subscribed to the Google Groups
"Excel-DNA" group.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to
exceldna+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/exceldna?hl=en.

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1834 / Virus Database: 2092/4588 - Release Date: 10/31/11

Stefan

unread,
Nov 2, 2011, 1:23:32 AM11/2/11
to exce...@googlegroups.com
On further analysis, we seem to have narrowed this down to the following scenario:
1) have a C# DLL registered with ComServer=true, ExcelDNA 0.29, which accesses ExcelDnaUtil.Application
2) have another addin, e.g. *.xlam, or in our case *.xla - there doesn't need to be any code in them, just be referenced from Excel.
In which case Excel (2007) crashes on exit.

Any thoughts?

Stefan


Sent from my iPhone

Govert van Drimmelen

unread,
Nov 2, 2011, 4:53:56 AM11/2/11
to Excel-DNA
Hi Stefan,

I presume you .xla add-in must have some code in to call the Excel-DNA
COM server...? So the code the accesses ExcelDnaUtil.Application must
run in the COM Server context. Just having a .xla add-in that has no
reference to the Excel-DNA add-in isn't likely to be an issue.

Perhaps the rule is:
* Don't call ExcelDnaUtil.Application from inside an Excel-DNA COM
server when in the context of a call to the COM server from VBA.

Could you send the test application for me to try out, or post
somewhere online?

Thanks,
Govert
> >http://groups.google.com/group/exceldna/browse_thread/thread/143bd77d...
> > or the latest version from the CodePlex source). This will keep the
> > Application object passed to the COM connect event, and pass this back
> > every time you call ExcelDnaUtil.Application from the main thread.
>
> > Now, your crash sounds a lot like the problems that arise when
> > embedding into other Office apps. This was discussed here:
> >http://groups.google.com/group/exceldna/browse_thread/thread/7374ccad...
> > with some resolution here:http://groups.google.com/group/exceldna/browse_thread/thread/5b5e5948....
Reply all
Reply to author
Forward
0 new messages