IRibbonUI.invalidate crashes Excel 2010 custom ribbon with COM exception 0x80004005... sometimes - c#

OK, this is a strange problem we've got with our Add-in for Excel. It works well with Excels 2003 - 2013, but from time to time we get reports about our ribbon disappearing. It seems to happen only on start of Excel 2010 and when opening sheet with our data in it. Our add-in is huge and with problem happening once in a few weeks, there is little I can show you, but I will write some specifics and hope someone can come up with any recommendation on what to do next.
Right now, it seems to be happening only with Excel 2010 (not absolutely sure about this, though)
It happens in a callback so it smells like synchronization issue, but not sure if that should be happening at all
This is the code that gets called in our callback
private void SetShowNotConnectedButton(bool show) {
if(_ribbon != null) {
_ribbon.Invalidate();
}
if(_notConnectedButton != null) {
_notConnectedButton.Visible = show;
}
}
So my question is, is there any way I don't know of for calling invalidate from a callback, or anyone knows any other issue that might be there with invalidation of ribbon in any version of Excel.

Related

Why do instances of Excel not close when opened via interop, even though Word apps close just fine?

As far as I can see, this is not a duplicate question, as the question here is about why the accepted answers of seemingly duplicate questions, do not solve my issue in what appears to be the same circumstances.
For days, I have been struggling with my application failing to end instances of Excel, which have been opened using interops.
My application opens and closes Word applications just fine (i.e. the process disappears from task manager), but not Excel apps. Excel always remains open in the task manager. After much, much searching - this seems to be the definite guide on how to close Excel instances. However, if I copy and paste that exact example code - and run it as a console app, in either .NET Framework, or .NET 6 - Excel still fails to close, exactly as per the behaviour of my application.
Presumably, this must be an issue with the latest/newer versions of Word?
Completely and utterly lost on this one...
Code from the above link that leaves Excel open:
using System;
using System.Runtime.InteropServices;
using Microsoft.Office.Interop.Excel;
namespace TestCsCom
{
class Program
{
static void Main(string[] args)
{
// NOTE: Don't call Excel objects in here...
// Debugger would keep alive until end, preventing GC cleanup
// Call a separate function that talks to Excel
DoTheWork();
// Now let the GC clean up (repeat, until no more)
do
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
while (Marshal.AreComObjectsAvailableForCleanup());
}
static void DoTheWork()
{
Application app = new Application();
Workbook book = app.Workbooks.Add();
Worksheet worksheet = book.Worksheets["Sheet1"];
app.Visible = true;
for (int i = 1; i <= 10; i++) {
worksheet.Cells.Range["A" + i].Value = "Hello";
}
book.Save();
book.Close();
app.Quit();
// NOTE: No calls the Marshal.ReleaseComObject() are ever needed
}
}
}
It does seem a bit weird with the current version of Excel. It depends on how the console program is run. If I double-click in Windows Explorer, it closes perfectly like it used to. But if I run from a console window, then Excel stays open until the console window closes. Similarly when I run from the debugger, Excel only closes when the Debug window is closed and not when the driving process is terminated. It would be good if you can confirm this too.
I suspect Excel has added some defensive code to not close in specific situations - maybe watching for a 'parent' window to close, or something similar.
Aaaaand then. . . . just as I try again after posting this, Excel starts closing beautifully every time, however I run it.
OK, so I've stumbled across the solution to this. The solution is really rather an unrelated issue.
My instance of Excel had the Analysis Toolpak enabled (spelling mistake included!), from some work I was doing a few months back. The add-in is found at File --> Options --> Add-ins --> Analysis ToolPak.
I've disabled the add-in, and now Excel apps open and close just fine, using only explicit garbage collection, as expected.
I should add - the behaviour is still different to Word. Closed Word files kill Word almost instantly on closure of the document, even before the explicit GC. With Excel, I still have the close the form where the Workbook was opened from, which then calls the explicit GC, and sometimes it takes a few seconds, sometimes 30 seconds, sometimes it takes a minute - but having disabled the add-in, Excel does eventually get stopped.

Exception from Word.ApplicationClass.Activedocument all of a sudden

