Re: [ExcelDna] Excel Addin BEX / APPCRASH in Windows Server 2008 R2 Terminal Services, Office 2010, Citrix XenApp 6.5 environment
692 views
Skip to first unread message
Naju Mancheril
Nov 1, 2012, 7:43:05 AM11/1/12
to exce...@googlegroups.com
I believe 2008 also adds UAC.
The registry writing sounds very suspicious. Is it possible to disable this feature and test the modified version? Or maybe the layout can be stored in the database?
Naju Mancheril
Nov 1, 2012, 7:50:24 AM11/1/12
to exce...@googlegroups.com
Also, rather than removing functionality, you may also want to try adding some aggressive debug functions. Maybe one menu item that writes to the registry N times. And another that accesses the database N times.
Also, the most nondeterministic parts of your system sound like database access by multiple users and network access. Maybe unplug the network while this runs and see if it crashes?
Govert van Drimmelen
Nov 2, 2012, 12:42:13 AM11/2/12
to Excel-DNA
Hi Tom,
You say: "After Excel has crashed, or even while Excel is running and
the addin has been loaded, other user
mode processes begin to crash, Explorer, MMC, etc, from similar
exceptions."
If true, this is pretty serious, and can not be due to any wrong in
Excel, your Excel-DNA add-in or .NET itself, but is indeed a much more
serious symptom of instability on that (virtual) machine. Windows will
generally isolate processes very well, so general errors like this
indicate something very wrong.
As a test I would suggest running the add-in a bit in a non-virtual
host on the same O/S and network environment (i.e. Terminal Services
without XenApp).
As for the list of 'dangerous' features - the ones I would be worried
about in order of concern:
1. running the add-in binaries over the network - you say "it is run
from a FullTrust local intranet share over a distributed file system"
- this would be my first worry. Just copy the binaries to the local
machine (not necessarily the SQLite database).
2. The WPF form over Terminal Services - this would make me a bit
nervous - there used to be issues with WPF being hosted in Office
apps, and WPF via RDP was also a bit funny. Try to isolate this part.
3. Run it under .NET 4 (you might need to add some stuff to the
excel.exe.config file to allow the SQLite driver to load, or change
the System.Data.SQLite version you use. The rest need not even be
recompiled, just add the right RuntimeVersion tag in the .dna file).
On Nov 1, 2:56 pm, Tom Keirl <tom.ke...@gmail.com> wrote:
> Thanks for your suggestions. We're currently trying a fully stripped down
> version of the Addin with most of those features removed. Any problems with
> the SQLite connection should be caught, in theory, in managed code courtesy
> of a global exception handler registered when the addin loads with
>
> Integration.RegisterUnhandledExceptionHandler
>
> The referenced exception handler returns a string pertaining to the
> exception message after various tests are done to evaluate whether it
> should be logged, output into LogDisplay, etc.
>
> Will update soon.
>
> Thanks
>
> Tom
You say: "After Excel has crashed, or even while Excel is running and
the addin has been loaded, other user
mode processes begin to crash, Explorer, MMC, etc, from similar
exceptions."
If true, this is pretty serious, and can not be due to any wrong in
Excel, your Excel-DNA add-in or .NET itself, but is indeed a much more
serious symptom of instability on that (virtual) machine. Windows will
generally isolate processes very well, so general errors like this
indicate something very wrong.
As a test I would suggest running the add-in a bit in a non-virtual
host on the same O/S and network environment (i.e. Terminal Services
without XenApp).
As for the list of 'dangerous' features - the ones I would be worried
about in order of concern:
1. running the add-in binaries over the network - you say "it is run
from a FullTrust local intranet share over a distributed file system"
- this would be my first worry. Just copy the binaries to the local
machine (not necessarily the SQLite database).
2. The WPF form over Terminal Services - this would make me a bit
nervous - there used to be issues with WPF being hosted in Office
apps, and WPF via RDP was also a bit funny. Try to isolate this part.
3. Run it under .NET 4 (you might need to add some stuff to the
excel.exe.config file to allow the SQLite driver to load, or change
the System.Data.SQLite version you use. The rest need not even be
recompiled, just add the right RuntimeVersion tag in the .dna file).
On Nov 1, 2:56 pm, Tom Keirl <tom.ke...@gmail.com> wrote:
> Thanks for your suggestions. We're currently trying a fully stripped down
> version of the Addin with most of those features removed. Any problems with
> the SQLite connection should be caught, in theory, in managed code courtesy
> of a global exception handler registered when the addin loads with
>
> Integration.RegisterUnhandledExceptionHandler
>
> The referenced exception handler returns a string pertaining to the
> exception message after various tests are done to evaluate whether it
> should be logged, output into LogDisplay, etc.
>
> Will update soon.
>
> Thanks
>
> Tom
Reply all
Reply to author
Forward
0 new messages