Unexpected error trying to run SyncMacro for queued macro execution. : TargetInvocationException

[fandrei]

Some users are having this error without any visible reason. Any ideas why it can be happening?

[juflo]

Since last Office update (July 13 2021), Office version 2102 is deployed in "Semi-Annual Enterprise" channel. https://docs.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date We encountered the same issue, and rollback to version 2008 until figuring out a solution for newer Office builds.

[govert]

@fandrei Are you able to check the exact Excel version of the problem users?

@juflo Have you reported the issue to Microsoft? (At least with the Send Feedback button in Excel)

This was a similar issue caused by an update that I think was rolled back again: https://groups.google.com/g/exceldna/c/HKcW2E7-TbA/m/roWQQQ0yAQAJ

[juflo]

@govert Thanks for your feedback. After searching again for a solution, it seems that invalid range name references are the cause for this, as stated here : https://stackoverflow.com/a/11191514/12717104 After removing invalid references in my problematic workbook, I have not encountered the error anymore in new Excel version (2102 and 2105 tested)

[fandrei]

@govert it's 16.0.14326.20404 In this case it does load, just fails occasionally. PS Some info about the underlying exception that I collected:

Runtime [Error] Unexpected error trying to run SyncMacro for queued macro execution. : TargetInvocationException - System.Reflection.TargetInvocationException: The target of a call has thrown an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This often indicates that other memory is damaged. 

 --- End of internal exception stack path --- 

 at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters) 

 at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams) 

 at System. Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture) 

 at ExcelDna.Integration.RunMacroSynchronization.COMRunMacro(String macroName) 

 at ExcelDna.Integration.RunMacroSynchronization .ProcessRunSyncMacroMessage()

[juflo]

Hi Despite any workaround I tried, I still have the issue. I would be glad to have some feedback about possible solution. Thanks.

[govert]

@juflo Is it still the case that invalid range names seem to cause this, and that the problem is related to a specific workbook?

[juflo]

It happens way more often with invalid range names, but it occurs also without it. Problem may happen with any workbook.

[govert]

Maybe you can make a small add-in and a workbook which triggers the problem often, then I can try to reproduce it.

[juflo]

Sure, I will try to prepare that. Thanks.

[juflo]

Hi.

Back with a reproductible code sample :

public class AddIn:IExcelAddIn
    {
        public void AutoOpen()
        {
            Observable.Interval(TimeSpan.FromMilliseconds(10)).Subscribe(l => ExcelAsyncUtil.QueueAsMacro(() => Debug.WriteLine("Queue {0}", l)));
        }

        public void AutoClose()
        {
        }
    }

You will need to add Reactive library as dependency. After a few seconds, the following message appears :

Problem only occurs when some "big" worksheet (mine is 3 MB) happens. The test is done using "excel /s", to prevent any addin conflict.

Edit : even small workbook creates error. Find attached sample if needed. ExcelDNA-AVE.xlsx

[govert]

@juflo What version of Excel-DNA are you using? Can you also try with the current 1.6.0-preview1 ? What is the exact sequence to cause the error? Do I open the workbook first and the load the add-in, or does it happen if the add-in is already loaded and you then open the workbook?

[juflo]

I was using 1.5.1. I will try with 1.6.0-p1 Sequence is first open the workbook, then load the addin. I didn't try the reverse order, I will check. You can use SysInternals DebugView to check Debug call.

[govert]

OK I doubt 1.5.1 -> 1.6.0-preview1 would make a difference. What version of Excel? Doesn't seem to give any problems for me. I can see the debug trace running.

[govert]

[juflo]

Any version from 2102. Test was done on 64 bits. You may have to wait a few minutes to have an error. I can provide the exception stack if needed.

[govert]

@juflo I've run for a few days continuously, opened and closed various files including the one you sent. Do you see the problem on multiple machines? Maybe there has to be more calculation going on, or calculation triggered along the way, to interfere with the COM call.

[juflo]