I have this single line of code in a Word VSTO add-in project which used to work but suddenly doesn't anymore:
Microsoft.Office.Interop.Word.Document doc = Globals.ThisAddIn.Application.ActiveDocument;
Before it just returned the Document object as it was supposed to, and I could read from and manipulate it without issue. But now it throws a System.Runtime.InteropServices.COMException exception. "Word has encountered a problem." Very helpful. The exception contains an HRESULT of 0x800A13E9, which hasn't helped me so far either. Out of memory or something? Idk.
The new behavior seems to have started around New Year's Eve (not sure since I wasn't using the add-in for the past couple of weeks), and it started while the add-in was installed, i.e. nothing in the code was changed, recompiled or reinstalled to make it happen. I've since rebuilt the project, thinking maybe a certificate had expired or something, but the error still occurs.
It's maybe worth noting that I can still access other properties of the Application instance. For instance, this line does not throw an exception:
int numDocuments = Globals.ThisAddIn.Application.Documents.Count;
But then when I iterate over the Documents collection with foreach, it just skips over the loop as if the count was zero.
The only thing I can think of is that an update to Office (365) has broken something related to VSTO. But where do I even begin debugging this?
Okay, so I tried creating a new Word VSTO add-in, changing none of the default project properties, but adding a single ribbon with a single button and the following method:
private void button1_Click(object sender, RibbonControlEventArgs e)
{
try
{
var x = Globals.ThisAddIn.Application.ActiveDocument;
}
catch (Exception ex)
{
;
}
}
It throws exactly the same exception on getting the ActiveDocument property. I did however notice that there are two more exceptions thrown when loading the add-in, and they're also thrown when loading the original add-in (that used to work fine):
Exception thrown: 'System.Deployment.Application.DeploymentException' in System.Deployment.dll
Exception thrown: 'System.Security.Cryptography.CryptographicException' in Microsoft.VisualStudio.Tools.Applications.Hosting.dll
They don't prevent the add-in from loading and running, but maybe they're related to the problem anyway? I don't know if they were also thrown last year before the problem appeared.
I do however have a couple of Excel add-ins that still run fine with the same version of VSTO, Visual Studio and Office, and they don't throw the above two exceptions when loading. So the issue seems to be specific to Word.
And now I tried rolling back to Office 365 version 1810, the October release, which definitely worked before, so I think it's probably not a problem introduced by an Office update. It's something else. Probably.
Not that it really helps me much, but at least I've ruled that out. Probably.
The problem seems to be triggered by the Windows 10 October 2018 Update (or November). The affected customers had special Windows regional settings: Example: "English (Switzerland)".
Solution:
Change the Windows regional settings format to "English (UK)" or "English (US)"
The VBA Editor also no longer worked correctly for the affected customers (without installed add-ins). The error "Word has encountered a problem" (Visual Basic Error 5097) occurred directly during opening. The same error that occurs in C# for Application.ActiveDocument
Well, rolling back to the previous version of Windows 10 (1803 in my case, apparently) fixed the issue, and I can't reproduce it at the moment, so I'll mark this as solved for now.
While I still have no clue what exactly the deal was, I did at least learn in my research that clicking the "Check for updates" button in Windows 10 instantly makes you a beta tester for Microsoft. As in, they deliberately put you on the unstable update train, without any sort of notice, let alone a warning that you're about to install updates that they don't consider ready for release yet.
Anyway, I hope they got some good telemetry from my many, many hours of trying everything I could think of, so that maybe the issue is fixed by the time the update is forced on me. If not, I guess I'll be back to ask the same question again. At least I'll know where to start looking for the cause.
From my experience :
when i was closing the Active Document at that time i was refreshing Ribbon Menu according to the active document.
If the closing document was the Last document i wasn't able to read any property of
Microsoft.Office.Interop.Word.Document doc = Globals.ThisAddIn.Application.ActiveDocument;
and i was facing the same issue like you.
whenever i close any document i check
if(Globals.ThisAddIn.Application.Documents.Count = 1){
LastActiveDocument = true;
}
And when i refresh the Ribbion Menu i check
if(!LastActiveDocument){
// then only read any property of Active document
}
Microsoft has fixed the issue
Microsoft has released an Office update to fix this issue.
With Office Version 1902 (Build 11328.20158) the issue is fixed on my side.

OutOfMemory Exeption VSTO Add-in Office 2016 64bit

