How to automatically detect corrupted Excel files generated with ArcGIS 10.6/xlswriter/SpatiaLite using Python 2.7

I created a Python toolbox in ArcGIS 10.6 to produce Excel reports out of a SpatiaLite DB, using the library xlsxwriter. I am using Excel 10 and Python 2.7.

The Excel file includes the results of several queries and photos too. It works fine most of the times but for certain features produces the following opening error message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error012280_01.xml</logFileName><summary>Errors were detected in file 'C:\Test\Data\ExcelReports\R90GGH.xlsx'</summary><removedRecords><removedRecord>Removed Records: Named range from /xl/workbook.xml part (Workbook)</removedRecord></removedRecords></recoveryLog>

Excel prompts to recover data, and indeed it opens the file after accepting the loss of some data, and after I saved the repaired file, apparently all is in order.

I have not found any difference among the data of the reports that work and of the reports that don't.

I used the trick of saving as zip and then unzip and check the XMLs but I do not see errors there (although it would be hard to detect because the density of the XML)

I thought it was something to do with the definition of the print area or repeating files or the page breaks so I tested commenting those lines, but the error persisted.

I can live with saving the bad reports but the problem is to find which one are the bad ones, since they are over 300.

I used a script which I found in this site to automatically opening and checking for errors using xlrd, but according to the script all the Excel files are OK.

def test_book(filename):
    try:
        book = open_workbook(filename)
        try:
            sheet = book.sheet_by_index(0)
            b6 = sheet.cell_value(rowx=5, colx=1) #b6 an internal code
            print "'"+ str(sheet.name) + "',"
            return True
        
        except XLRDError:
            return False
            print "error"
    except Exception as e:
        return False
        print "error"

I would like to find the error, but my question is: how can I detect the bad Excel files automatically, since to check my 300 files manually I spent more than an hour and these reports are periodic.

I had previously asked in GIS Stack Exchange but they considered my question not was in direct relation with GIS.

EDIT:
This is workbook.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"><fileVersion appName="xl" lastEdited="4" lowestEdited="4" rupBuild="4505"/><workbookPr defaultThemeVersion="124226"/><bookViews><workbookView xWindow="240" yWindow="15" windowWidth="16095" windowHeight="9660"/></bookViews><sheets><sheet name="R7MB22" sheetId="1" r:id="rId1"/></sheets><definedNames><definedName name="_xlnm.Print_Area" localSheetId="0">R7MB22!$A$1:$H$137</definedName><definedName name="_xlnm.Print_Titles" localSheetId="0">R7MB22!$1:$2</definedName></definedNames><calcPr calcId="124519" fullCalcOnLoad="1"/></workbook>

It is going to be difficult to figure out if a file is corrupted without using Excel to read the file since the files produces by XlsxWriter rarely include something like an XML error that could be caught be a third party tool. In general these types of issues occur due to something like a very invalid formula. It this case it looks like an issue with names ranges but that could related to actual names ranges or autofilter ranges or print areas.

A better approach would be to figure out what is causing the corruption and avoid doing that. XlsxWriter works hard to avoid creating a file that Excel considers has an error but it can happen.

If you open a bug report against XlsxWriter with one of the corrupt files I will have a look at it.

Update: The bug report is here: #963. The issue is caused by a worksheet name that looks like a RC range and should be quoted.