@govert I try using ExcelDna 1.6-p2, same problem. The problem happens on multiple machines, but only when using Office 365. I did not manage to reproduce the problem using Office 2019. And really, I do nothing, just wait for 1-2 minutes before having the exception.

That's more or less the same problem than the one described here https://www.ibm.com/support/pages/intermittent-attempted-read-or-write-protected-memory-systemaccessviolationexception-invokedispmethod-error-using-data-entry-or-running-report-caused-click-run-ms-office

[govert]

I am also running Office 365 and can't reproduce it. It might help to try to dump all the modules loaded into that process. Maybe you can do a ProcessMonitor run to see whether there is some interesting file or registry activity around that time. Maybe you can make a clean VM and see if you can recreate the problem there.

The IBM link is very weird. They suggest this intermittent problem is caused by the Click-to-Run installation (which I think my installation is too, though I'm not sure how to check). In this case there is a virtualization of the file system and registry (so it's running in a kind of mini-VM sandbox). I guess there can be problems with this.

Is the problem fatal, or just irritating? You can set up a logging configuration which won't pop up the dialog. But of course in that case your intended macro really did not run. I can't remember whether Excel-DNA will retry after that error - it's worth checking.

[juflo]

Excel became totally unusable afterward (no response, flashing ui, crash, ...) I have reproduced it in "clean" VM too. You can check click to run in "account" screen

I will check which modules are loaded. Thanks.

[govert]

[govert]

What are you using QueueAsMacro for? Maybe we can un-ask the question.

[juflo]

Unfortunately, I need to do some xlc C function calls in "macro context". Could you try the provided xll on your side ? I remove the Rx dependency and display message using Excel status bar. ExcelDnasample2.zip

[juflo]

Hi. I have complementary information. The problem seems only to happen when Excel is not using English language. It seems that the problem is in ExcelSynchronizationContext at line 401 : object result = appType.InvokeMember("Run", BindingFlags.InvokeMethod, null, xlApp, new object[] { macroName, 0.0 }, _enUsCulture); If the culture does not match the Excel one, the call may throw the AcessViolationException. When changing culture to matching Excel using ExcelApp.LanguageSettings.LanguageID(Office.MsoAppLanguageID.msoLanguageIDUI), or removing the culture totally, no Exception is thrown anymore. The workaround was found here : https://www.add-in-express.com/creating-addins-blog/2009/02/13/old-format-invalid-type-library/ Would it be possible to try on your side ? Thanks.

[govert]

I'm trying on an English Office on English Windows, so that might explain why I don't reproduce the error, and why it is not often reported. Anyway your test ran fine for several hours:

The article you point is interesting, but I wonder how close your situation is to this: " If a client computer has the English version of Excel, and the locale for the current user is configured for another language (e.g. German or French), Excel may fire the “Old format or invalid type library” exception with error code 0x80028018 (-2147647512). "

1. Are you just on a non-Enlish locale, or in this mixed situation.
2. Are you seeing the error they describe here, or crashing the process with an Access Violation?
3. Do I understand correctly that the QueueAsMacro / Application.Run call works many times, then sometimes after a while it suddenly fails?
4. Are you suggesting that all the COM calls can be made with the enUS Culture replaced by msoLanguageIDUI?
5. Do you know anything more about what the locale affects? I remember some discussion about this in the days of the COM add-in shim that the VSTO guys made, but can't find the relevant article anymore.

[juflo]

Hi Govert.

1. I have checked both.
2. The process became buggy : freeze or crash after few click, can not close Excel window anymore.
3. Yes, that's what is happenning.
4. I'm not sure at all of what must be done in that case. I remember that in .Net 2.0, culture enUS must be passed when calling InvokeMember, but it was not needed anymore using .Net 4.0.
5. Not that I remember.

By saving the sheet created with Excel 2008 with Excel 2102, I have not been able to reproduce the problem anymore. That's really strange. I will update the issue if I have the exception again.

Thanks.