Excel Worksheet and backups suddenly get Unreadable Content Message

It appears that many of us are getting the same error with no resolution yet.  i have recently found that a form I am writing has also got the same error.  I have gone through step by step and found the trigger in mine, maybe this will help others in finding the resolution.

The form has checkbox controls which hide/unhide and named range upon selection.

Steps followed:

Create main template

Name Range 'PassApps'

Insert Control 'Check Box1'

Apply code to hide/unhide (codes below)

Check if working.

If the file is saved when the rows are unhidden - no problems

If the file is saved with any of the named ranges hidden - corruption occurs

If the file is saved with rows that are not a named range or only part of a named range hidden - no problems

(The named ranges are not the issues as the corruption occurs when the rows are called out in place of the named range)

CODE:

Sub ShowPassApps()

    Range("PassAPPS").Select

    Selection.EntireRow.Hidden = False

    Range("A78").Select

End Sub

Sub HidePassApps()

    Range("PassApps").Select

    Selection.EntireRow.Hidden = True

    Range("A78").Select

End Sub

Private Sub CheckBox2_Click()

 Run IIf(CheckBox2, "ShowPassApps", "HidePassApps")

End Sub

When the file re-opens with the corruption, all of the Checkboxes have been removed as part of the repair.

As with everyone else on this string, help wuold be very much appreciated

Am recieving the same error message when trying to open a workbook with pictures and sames pasted in certain cells.  The issue persists even when opening a backup version of the file from a date I am %100 certain the file was fine.

 

Am I really going to just put up with completely redoing a workbook every month or so?  This is the second workbook this has happened too, both are being used in similar ways.

 

Any more recent progress on this issues?

 

 

  -Brad

 

 

Below is error details...

 

 

**** <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

**-** <recoveryLog xmlns="**http://schemas.openxmlformats.org/spreadsheetml/2006/main**">

**** <logFileName>error045960_01.xml</logFileName>

**** <summary>Errors were detected in file 'G:\Brad\WIP\SPID 2402 NORTHFIELD CHUCK.xlsx'</summary>

**-** <repairedRecords summary="Following is a list of repairs:">

**** <repairedRecord>Repaired Records: Drawing from /xl/drawings/drawing1.xml part (Drawing shape)</repairedRecord>

**** </repairedRecords>

**** </recoveryLog>

I am having a related but somewhat different problem.  Every file I create with Excel 2010 is corrupt, and crashes after a few minutes of work.  When I try "Open and Repair", i get the following error message:

<?xml version="1.0" encoding="UTF-8" standalone="true"?>

-<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error342240_01.xml</logFileName><summary>Errors were detected in file 'C:\Users\BlueMonk\test1.xlsx'</summary>-<additionalInfo><info>Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded.</info></additionalInfo></recoveryLog>

*EVERY* file i try to work with has the same problem.  Please help.

I had the same problem, except I didn't really have any drawings as such. Well, I had a few "lines" drawn on a chart but removing them didn't do anything. No, after trying different permutations, I realised what it was - grouping and hiding rows. The sheet had a fair bit of information on it and it looks like the worksheet was groaning under the weight - we have other sheets with lots of rows and hidden data but they seem to be ok. When I ungrouped/unhid everything, suddenly the problem disappeared. Then if I grouped a certain section, the error came back. I suspect this is really about grouping/hiding graphs, rather than simply grouping/hiding cells.

I had the same problem using Excel 2013 on an .xlsx file with images inside comments.

I was able to get the document back to a working state, and at the same time see where the corruption is.

Here's what worked for me (summary: remove a couple of bogus tags in an embedded text file):

1. take a backup of the file (just in case)
2. open the file and accept Excel's tentative to recover the file
3. note the full path of the "removed part" file, e.g. "/xl/drawings/vmlDrawing2.vml"
4. close the file without saving
5. rename the file to end with .zip (e.g. myExcelFile.xlsx.zip)
6. open the zip file, it shows as a folder hierarchy (if you're curious to see where your images are stored, I found them fully readable under the following folder in the zip file: \xl\media\ )
7. extract the problematic file found in step 3, e.g. "/xl/drawings/vmlDrawing2.vml"
8. open it with Notepad
9. if you want to see what is wrong with this file, you can copy and paste its whole text content to an online XML syntax checker (e.g. http://www.w3schools.com/dom/dom_validate.asp).  Mine showed duplicate attributes on a given line (once you correct a line, you can re-paste your corrected text to find the next error, and so on).
10. Here's the bug I had: all the v:fill tags had multiple o:relid attributes, even a working file has multiple, and it shouldn't, but in the case of the broken file, one of those attributes is different from the others, e.g.: v:fill o:relid="rId3" o:relid="rId3" o:relid="rId3" o:relid="rId3" o:relid="rId3"  o:relid="rId2"  <--- note the "rId2" instead of ="rId3" like the rest of the line
11. for each v:fill tag, remove all but the last o:relid (in the previous example, that part of the line would now be v:fill o:relid="rId2" )
12. once you have verified this for each v:fill, the XML of the file should be ok (step 9), save the file and put it back in the zip (overwriting the original one)
13. rename the Excel file to its original name (e.g. myExcelFile.xlsx) by removing the .zip extension added in step 5
14. open the file with Excel, everything is back to normal

The error is probably due to changes that force renumbering of the existing images such as removing a line on which there is a comment with a picture on it (if it's not the last picture added) - I can reproduce the bug every time I remove one such line.  We can see that just the last entry ("rId2") is corrected, the rest stay the same ("rId3"), and Excel can't cope with those different values for the same tag.  To Microsoft: preventing multiple occurrences of the same attribute on a given tag should be the initial goal to solve this issue.