Office-js: Function call causes Excel to silently crash and restart

[misaunde]

Within the last few weeks or so, without any changes to my code which has been running fine for months, Excel has started randomly silently closing and restarting. I've seen it happen on a number of different computers, workbooks, and often times near the same function call, although a few times at completely different locations in the app, even right at startup.

The frustrating part is, that it immediately closes not only Excel, but the side panel, IE, and the IE debugger, so I'm unable to determine the exact root of the problem or even if my add-in had an error. I've tried logging to localStorage and wrapping the function getting called at the highest level in a try-catch without success.

However, as far as I can tell, the function call where it occurs most regularly is Office.context.document.getFileAsync()
Has something changed since 1.8 that could be related to this?

Expected Behavior

I would expect Excel not close, and if there was an error caused by my add-in, for it to get caught and handled instead of crashing Excel.

Current Behavior

Excel silently closes and restarts to an auto-recovered version of the workbook

Steps to Reproduce, or Live Example

• Link to live example: ______

console.log("here") //This gets logged as expected
Office.context.document.getFileAsync(FileType.Compressed, {sliceSize: 1000000}, async (result) => {
  console.log("result?????: ", result); //never reaches this line
  if (result.status === Office.AsyncResultStatus.Succeeded) {
    //work done here...
  } else {
    this.messageService.setMessage("error: " + result.status)
  }
 });

• Additional details:
  Besides not knowing the exact cause of this issue, I have not figured out how to consistently reproduce it. Any idea on how I can get some sort of more detailed log or info from windows on what is going on here in Excel?

Context

Trying to upload a file to the server.

I know this is grasping at straws here, but this is the closest thing I can find related to my issue (even though I don't use the function they reference and no sheets get deleted, but it sounds like a similiar result of Excel crashing and restarting using API v1.8:
https://github.com/OfficeDev/office-js/issues/263

Your Environment

• Platform [PC desktop, Mac, iOS, Office Online]: PC
• Host [Excel, Word, PowerPoint, etc.]: Excel 2016
• Office version number: Version 1810 (Build 11001.20074)
• Operating System: Windows 10
• Browser (if using Office Online): n/a

Useful logs

• [x ] Console errors
• [ ] Screenshots
• [ ] Test file (if only happens on a particular file)

From Event Viewer: Windows Logs -> Application:

    Faulting application name: EXCEL.EXE, version: 16.0.11001.20074, time stamp: 0x5bd0fbfc
    Faulting module name: ntdll.dll, version: 10.0.17134.254, time stamp: 0xa5a334d4
    Exception code: 0xc0000374
    Fault offset: 0x00000000000f4d3b
    Faulting process id: 0xc10
    Faulting application start time: 0x01d4755219483136
    Faulting application path: C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE
    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
    Report Id: cbed6f65-37a7-48ad-b01f-939e3cd097b6
    Faulting package full name: 
    Faulting package-relative application ID: 

[dmahugh]

Thanks for reporting this. To track down what's happening, it would be useful to know the Fault Bucket #, and then we can look into what Watson reported on our end. You should be able to find this in the next event after the error that you provided above, in the Event Viewer. Thanks!

[misaunde]

Awesome, here's the fault bucket # and that entire log:

Fault bucket 1997120934903425266, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: EXCEL.EXE
P2: 16.0.11001.20074
P3: 5bd0fbfc
P4: StackHash_2015
P5: 10.0.17134.254
P6: a5a334d4
P7: c0000374
P8: PCH_86_FROM_ntdll+0x000000000009AA44
P9: 
P10: 

Attached files:
\\?\C:\Users\USER~1\AppData\Local\Temp\{35F68BAC-47F9-4059-AEE3-1FA1562AF506} - OProcSessId.dat
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER6886.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER6A7B.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER6A9C.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER6A9A.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER6ABA.tmp.txt

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_EXCEL.EXE_921e425e81da96bcfa15ac6c2a3c5636542b94_8989db35_d21187e6

Analysis symbol: 
Rechecking for solution: 0
Report Id: 361d2834-48b0-412c-8f81-a83c435854e9
Report Status: 268435456
Hashed bucket: e67c25cc1857b63dfbb732e8ba6a28f2
Cab Guid: 0

[jipyua]

@misaunde, seems this is caused by the GetFileAsync API, but can you provide a detailed repro step using your app and api code? we need to first repro it in order to fix it. thanks.

[kbrandl]

@misaunde are you able to provide the information that @jipyua has requested?

[misaunde]

Well... Unfortunately, I can't send any code that consistently reproduces this. This is more in the ballpark of, apparently, at least a few stars have to align for it to crash. Somedays, I can reproduce it somewhat reliably by just submitting the file over and over again in quick succession until it crashes (usually before 5-10 submits).

Like I mentioned earlier though, I have not figured out how to consistently reproduce this, and I've witnessed this occur across multiple computers not only when getFileAsync() was called, but at other random times during the usage of this specific tool that uses getFileAsync() and/or a few times just opening this specific add-in.

Sometimes it closes after successfully transferring the file to the server, other times it closes when it starts sending or before it's done sending all the slices.

This tool has been in production for nearly a year and these issues only just recently started occurring, probably in the last month or two.

I guess I could try posting some of our code and maybe there'd be something suspicious you could spot? At this point, it's worth a shot.

async publishFile() {
  //some validation, etc...

  Office.context.document.getFileAsync(FileType.Compressed,
    {sliceSize: 1000000}, (result) => {
      if (result.status === Office.AsyncResultStatus.Succeeded) {
        // Get the File object from the result.
        const data = result.value;

        const state = {
          file: data,
          counter: 0,
          sliceCount: data.sliceCount,
          submissionId: submissionId
        };

        this.recursiveSendSlices(state);

      } else {
        this.messageService.setMessage("error: " + result.status)
      }
    }
  );

}

private recursiveSendSlices(state) {
  state.file.getSliceAsync(state.counter, async (result) => {
    if (result.status === Office.AsyncResultStatus.Succeeded) {
      try {
        //this updates a message on the loading bar
        setProgressMessageWithKeepAlive("Sending file slice: " + (state.counter + 1) + " of " + state.sliceCount + ". ", (((state.counter + 1) / state.sliceCount) * 100) - 1, "Submission", this.messageService)
        this.applicationRef.tick();

        this.submissionInfoList = await this.sendSlice(result.value, state);

        state.counter++;
        if (state.counter < state.sliceCount) {
          this.recursiveSendSlices(state);
        } else {
          this.successfulSubmission = true;
          setProgressMessageWithKeepAlive("Finished Publishing! ", 100, "Submission", this.messageService)
          this.applicationRef.tick();
          this.closeFile(state);
        }

      } catch (exception) {
        setProgressMessageWithKeepAlive("Error! ", 100, "Submission", this.messageService)
        this.errorService.handleError(exception, "Error sending file!")
        this.applicationRef.tick();
      }
    }
  });
}


private async sendSlice(slice, state) {
  const data = slice.data;

  // If the slice contains data, create an HTTP request.
  if (data) {
    // Encode the slice data, a byte array, as a Base64 string.
    // NOTE: The implementation of myEncodeBase64(input) function isn't
    // included with this example. For information about Base64 encoding with
    // JavaScript, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding.
    // const fileData = btoa(data);
    // const fileData = data.toString('base64')


    const fieldInfo = {}
    Object.entries(this.stateService.currFieldDataMap).map(([k, {dataType}]) => fieldInfo[k] = {dataType: dataType})

    const retVal = await this.uploadService.sendDataToServer(data,
      this.stateService.getSanitizedFileName(),
      state.sliceCount,
      state.counter,
      this.stateService.user,
      this.submissionType,
      state.submissionId,
      fieldInfo
      //handful of other properties we send to the server
      );


    if (_.isError(retVal)) {
      this.applicationRef.tick();
    }

    return retVal;
  }
}

private closeFile(state) {
  // Close the file when you're done with it.
  state.file.closeAsync((result) => {
  });
}

I'll point our that our setProgressMessageWithKeepAlive() function looks like this:

export async function sendMessageWithKeepAlive(message: String, messageService: MessageLogService) {
  messageService.setMessage(message)
  await Excel.run(async ctx => {
    ctx.workbook.getSelectedRange();
    await ctx.sync();
  });
}

Which is basically a hack we use for long running jobs to prevent Excel from shutting us down.

If all of this isn't enough information to do anything on your side, I guess my big ask would be: Any idea on how I can get some sort of more detailed log or info from windows on what is going on here in Excel and why? I'm at a loss on this one.

[kbrandl]

@misaunde thank you for providing this detailed information.

@jipyua and @XuanZhouMSFT please see the information that @misaunde has provided (per your earlier request).

[misaunde]

The majority of the time it appears crash after finishing the download and after closeAsync() returns "successful"

[theGove]

I'm experiencing very similar behavior as @misaunde. However, I think I can provide a way to reproduce the error somewhate consistently.

The example comes from the MS Documentation on the getFileAsync() method as this URL: https://docs.microsoft.com/en-us/javascript/api/office/office.document?view=office-js. It's a long page, just scroll to getFileAsync or search the page for "The following example gets the document in Office Open XML"

I've built an Excel Add-in that shows the problem. There are two buttons, one that calls getFileAsync and one that changes the value of a range on the active sheet. Clicking either one repeatedly will not cause an error; however, by alternately clicking one then the other, you can crash excel. It may take 100 or more cycles, but I can get Excel 365 on windows (version 1812 - build 11126.20132) to crash every time.

The addin is in a public repo on github (https://github.com/theGove/getFileAsync_bug.git), but I've also posted the manifest here.
getFileAsync_manifest.zip

[kbrandl]

@theGove thank you for providing this information.

@jipyua and @XuanZhouMSFT please see the information that @theGove has provided regarding repro steps for this issue (per your earlier request).

[donlvMSFT]

Update: There is already a fix now, still need some time for code to go to product.

[kbrandl]

@J-January thank you for the update; please comment here again when the fix has been deployed to the product.