Weird behaviour in Excel on Parallels on Mac

165 views
Skip to first unread message

Alan Stubbs

unread,
Nov 4, 2021, 6:56:56 PM11/4/21
to Excel-DNA
Hi Govert,

Hope you are well.

I've got an odd client bug with an addin that has been working perfectly well for ages - the client runs Excel via a Windows 10 vm on Parallels on his mac.  I believe other users have run this way without issue too (I'm setting up to test it myself in Parallels).

The UDF in question is defined with up to 16 optional arguments.

The test case formula specifies 9 args but on this client vm, the UDF only gets the first 5 args correctly (logging in the UDF body after a call to XlCall.Excel(XlCall.xlfCaller) and to XlCall.Excel(XlCall.xlSheetNm, excref), but before we start processing the args).  The next 7 args are ExcelMissing and the last 4 are the empty string.

I don't see anything odd about the arg values (they are default values we've been using for ages).  Both arg 5 and 6 are double-quoted strings - as are all the other args in the formula.  All args are comma separated - and none contain commas.

This same user had a bug a month ago whereby missing args were turning up in the UDF logic as actual nulls rather than ExcelMissing or ExcelEmpty - something that had never happened before.  I've seen a post on this group stating that they should always come through as ExcelMissing or ExcelEmpty - and I've never had to handle null before.

Have you seen anything like this before?

Many thanks,

Alan

Alan Stubbs

unread,
Nov 12, 2021, 3:42:30 PM11/12/21
to Excel-DNA
Hi Govert,

It turns out that it is an m1-based Mac that is hosting parallels so I'm guessing that the issue is to do with it being ARM-based Excel.

Is this use case supported by Excel-DNA - do I just need to update my version of Excel-DNA?  Or is it something I would have to change about the build of my addin code?

I'm trying to find info on this now but any pointers much appreciated!

Thanks,

Alan

Govert van Drimmelen

unread,
Nov 12, 2021, 3:54:43 PM11/12/21
to exce...@googlegroups.com

Hi Alan,

 

As I understand it, the Excel will run in some x64-compatible emulation mode on the Windows ARM.

That you’re having subtle problems with parameter passing on that architecture makes it sound like a bug in either the emulation or in the .NET JIT in that setting.

For example, the JIT might decide to pass some parameters in registers, and the rest on the stack.

But somehow this is not being emulated or represented correctly.

 

If one has to dig in further, I’d say you need to know a bit more about the emulation mode in which the Excel process is running.

One step might involve trying to reproduce this on Windows ARM running on non-Mac hardware.

Another might to try to make a non-Excel reproduction of the issue somehow, with a .NET app that is (somehow, possible with a native host) configured to run as an x64-emulated app.

 

It sounds like a bit of a project unless you stumble on it as a known issue somewhere.

 

-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 view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/19cf255f-21e1-4dae-84a2-8322c660e82cn%40googlegroups.com.

Alan Stubbs

unread,
Nov 12, 2021, 5:19:03 PM11/12/21
to Excel-DNA
Thanks Govert!  I'll see what I find - will update here if anything useful to report.

Alan

Alan Stubbs

unread,
Dec 9, 2021, 5:27:32 PM12/9/21
to Excel-DNA
Just in case anyone else runs into similar issues: 
 - we didn't find any resolution
 - Windows 11 isn't officially supported (by Microsoft) on Apple Silicon - running on it breaks the Windows 11 EULA, I understand
 - Parallels have implemented their own version to get Windows 11 (mostly) working on the M1 Mac - and it has some known issues (of which this is not one!)

gab...@velixo.com

unread,
Dec 10, 2021, 11:33:14 AM12/10/21
to Excel-DNA
Just wanted to let you know that I have noticed the same thing as well with our product, and I don't think the issue is related to Parallels, but rather the ARM64 version of Office and how they deal with x64 add-ons. One of my team members swear this was working correctly a few months ago, so it might be a bug that Microsoft introduced in Office or the x64 emulation layer.

I spent part of the day yesterday trying to see if I could create an ARM64EC version of ExcelDna. I got it to compile, but it crashes on load. I built it from my x64 machine and copied the binary to the ARM64 machine, so no ability to debug this easily (and not a lot of time to dedicate to it, either).

There's a growing number of ARM-based laptops and I expect we will start seeing more in the wild, and I want to be proactive about supporting it. If someone is willing to collaborate with me on this port I am happy to share what I've done so far.

Govert van Drimmelen

unread,
Dec 10, 2021, 4:05:45 PM12/10/21
to Excel-DNA
Hi Gabriel (and Alan),

I do not understand what you mean by an 'ARM64EC version of ExcelDna'.
My understanding is that there is no ARM64 version of Excel that supports .xll add-ins, and that the code running on Windows-on-ARM and Windows-on-M1 is enulated x64 code.
I.e. the Excel binaries are the same and the add-ins are x64 add-ins.
Native Excel for Mac does not support .xll add-ins, but has VBA.
Have I missed something?

Otherwise I'm also happy to help with this issue, which I understand as getting x64 Excel-DNA add-ins working on the Excel which runs emulated under Windows-on-ARM/M1.
However, I don't have access to an ARM / M1 machine at the moment.

