Recently Appeared Exception

[Alan Stubbs]

Hi Govert,

Hope you are well.

I've started seeing an Exception recently at startup in an add-in that was previously working fine.  Looking at the log output, I see only:

...
ExcelDna.Integration Verbose: 4 : ExcelComAddIn.OnStartupComplete
ExcelDna.Integration Error: 6 : Unhandled exception in async delegate call. : NullReferenceException - Object reference not set to an instance of an object.
ExcelDna.Integration Error: 6 : Unhandled exception in async delegate call. : NullReferenceException - Object reference not set to an instance of an object.
...

Does the 6 mean that it is from Intellisense?

I don't believe anything has changed in my code recently so I'm wondering if there are any known issues with recent versions of Office 365?  The users have 64-bit Excel.

I've tried updating to the latest stable versions of Integration and Intellisense, which made no difference.

Thanks,

Alan

[Govert van Drimmelen]

Hi Alan,

 

For the ExcelDna.Integration trace source, the EventId 6 mean “Runtime”: https://github.com/Excel-DNA/ExcelDna/blob/2aa1bd9afaf76084c1d59e2330584edddb888eb1/Source/ExcelDna.Integration/Logging.cs#L64

 

The error you see is from here:

https://github.com/Excel-DNA/ExcelDna/blob/2aa1bd9afaf76084c1d59e2330584edddb888eb1/Source/ExcelDna.Integration/ExcelSynchronizationContext.cs#L312

 

This happens when an async macro (e.g. from ExcelAsyncUtil.QueueAsMacro) has run and thrown an unhandled exception.

So I think the NullReferenceException is from add-in code and not Excel-DNA code, but it’s hard to tell what changes might be causing this.

 

I also see that I made some attempts last year to improve robustness of running async macros from AutoOpen, including in the case of a “Protected View” sheet:

https://github.com/Excel-DNA/ExcelDna/commits/master/Source/ExcelDna.Integration/ExcelSynchronizationContext.cs

 

With version 0.35, unhandled exceptions in the async macros will also call the registered ExcelIntegration.UnhandledExceptionHandler.

That would give you another opportunity to catch the exception yourself, and e.g. print out the StackTrace to see where exactly the NullReferenceException arises.

 

I hope that gives some clues.

 

Regards,

Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To post to this group, send email to exce...@googlegroups.com.
Visit this group at https://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.

[Alan Stubbs]

Hi Govert,

Thanks for the info, I was looking at an old version of the ExcelDna repo for the IntegrationTraceEventId.

I'm seeing an Exception when I get the Excel Application in AutoOpen - which I've been doing for ages:

Exception of type 'ExcelDna.Integration.XlCallException' was thrown.
   at ExcelDna.Integration.XlCall.Excel(Int32 xlFunction, Object[] parameters)

   at ExcelDna.Integration.ExcelDnaUtil.GetApplication()

   at ExcelDna.Integration.ExcelDnaUtil.get_Application()

   at ...AutoOpen()

Code at top of AutoOpen hasn't changed in a long time and it still fails when I run this as the first line:

try

{

    ExcelApplication = ((Microsoft.Office.Interop.Excel.Application) ExcelDnaUtil.Application);

...

Same from installed version and when running the xll directly as admin/non-admin in admin/non-admin location.

Bug is when running on a Windows 10 laptop with Excel 2016

Somewhat inevitably, it works on my machine... Windows 10 laptop with Office 365.  The only other difference I can see is that I am running .Net 4.7.2 with a different code:

"On Windows 10 April 2018 Update only: 461808" (my laptop working)   "On all other OS versions, including Windows 10 October 2018 Update: 461814

"

(other laptop not working)

I'm running Office 365 MSO 16.0.1126.20192 64-bit.  Other laptop is running Excel 2016 MSO 16.0.4738.1000 64-bit

Will keep digging to see what I can find.

Thanks,

Alan

[Govert van Drimmelen]

I suggest you test with the pre-release 0.35.

That addressed some scenarios where the Application couldn't be found.

Also consider whether Excel might be opening in Protected mode for some reason.

Otherwise we'll have to set up some debugging on a problem machine.

-Govert

--

[Alan Stubbs]

It's not obviously running in Protected mode but I will check that explicitly this evening.

It may have worked for someone else testing this morning with Minimal Trust settings and running the xll directly.  It also happens with a much older version of the add-in so it looks like it is something to do with the environment.  Going to install VS and try to replicate the issue in debug mode.

What else would you suggest for debugging?

Thanks,

Alan

[Alan Stubbs]

Debugging in VS, I observe that with a breakpoint on this line, it works fine.:

ExcelApplication = ((Microsoft.Office.Interop.Excel.Application) ExcelDnaUtil.Application);

If I take the breakpoint away, it then fails at that line with:

Exception of type 'ExcelDna.Integration.XlCallException' was thrown.
   at ExcelDna.Integration.XlCall.Excel(Int32 xlFunction, Object[] parameters)

  at ExcelDna.Integration.ExcelDnaUtil.GetApplication()

  at ExcelDna.Integration.ExcelDnaUtil.get_Application()

  at ...AutoOpen()

I presume the delay which the debugger introduces is what makes the Application available/ready - and for some reason, it still works fine on my machine without any delays.

If I put the contents of AutoOpen inside a QueueAsMacro, it appears to be fine - is this a valid solution?

Thanks,

Alan 

[Alan Stubbs]

I spoke to soon, there were issues with running AutoOpen itself on this machine - even when it had none of my code in it.

Debugging, it turned out to be failing at the xlcWorkbookInsert: https://github.com/Excel-DNA/ExcelDna/blob/master/Source/ExcelDna.Integration/Excel.cs#L297

Does this give you any clue as to the actual cause?

As a temporary fix, I updated the catch block to contain:

try

{

// this is to do what would have happened if XlCall.Excel(XlCall.xlcWorkbookInsert, 6); hadn't thrown an exception at L297

application = GetApplicationFromWindows(allowProtected, out isProtected);

XlCall.Excel(XlCall.xlcFileClose, false);

}

catch

{

// Not expecting this ever - but be consistent about Try vs. exceptions

application = null;

isProtected = false;

}

This appears to work fine.  Does it look like an okay/safe update to you?

I'd still like to understand what is different about this machine - in case it causes other issues!

I did notice that, originally, after the XlCall exceptions, etc, Excel was at the launch page (New workbook, templates, etc) on the troublesome machine - while on my laptop it would open to a grey worksheet, where Ctrl-N would make it add the cells to the grey area.

I can create a PR for the changes above if you think they are appropriate.

Thanks,

Alan