Commented Unassigned: Workbook.ExportAsFixedFormat followed by Workbook.Close crashes the Excel app but no exception is thrown [22310]

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, 1) Yes, it does fix the issue on my machine. The code seems to be executing too fast for Excel. 2) I have the following entry in the event viewer. ``` Log Name: Application Source: Application Error Date: 2016-08-25 9:34:46 AM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: maboivin-pc.xxx.local Description: Faulting application name: EXCEL.EXE, version: 16.0.6741.2063, time stamp: 0x579e3ad1 Faulting module name: EXCEL.EXE, version: 16.0.6741.2063, time stamp: 0x579e3ad1 Exception code: 0xc0000005 Fault offset: 0x000000000031ec99 Faulting process id: 0xa784 Faulting application start time: 0x01d1fed571561d63 Faulting application path: C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE Faulting module path: C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE Report Id: afddf70b-6ac8-11e6-9c0c-d0509936edec Faulting package full name: Faulting package-relative application ID: Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2016-08-25T13:34:46.797178400Z" /> <EventRecordID>5655</EventRecordID> <Channel>Application</Channel> <Computer>maboivin-pc.xxx.local</Computer> <Security /> </System> <EventData> <Data>EXCEL.EXE</Data> <Data>16.0.6741.2063</Data> <Data>579e3ad1</Data> <Data>EXCEL.EXE</Data> <Data>16.0.6741.2063</Data> <Data>579e3ad1</Data> <Data>c0000005</Data> <Data>000000000031ec99</Data> <Data>a784</Data> <Data>01d1fed571561d63</Data> <Data>C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE</Data> <Data>C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE</Data> <Data>afddf70b-6ac8-11e6-9c0c-d0509936edec</Data> <Data> </Data> <Data> </Data> </EventData> </Event> ``` 3) No, it's a simple console app. In my case, I tested the scenario using LINQPad. I was able to reproduce it on 3 different machines so far. 4) No, it's running on the default thread. 5) Calling the Close method on the proxy has no effect on the result and the Excel app still crashes. In the end, I don't think it's a NetOffice issue. It looks more like it's an Excel 2016 issue... I was able to reproduce the issue using only the Excel Interop that ships with VS2015. I might have to report this issue to the Office team directly. Do you have any contact in the Office team?