Unspecified Error, word/document.xml, Line:2, Column: 0

I don't know if this is one of the line: 2 column: 0 threads where I've detailed my own methods (and don't want to go through 39 pages of replies to find out) so I'll supplement here.

Rather than use the native ability of Windows 7 to look into a renamed .ZIP (from .DOCX), I use WinRAR to open the DOCX directly. After the first time a full right-click, Open with..., Browse has been performed on a DOCX, WinRAR will be in the list of right-click, Open with... programs. After associating the .XML extension with Notepad++ as the default, simply double-clicking the word/Document.xml file from within WinRAR is sufficient to open it in Notepad++ as a TMP file. The big benefit is that making corrections then saving in Notepad++ produces a message box in WinRAR (Do you want to update the archive?). Click Yes and then attempt to open the DOCX in Word immediately.

It takes a small bit of effort to get WinRAR into the Open with... list of programs and associate the .XML extension with Notepad++ but that only has to be done once. There is no right-click, Open with in WinRAR so it has to be the default. I did that years ago and it is still saving me time for every new corrupt DOCX I work on by not having to rename/re-rename the DOCX to .ZIP and back for every attempt at opening the corrected document. The described 'cascade failures' can easily run up to a dozen or more (I start trying Find & Replace All after two or three) and this is the easiest way I know.

I am impressed by the description of the Microsoft's XML Notepad's ability to adjust an XML file into properly formatted XML syntax layout. I hope it indents parent/child nesting properly. I plan to try it sometime soon but if anyone has any experience with how it handles >10Mb XML files, I would appreciate them sharing that here.

Øystein,

Hi. By "normalizing" line endings, do you mean it puts each tag on a separate line? If Microsoft's XML Notepad is doing that, then it is a valuable tool. I'll give it a try.

What you did, I think Jeeped is doing too. When you put the document.xml tags on separate lines using NotePad++ and then rezip all the files, Word is still able to read it and now tells you exactly which line to go to find the XML error. I just checked and even Word 2013 does this.

I was first clued into this technique by Daniel "3ICE" Berezvai posts here: http://bit.ly/1s4TPsT. Below are his steps to put the document.xml XML tage on separate lines using NotePad++. Please note in step 3, *it is vital that you the radio button in the Replace Window in the "Search Mode" Section in the lower left, from "Normal" to "Extended" or it won't work! In Normal mode Notepad++,the new line (\n) and return (\r) character combinations will be added as plain text not as the hidden formatting characters they need to be.*You can even see these hidden formatting characters by choosing the Show Symbol submenu on the View menu and click on "Show all characters". :

1. "Change your file extension from docx to zip *
2. Extract word/document.xml * [The zip structure of corrupt DOCX files with the Unspecified error type are usually not damaged, but if you can't unzip the file, try repairing the zip file first. For that I think the best is the fixfix (-FF) command of the free InfoZip's zip.exe. Once you have a repaired zip, I find 7zip is the best at extracting repaired zip files.]
3. Using a Programmer's Notepad (I prefer Notepad++) replace >< with >\r\n< in Extended mode to make the XML more readable, putting each tag on its own line. (The expression \r\n stands for new line in windows.) You can use regexp mode or multi-line replace in other text editors, or copy a newline/hidden paragraph symbol and paste it in the replace box. (Which works even in Word.) [Notepad++ even has a halfway decent multiline replace tool in the ToolBucket plugin which can easily be using the Plugin Manager on the Plugin menu.]
4. Import the modified word/document.xml back into the archive [and rezip if you have unzipped to extract theword/document.xml file. It is imperative to rezip starting for the root of the file, where the[Content_Types].xml hangs out. Don't go up one level so that you are zipping one folder which has the _rels,  customXml, docProps and word folders plus the*[Content_Types].xml (if your file has all those folders otherwise work with what you have), otherwise Word won't recognize it.*]*
5. Rename it back from zip to docx *
6. Attempt to open the document
7. Note that this time the error message will be more useful, for example it will tell you that the error is at: line 13540, as opposed to line 2 column 0.
8. Go to the line specified (was 13540 for me) and remove it. And the tags around it too, if necessary. Make sure you keep the XML well-formatted! (You can attempt to fix the erroneous line instead of removing it, but usually the indicated line is as useless as the other lines around it, so removal will not result in any loss of data. See the note** below for why this is.)
9. Import document.xml and rename zip/docx as usual. *
10. Repeat steps 6-9 until your document is recovered. (Took me 5 repeats, as more errors arose at lines 15870, 13595, 13222 and 10835.*** (Not sure why it found errors in reverse order, but it did.)

* These steps are unnecessary if you use Total Commander (or other advanced file managers). It can look inside docx files as if they were folders because it automatically recognizes them as compressed archives. It also lets you edit files easier, just press F4. And it even detects file changes and asks if it should reimport your edited files into the archive upon closing the editor.

** Note: To me it seems that none of the errors were real. While the source code was extremely bloated and wasteful, every indicated error was a line with completely well formed XML. (Around it was good XML too.) For pages and pages, almost every line repeated the same statement:"

Thanks for the update and description of how your fixed your problem.

Well done Øystein_!

Personally I use Notepad++, a free programmer's text editor as it displays both line number and line offset. Word 2007 will often show the location of the error when Word 2010 or 2013 will not but not everyone has access to multiple Office versions.

It seems that you had what I have called a 'cascade failure' which occurs when the first error will reproduce almost identically in similar subsequent XML code further down the document.

Again, congratulations and thank you for sharing your insight into this issue! Big +1.

Jp'd