* Is there a hosted / VM version of normal Windows ARM or MAC M1 that we can try to reproduce this on?

* We can make sure we have a minimal reproduction as a start. 
Is it as easy as this function in an Excel-DNA add-in:
    
    public static object Test(object arg1, object arg2, object arg3, object arg4, object arg5, object arg6) => arg6;

and calling as 

    =Test(1,2,3,4,5,6)

* We can make a pure C add-in with the same function, and check that (it eliminates the .NET runtime as a source of the problem).

* We can make a C program that calls such an exported .NET function without Excel involved.

-Govert

Govert van Drimmelen

unread,
Dec 10, 2021, 4:11:39 PM12/10/21
to exce...@googlegroups.com

OK I see there is a gap in my understanding, looking at this 64-Bit Office for Windows on ARM

 

I don’t know whether the ARM-optimized version of Office supports .xll add-ins, but they say

“maintain compatibility with existing 64-bit add-ins using the new x64 emulation capability provided by Windows.”

 

This might be restricted to COM add-ins, or might include the C API / .xll add-ins too.

 

Any other relevant links would be great.

 

-Govert

gab...@velixo.com

unread,
Dec 10, 2021, 4:38:35 PM12/10/21
to Excel-DNA
Hi Govert,

I have a virtual machine running Windows 11 on ARM with the ARM64 version of Excel and I can give you access through Chrome Remote Desktop.

ARM64EC is new new ABI (application binary interface) that lets you mix ARM and x64 code in the same process. That’s how Office on ARM manages to load x64 add-ins  (despite performance and reliability issues described in this thread).

Would you happen to have a simple C add-in that I could use as a starting point? I will setup everything needed in the machine to try to replicate and troubleshoot this.

I am not sure at this point if Excel is able to load an XLL file that targets ARM64EC. I can confirm it will not load one that has been compiled to target ARM64, but it does attempt to load the one I compiled for ARM64EC before crashing. I don’t have a debugger on the machine and was about to add simple tracing code to see if the initialisation logic gets called or if Excel crashes before that. I commented out the asm thunking  because it does not compile but I was planning on verifying whether I can load the add in first before looking at function calls.
Message has been deleted

Govert van Drimmelen

unread,
Dec 23, 2021, 5:48:52 AM12/23/21
to Excel-DNA
Just an update of the current status on this issue.

I'm able to reliable produce an Excel Access Violation crash under Excel for ARM using only the Excel SDK sample add-in GENERIC.XLL.
The problem only occurs with UDFs that have many parameters.
The same binary add-in works fine on x64 processors, and UDFs with few parameters work fine.
This means we can reproduce the problem without .NET or Excel-DNA involved, and it seems to relate to how Excel calls the UDF functions under the ARM64EC to x64 calls.

I have reported the problem to the Office support at Microsoft and I've been able to show them the problem and describe how to reproduce it.
They seem to be unsure exactly where to escalate this to.

For the last week the only updates to the support ticket has been:

"I would like to inform you that we are still in discussion with the internal team and we will get back to you shortly.
Thank you for choosing Microsoft and have a great day ahead."

I'll wait a few weeks into the new year before following up further.

-Govert


Kevin Fox

unread,
Dec 28, 2021, 1:54:07 PM12/28/21
to Excel-DNA
Govert, 

Thanks for the update.

One of our clients found a workaround. I wasn't able to test it but for anyone else who runs into this issue it may prove useful. 

This is what our client did. 
  1. Install the 32-bit version of Office even if you have a 64-bit capable M1 chip if you run Windows 11 on Parallels version 17.
  2. Install the 32-bit version of the Excel plugin. 

If someone has an M1 Macbook and wants to confirm that works, could be an acceptable workaround for some people. 

FastExcel

unread,
Jan 9, 2022, 1:24:34 PMJan 9
to Excel-DNA
I have a client with a somewhat similar M1 problem: its not XLDNA but a C++ XLL built with PlanaTech
it was working fine on Parallels with an Intel Mac but when the client upgraded to M1 he gets an error message complaining that an optional parameter has not been initialized - a Long was expected
64 Bit office and parallels 17
The failure is on the 5 th parameter of 6. The parameter type string is "UC%QQQQQ$"

Govert van Drimmelen

unread,
Jan 9, 2022, 1:41:51 PMJan 9
to Excel-DNA
HI Charles,

Indeed, it does not seem related to Excel-DNA or .NET, but a problem with the ARM64 version of Excel.
I can consistently reproduce an Excel crash with the FuncSum function from the GENERIC.XLL add-in from the Excel SDK.

I have reported to the Office support and they claim to "have shared the details with our internal team and waiting for the update from them."
If you have a more direct channel to the Excel developers, I'm sure that would help.

-Govert

Alan Stubbs

unread,
Jan 11, 2022, 7:43:30 AMJan 11
to exce...@googlegroups.com
Hi Kevin,

Just referencing your workaround suggested above - using 32-bit office, etc - I am told that this does work, at least as far as the initial issues we were having.  Thanks for the suggestion!

Alan

You received this message because you are subscribed to a topic in the Google Groups "Excel-DNA" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/exceldna/jCee3l0lzjM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/7abf9567-c30e-4066-82d7-97c4b070ada0n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages