Due to a "freeze" during formatting a book item, I had to force boot-up. Now CAS-UpArrow indicates two errors: Test 30018, attach 13406 has a desc. line (13407) with illegal  WCHAR(13). The next error is the same except for the field type WCHAR(10). 

Are these externally visible fields and which are they, so maybe I can fix them? 

My original message was a question: "How [do I] repair a damaged file?" 

Now I can turn it into an answer "[Here's] how to repair a damaged file." 

Fiddling around, I discovered the following: 

 1. re-index did no good 
 2. export all individuals and error follows them 

The latter gave me a method for isolating the error: Export half the individuals and check which half of the population contains the error. By continually halving the population (originally about 800) and retaining the half with the error I isolated the problem to a single individual after 9 steps. (This process is known as a Binary Search.) 

Once the problem person was found, I assumed that the error fields were some sort of character fields from their descriptor (WCHAR), and went over this guy with a fine tooth comb, so to speak. Knowing that invalid characters often have no visible presence on the screen, I blanked out field after field, checking for the error after each one. I eventually found that the two errors disappeared when I blanked out the description field in the one scrapbook picture for this guy. 

This [binary search] is a useful method for isolating one particular thing hiding among other things that can be ordered. In this case, I ordered the individuals in the workspace by BIRTHDATE and selected by using relationals on particular dates (before 1700, &c), cutting the remaining range in half each time. 

 In general the requirements are:

 1. Ability to put the collection in order 
 2. Ability to partition based on order 
 3. Ability to detect target in partitions