Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)

[AppleG]

Hello,

I got this COMexception (Exception from HRESULT: 0x8001010A
(RPC_E_SERVERCALL_RETRYLATER) ) when trying to update a spreadsheet
having several calls on the same UDF.

Could someone please provide some suggestion on how to handle this?

Thank you very much and any information is highly appreciated.

Thanks,

Vickie

[Govert van Drimmelen]

Hi Vickie,

You'll sometimes see RPC_E_SERVERCALL_RETRYLATER and VBA_E_IGNORE if
you're automating Excel through the COM interface, or implementing an
RTD server and calling UpdateNotify from a different thread. The error
is raised when Excel is not ready to handle your call - e.g. if the
user is busy editing a cell or pressing the mouse button. You should
expect the exception and deal with is gracefully - maybe sleep for a
second and then try again.

At the bottom of my ArrayResizer attempt (http://excel-dna.net/
2011/01/30/resizing-excel-udf-result-arrays/) you'll see some example
of trying to deal with this error. It just backs of for a bit and then
retries, forever.

There is quite a lot of detailed information on the web about this.
Two useful threads are:
http://social.msdn.microsoft.com/Forums/en/vsto/thread/1dab0874-bba5-481a-9986-a11a66efa0a0
http://social.msdn.microsoft.com/forums/en-US/vsto/thread/11c6ca3f-6bd9-47d9-83e4-9c8adc6292c2

-Govert

[AppleG]

Hi Govert,

Thank you very much for your reply. After reading through your
ArrayResizer example, I was able to solve the problem. But, just for
curiosity, what does this "Marshal.ReleaseComObject" business do? Is
that only for multi-threading situation or is that necessary for all
COM objects. What if the COM Object is not released?

I also have another question regarding your reasoning behind this
error/exception. You mentioned that when Excel is busy and if there is
another thread trying to edit it, we may get those error/exception.
But I tested some simple UDFs (also use multi-threading), which are
all called from the same s/s, but didn't have any problem and all UDFs
give the correct results. Do you know why it has different behavior
than the previous case?

Thank you again for all the information!

Best,

Vickie

On Feb 27, 3:03 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Vickie,
>
> You'll sometimes see RPC_E_SERVERCALL_RETRYLATER and VBA_E_IGNORE if
> you're automating Excel through the COM interface, or implementing an
> RTD server and calling UpdateNotify from a different thread. The error
> is raised when Excel is not ready to handle your call - e.g. if the
> user is busy editing a cell or pressing the mouse button. You should
> expect the exception and deal with is gracefully - maybe sleep for a
> second and then try again.
>
> At the bottom of my ArrayResizer attempt (http://excel-dna.net/
> 2011/01/30/resizing-excel-udf-result-arrays/) you'll see some example
> of trying to deal with this error. It just backs of for a bit and then
> retries, forever.
>
> There is quite a lot of detailed information on the web about this.

> Two useful threads are:http://social.msdn.microsoft.com/Forums/en/vsto/thread/1dab0874-bba5-...http://social.msdn.microsoft.com/forums/en-US/vsto/thread/11c6ca3f-6b...

[Govert van Drimmelen]

Hi Vickie,

Marshal.ReleaseComObject() forces the .NET COM object wrapper to
release the referenced COM object (in this case Excel's Application
object). If there are outstanding references to the Excel objects, the
Excel process will not terminate when you close Excel. You can test
this by removing the ReleaseComObject() call, calling the resizer
function, closing Excel and then checking in the Task Manager - Excel
will be 'closed' but the process will stick around.

So in the ArrayResizer example where the Application object is
accessed from a different thread, we either need to release the object
explicitly, or force a garbage collection. If we don't, and we close
Excel, the garbage collector will never run and clean up the COM
reference, since no further .NET code is running which could trigger
the GC.
I don't have a good idea of when this is required and when you don't
need it, but in this case we need it and it certainly is safe and
correct - we are done with the COM wrapper after the "Run" call
completes.

Multi-threaded UDF calculation is a totally different thing to making
your own threads behind Excel's back, and then trying to access Excel
from those. UDF calculations returning values to Excel are handled by
Excel internally. The multi-threaded recalculation runs on threads
that Excel controls and only some of the C API calls are supported
from the context of the thread-safe functions. I doubt accessing the
COM object model from this function context is safe.
The COM errors we are dealing with here only arise when Excel is
called through the COM automation interface.

Regards,
Govert

> > Two useful threads are:http://social.msdn.microsoft.com/Forums/en/vsto/thread/1dab0874-bba5-......

[AppleG]

Hi Govert,

Thank you very much all the detail explanation! Yes, I tried with by
commenting out the ReleaseComObject function and did see excel is
still running in the tasking manager. Thank you again for all the
help!

Best,

Vickie

[Annu Dudeja]

Hello,

Please tell how can solve this problem?

Thanks & Regards

Annu 

[Govert van Drimmelen]

Hi Annu,

 

The guidelines are:

·         Only talk to the COM object model from the main Excel thread, in a macro context, event handler or ribbon callback.

·         Never, ever, talk to the COM object model from another thread.

·         If you want to initiation COM object model work from another thread, use a call to ExcelAsyncUtil.QueueAsMacro(…) to schedule the code to run in a macro context.

 

-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 http://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.