When calling Workbook.ExportAsFixedFormat to save an Excel workbook as PDF quickly followed by Workbook.Close, the Excel app crashes but no exception is thrown by NetOffice.
Here's the code to reproduce the issue:
```
var s = $@"C:\users\{Environment.UserName}\desktop\test.xlsx";
var d = $@"C:\users\{Environment.UserName}\desktop\test.pdf";
var app = new Application() { Visible = true };
try
{
var wb = app.Workbooks.Open(s);
wb.ExportAsFixedFormat(XlFixedFormatType.xlTypePDF, d, XlFixedFormatQuality.xlQualityMinimum, false, null, null, null, false);
// 2. Adding the sleep for at least 16ms on my machine makes it succeed.
//Thread.Sleep(20);
// 1. It crashes on the following line.
wb.Close(false);
// 3. Note that calling Close on the COM object works and properly closes the workbook.
//((dynamic)wb.UnderlyingObject).Close(false);
Console.WriteLine("Done");
}
catch (Exception ex)
{
ex.Dump();
}
finally
{
app.Quit();
app.Dispose();
}
```
Some more details.
1. On my machine, it crashes the Excel app when the code executes in 1.02s or less.
2. On my machine (or on slower machines), it doesn't crash the Excel app when the code executes in 1.1s or more.
3. Calling the Close method on the COM object itself doesn't crash the Excel app.
I'm using NetOffice 1.7.3.0 with Office 2016 16.0.6741.2056 on Windows 10 Enterprise Anniversary Update, 64-bit. I used LINQPad to reproduce the scenario above.
I have uploaded the LINQPad query (if needed). The Excel file (test.xlsx) is a very simple workbook with "Hello World!" in the first cell.
UPDATE:
It looks like in some cases, it still crashes the Excel app even when calling the Close method on the COM object itself. This could be due to the dynamics framework being a bit slower to execute...
Comments: Sebastian, As I said, no exception is thrown. As I already said, I'm using NetOffice 1.7.3.0 with Office 2016 16.0.6741.2056 on Windows 10 Enterprise Anniversary Update, all 64-bit. My CPU is an Intel Core i7-5820K (more info at [ark.intel.com](http://ark.intel.com/products/82932/Intel-Core-i7-5820K-Processor-15M-Cache-up-to-3_60-GHz)) and is also 64-bit. Calling NetOffice.Core.Default.ProxyCount just before Workbook.Close method returns 9. Setting NetOffice.Settings.Default.MessageFilter.Enabled = true; has no effect and the Excel app still crashes. When I say that the Excel app crashes, it crashes with the window Microsoft Excel has stepped working. I included the screenshot in attachment. There's no exception at all that is raised. The code executes fine, but the Excel app is crashed and not responding after the Workbook.Close method is called. The test.xlsx workbook is just the test workbook I'm using in my test. There's nothing to be done with it...
Here's the code to reproduce the issue:
```
var s = $@"C:\users\{Environment.UserName}\desktop\test.xlsx";
var d = $@"C:\users\{Environment.UserName}\desktop\test.pdf";
var app = new Application() { Visible = true };
try
{
var wb = app.Workbooks.Open(s);
wb.ExportAsFixedFormat(XlFixedFormatType.xlTypePDF, d, XlFixedFormatQuality.xlQualityMinimum, false, null, null, null, false);
// 2. Adding the sleep for at least 16ms on my machine makes it succeed.
//Thread.Sleep(20);
// 1. It crashes on the following line.
wb.Close(false);
// 3. Note that calling Close on the COM object works and properly closes the workbook.
//((dynamic)wb.UnderlyingObject).Close(false);
Console.WriteLine("Done");
}
catch (Exception ex)
{
ex.Dump();
}
finally
{
app.Quit();
app.Dispose();
}
```
Some more details.
1. On my machine, it crashes the Excel app when the code executes in 1.02s or less.
2. On my machine (or on slower machines), it doesn't crash the Excel app when the code executes in 1.1s or more.
3. Calling the Close method on the COM object itself doesn't crash the Excel app.
I'm using NetOffice 1.7.3.0 with Office 2016 16.0.6741.2056 on Windows 10 Enterprise Anniversary Update, 64-bit. I used LINQPad to reproduce the scenario above.
I have uploaded the LINQPad query (if needed). The Excel file (test.xlsx) is a very simple workbook with "Hello World!" in the first cell.
UPDATE:
It looks like in some cases, it still crashes the Excel app even when calling the Close method on the COM object itself. This could be due to the dynamics framework being a bit slower to execute...
Comments: Sebastian, As I said, no exception is thrown. As I already said, I'm using NetOffice 1.7.3.0 with Office 2016 16.0.6741.2056 on Windows 10 Enterprise Anniversary Update, all 64-bit. My CPU is an Intel Core i7-5820K (more info at [ark.intel.com](http://ark.intel.com/products/82932/Intel-Core-i7-5820K-Processor-15M-Cache-up-to-3_60-GHz)) and is also 64-bit. Calling NetOffice.Core.Default.ProxyCount just before Workbook.Close method returns 9. Setting NetOffice.Settings.Default.MessageFilter.Enabled = true; has no effect and the Excel app still crashes. When I say that the Excel app crashes, it crashes with the window Microsoft Excel has stepped working. I included the screenshot in attachment. There's no exception at all that is raised. The code executes fine, but the Excel app is crashed and not responding after the Workbook.Close method is called. The test.xlsx workbook is just the test workbook I'm using in my test. There's nothing to be done with it...