I start Excel from within my C# WinForms application using Process.Start(...) (this has a reason). I want to start it in background, without distracting the user, so I try to start it minimized or hidden. In both cases, I experience a very weird behavior:
After some seconds, Excel restores the window (even makes it visible if it's hidden) and then crashes saying: "Microsoft Office Excel has encountered a problem and needs to close. (Win XP crash message.)"
The same thing happens if I start Excel manually by double-clicking its Shortcut Icon on the Desktop and then just switch to another application window immediately, such that the Excel window loses focus during startup.
The problem appears only if any of the XLA add-in contains a UserForm. If I remove the UserForm, the problem disappears. If I remove the add-in, the problem disappears.
Any help is appreciated, as long as it is
An explanation of why this happens
Something I can change in the add-in
A way how to work around this bug (without using COM)
Not a suggestion to use COM. (See here to understand why I don't.)
Not an advice to update Excel (I can't)
Steps to reproduce:
Start Excel 2007 with an empty workbook.
Save As...
File Type: Excel 2003 Add-in (*.xla)
Location: %APPDATA%\Microsoft\Excel\XLSTART\foobar.xla
Alt + F11 (open VBA editor)
Add a UserForm to the project.
Save and Quit Excel
Start Excel and then immediately click on the Firefox or whatever tab in the taskbar to activate any window other than Excel.
Wait and watch Excel start, until it crashes.
After restarting Excel it says:
Excel experienced a serious problem with the 'foobar' add-in. If you have seen this message multiple times, you should disable this add-in and check to see if an update is available. Do you want to disable this add-in?
Details/Findings:
Excel version: 12.0.6535.5002, SP2 MSO 12.0.6425.1000
0xA3 reported in his comment he could reproduce it on 32 bit machine with Excel 12.0.6535.5002, SP2 MSO 12.0.6535.5002
I've tried with a 2007 add-in (XLAM). The same problem, except that it even crashes if it doesn't contain any UserForms.
0xA3 reported that on his 64 bit machine it worked, however Excel still pops up unexpectedly (but doesn't crash). The same holds for 2 machines of my testers so far.
This is the code I wanted to use in C# (note that the problem can be reproduced completely independent of any C# app, see above).
Process.Start(new ProcessStartInfo("excel.exe")
{ WindowStyle = ProcessWindowStyle.Minimized });
Related
I'm at the point of giving up.
I need to view pdfs in my Winforms application, so I've tried using Adobe's ActiveX control, and the vanilla WebBrowser control. The pdfs are local, and can be opened from Explorer with no problems at all.
The weird thing is that the application views the pdfs fine when running in Visual Studio, but the built application simply shows a grey area where the pdf is supposed to be. The exact same thing happens with both the Adobe control and the WebBrowser control. After a while, I usually get an Adobe error saying There is a problem with Adobe Acrobat/Reader. If it is running, please exit and try again. (103:103). I've looked this error up, which advised me to do things that didn't work (turning off a security setting).
Moreover, if the WebBrowser control is called with a .Navigate(path, true), the application opens an IE window that displays the pdf just fine.
I've tried running as administrator, which makes no difference. I'm at wits' end, so any help would be greatly appreciated. Maybe going for a 3rd party control?
Some further detail: I tried both Adobe 11 and Adobe DC, on Windows 10 and 8.1 VMs, .Net 4.6. Only a Win7 VM seems to work fine.
I solved this by building to x86 targets. Apparently AcroPDF.dll doesn't support x64. Of course, the error messages weren't at all helpful.
My previous answer was incorrect. The real issue is Adobe's Protected Startup mode. This has to be turned off for the application to use the viewer directly without problems.
Can any one help me with this?
I created a simple Excel add-in (using VS2012, Excel 2013, C#)
the Add-in has only a simple ribbon with 1 button and 1 simple form.
when the user clicks the button, the form is shown.
The thing is that when the user closes Excel, the attached image is displayed.
I replicated this by creating a Blank form that does nothing, but still the "Recovering your work" still appears.
this is the button-click event
Form1 f = new Form1();
f.ShowDialog();
After looking for windows Event Viewer, it turned out that "TitleBarDLL.dll" is causing Excel to crash.
investigating this file, it turned out that the problem is caused by Samsung Dual Monitor application (which installs with the monitor driver). Exiting/disabling the application fixes the issue.
I am using Visual Studio 2013 and trying to develop a C# Outlook Add-In project for Outlook 2013 client installations at my enterprise employer.
What could cause Outlook to not load completely, i.e. upon pressing F5 to Start Debugging my application via the VS IDE, the Outlook Splash Screen loads for a second, but Outlook never actually loads. Via the Task Manager, I am able to see a process for Outlook running in the background, but it never materializes into an App process.
I have done the following: in the project's Properties page, I have set Outlook.EXE local path as the Start an external program and also set the working directory.
When I run my code "Start Without Debugging", Outlook indeed does load and I can run my Outlook Add-In, but I am not able to step through my code which, of course, is invaluable.
Any ideas on what I should maybe look for?
UPDATE:
As per #Sarvesh's answer, I created a new Outlook Add-In project without setting any Properties and just one line of code as shown and still the same behavior:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
Console.Writeline("ThisAddIn_Startup was called...");
}
In the project's Properties page, I have set Outlook's local path as
the Start an external program and also set the working directory.
Why you have set these?
If you are developing VSTO addin using templates provided by VS, you don't need to set these properties manually.
Set it back to default and then Debug.
Be aware, only one instance of Outlook can be run at the same time. So, first of all check out the list of running processes for Outlook.exe before starting your project. Only then you can start your add-in under the debugger.
Also I'd suggest disabling all other add-ins in Outlook. Outlook may disable add-ins that take a lot of time for loading. Try to reproduce the issue with a newly created empty add-in project. Set a breakppoint to the Startup event handler and run it under the debugger. Does it work?
Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.
For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold.
Make sure that the add-in is always enabled.
See Performance criteria for keeping add-ins enabled for more information.
I had this same issue just recently - I resolved it by building and installing the addin in Outlook, which when launched threw an error and popped up with the exception.
In the end, the solution to my issue was to create a registry key in the 64-bit hive named EnableVSTOLocalUNC set to value 00000001 (as a dword) in the key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Vsto
Runtime Setup\v4].
Here are some other potential issues you may come across once you've installed the addin.
I am writing a c# application that opens a number of PI ProcessBook display files. PI Processbook is a program that has embedded Visual Basic for Applications support, including a VBE environment.
The problem that I have is that a number of the displays I want to open have macros in them that run automatically when the display is opened. I have set the macro protection to maximum (which should disable macros completely!), but unfortunately there is something in the TypeLibrary that I am using that means that when a file is opened programatically, it bypasses macro security and the macros run anyway. Go figure....
I am therefore trying to find a way to programatically kill these macros, even if they have started. I have tried using SendKeys.Wait("^{BREAK}") to force into break mode. This "works", but is a bit hit-and-miss: I find that if the macro doesn't pause at some point, SetForegroundWindow can't force the VB Editor to the foreground to accept the sendkeys input. I therefore tried using sendmessage. I used SPY++ to see that CTRL+BREAK appears to send a WM_CANCELMODE message to the window. Apparently, this is somehow handled differently from literally ALT+Tabbing or clicking on the window with a mouse and pressing the CTRL+Break keys, in that the message gets queued, but does not appear to process until the macro has finished executing.
Does anyone have any other suggestions of things to try?
I am therefore trying to find a way to programatically kill these
macros, even if they have started.
Hold down the Shift key while opening the Spreadsheet and the Macro's wont run.
Otherwise you could try halting the code while its running: Ctrl + Alt + PauseBreak
Edit:
I have set the macro protection to maximum (which should disable
macros completely!)
Try disabling them:
My Excel addin (XLL AddIn, call it MyAddIn) is built with C#, ExcelDNA, NetOffice, VS2010. Client has another addin (let's call it B), I guess it is written in VBA.
Client says B works fine without MyAddIn. Once MyAddIn is installed, B fails with error:
Error code: 406
Error message: Non-modal forms cannot be displayed in this host application from an ActiveX DLL, ActiveX Control, or Property Page.
I did see this Microsoft resource, but I do not want to just tell the client that B addin needs changing. I want to do something to avoid this from my side.
Here is the steps reported to see the issue:
When B addin is installed, it does not make any registry entry for the Microsoft Excel.
When MyAddin is installed, it makes a registry entry for Microsoft Excel.
Registry entries here basically tells that the addin should be opened when Excel is launched, so B addin is not launched, Excel works fine, MyAddIn works fine.
Now when B addin is launched, it gives the 406 error shown above.
We can ignore the error and keep working with the B addin; disabling MyAddIn is the workaround.
When the B addin is launched, we see that MyAddIn is loaded first before the B addin and then get the 406 error.
When we uninstall MyAddIn, this error is no longer encountered and everything works fine.
To remove this error, we tried changing the registry order to make the B addin always open before MyAddin.
This works, but then this a global change for Microsoft Excel, which means B addin will always open, even when we launch only Excel. This is not desired, as B addin then can't let users work with the static data as the B addin keeps on refreshing real-time. That is the reason the B addin doesn't make an entry in the registry settings. So registry changes are not an option. We can’t always open B addin whenever Excel is open.
I don't have an answer, but here are a couple of things you can try.
You can tell what type of Addin you are dealing with by executing File | Options and selecting the Addins Tab.
If the event happens as soon as you load Addin B, it probably means you are calling a non-modal dialog box as it states, but there are a few other things that could give you similar errors.
Based on your description, it sounds like the error could either be a dialog box in your Addin, or it could be in the other addin, and it gets called as a side effect of some state change your addin made.
To get to the bottom of it, you need to attach a debugger. You can do that by making Excel your Startup Project, or by attaching later. The former is probably easier in this case.
In Visual Studio, Use Project | Properties | Debug, select Start external program and put in the fully qualified pathname to Excel.
Load Addin B manually to give yourself the error
Break into the debugger and examine the call stack.
That will frequently but not always give you good clue as to where the problem is, but it's always the first step. If it doesn't give you useful information (stack info is frequently completely lost in transitions between addins), you may want to put some breakpoints in your projects in any events you handle. Even this doesn't reliably work all the time, but it's worth a shot.
If I had to guess, I would say probably have some event handlers in your add-in that are causing the problem, And you might have to do something like change a .Show to a `.ShowDialog', or defer the processing of the form until outside the event handler but that's just a guess.