As the Title suggests I get an OutOfMemory Exeption in my VSTO Add-in in Excel 2016-64bit.
That happens when I update a Pivottable with the Table.Update() method which is provided by the VSTO Add-in by Microsoft.
My Machine has 16 GB RAM and the Process Memory in VS 2017 shows that only about 270 MB are used.
It works when I refresh the PivotCache wiht PivotCache().Refresh(); but that takes about 20 minutes which is
way too long.
AdditionalInformation would be that the Memory Exception occurs instantly when I hit my Update Button.
For a real memory exception I would expect the process Memory to rise over time till it is full and then throw an exception.
Any Ideas or suggestions would be nice. At this point I have no Idea where to look.
The issue is hard to reproduce in a minimal solution but apparently i am not the only one with that problem.
https://social.msdn.microsoft.com/Forums/office/en-US/18a6abc5-c390-41a9-8db7-206dbd86c509/getting-out-of-memory-exception?forum=exceldev
This person had the same problem in 2014 an the issue remained unresolved.
It seem like a rare bug in VSTO Addin.
I programmed a workaround:
Takes about 1 min so its fine since i need to update the Pivot Table once or twice a day.
try
{
//some other code
Table.Update();
//Some ohter Code
}
catch(OutOfMemoryExeption)
{
Table.Pivotcache().Refresh();
faildAny = true;
}

C# Excel 2007 RTD Server crashes on exit

I have written a c# RTD server based off of Kenny Ker's Multiple Topics in C#
The main difference between his design and mine is that my data comes from a WCF client. I use the same type of timer and every couple of seconds I call m_callback.UpdateNotify();. My RefreshData method calls a function in my WCF client with the topic values and uses the result as the value for excel. It all works excellent.
The problem comes when I close excel.
When I close Excel I get a message box that says "Microft Excel has stopped working"
My ServerTerminate() method clears all of my topics, calls close on my WCF client and exits without error.
I thought the problem might be a COM issue so I have tried adding
while ( Marshal.ReleaseComObject( m_callback ) > 0 ) ;
m_callback = null;
The pop up still showed up so I tried adding
GC.Collect();
GC.WaitForPendingFinalizers(); //SEHException thrown from this
GC.Collect();
GC.WaitForPendingFinalizers();
Adding these lines does throw an exception. if I ignore the exception excel closes without any problems, but if I install my RTD server on a computer with excel 2010, then the pop up box is still there.
I have Excel 2007 (12.0.6665.5003) SP3 MSO (12.0.6662.5000)
I am developing my c# RTD Server using Visual Studio 2008 and my project has a reference to Microsoft.Office.Interop.Excel version 12.0.0.0
The question was fairly vague, but that's because I really had no idea where to start. Every thing seemed to be working correctly.
After playing around with the code I noticed that I had an object that implemented IDisposable that I called Dispose on when I was done with it. The object also had a finalizer that called Dispose. I changed it to be more like this with a protected Dispose(bool).
I also removed the Excel assembly per Kenny Ker again (however just copying his code didn't work. I actually copied the interfaces straight from the excel interop assembly).
After doing that I was able to get rid of the lines I added (for marshalling the garbage collecting) above and excel now closes without a problem.

Visio Interop Questions

I have written a console application which uses UDC (universal document convertor) to convert visio diagrams to an image (more specifically a jpeg).
Everything is working fine (for visio files in 2007 and 2010), and I am using Microsoft.Office.Interop.Visio version 14.0.0.0. I thought I would do a test by creating a visio diagram in Visio 2003 and testing the application. It works fine however, I get the following popup "The Microsoft Visio building plan shapes in this drawing must be updated to function in the current version of Visio". If I click "Yes" then the program works fine. This code will eventually be running as a service and I was wondering if there is anyway to supress these warnings? Or tell it to do any conversion automatically?
We seem to have found the answer (trying nearly every property on the Visio.Application class!):
vApp = new Microsoft.Office.Interop.Visio.Application();
vApp.Visible = false;
vApp.Settings.ShowFileOpenWarnings = false;
vApp.EventsEnabled = 0;
It seems the EventsEnabled = 0 did the trick!
Hope this may be useful to someone eventually.. I spent about 4 hours on it :)
You can set vApp.AlertResponse = vbYes, which suppresses the dialog and chooses Yes for you.

Categories