<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-02T16:15:34Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-21T20:30:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-21T20:29:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-21T20:25:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Verified with datapro versions 4.0.1003.49231, 4.1.360.49222 and 4.2.48.49229.

Datapro logs show number of corrections and detections of configuration errors on Das now..

Used theese steps to test..


-------------------------------------------------

Create and Run a test with Das..  arm  trigger and  but dont download  then  close dp without downloading   

-------Then Corrupt FileStore  on DAS -------------------------



Use FWTU navigate  to base&gt;manage and select file data   enter 0 next to read button and click read on the right hand side and save to a file 
now enter a 1 in the box and click read on right side again and save to a second file. 

(theese are your filestores that live on the DAS and store config information .

open the first file from filestore 0  in text editor and corrupt it by entering random characters and save it .
Do the same to the second file 

Now load each file onto the das 



Enter 0 in the box next to write and click the right write button and select the first file and write it 


Enter 1 in the box next to write and click the right write button and select the second file 



now attempt to download with datapro  from download tab and you should get a message that das has no config file and dp will use local config file to download data


After Downloading  Check log files for the enteries ...
Setting NumberTimesDetected to
and Setting NumberTimesCorrected to

Repeat all the steps to corrupt the  filestores above then download again with datapro  and check the log 

-------------------------------------------------------------------
The NumberTimesDetected value and the NumberTimesCorrected should increase by 1  each time you corrupt the filestore and redownload.

 
 
 
</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-07-21T20:16:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-21T17:25:18Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1/4.2@49165
 
This issue is an add-on to previous issues like 28111: Allow units to recover from corrupted configurations on read configuration if possible and 29585: Remove invalid config warning, and add a separate failed config log also read from DIAG if possible.
 
 
 
The configuration is stored in an XML file that is compressed and then stored in a filestore on SLICE devices.  We've found in practice that sometimes the file that is read out of the SLICE devices fail CRC checks, often with a single bit flipped.  Because of this the file can't be decompressed.  With 29585 and 28111 we added some ways to read from back up file stores (diagnostic file store, pc file store).  Chad has expressed concerned we haven't addressed the original issue with the SLICE which is that it can have bit flips when writing memory and we are masking the issue by recovering. 
 
This patch addresses that by storing in user attributes how many times the configuration was written, how many times an error was detected, and how many times it was corrected.  The idea here is to give a chance at RMA or cal time to go back and check out how frequently this is happening on some devices.  Anecdotal experience suggests it happens way more frequently on some devices than most, and might get worse with use.
 
User attributes originally had their own attribute store (like system attributes and event attributes), but that was eliminated with SLICE2 and beyond.  With SLICE2 and beyond we recreated user attributes by writing an xml file to one of the available filestores.  The patch adds 3 new functions for reading an attribute for number of times written, number of times issue detected, and number of times corrected.
 
If you are have an issue in practice a user might not correct the issue right away and might try to run several downloads before correcting the issue, this is why I separated the # of times an issue was detected from the # of times it was corrected.  
 
There's no UI, so the log needs to be searched to get to see when values are written to the user attributes.  You can see:
 
2023-07-06 15:16:52.977 Setting NumberTimesWritten to 1
 
or
 
2023-07-06 15:19:23.378 Setting NumberTimesDetected to 1
 
or
 
2023-07-06 15:20:45.305 Setting NumberTimesCorrected to 2
 
now duplicating issues is probably going to be impossible on demand without doing it on purpose.
 
if you search the code for makeAMess
 
you can uncomment the make a mess code to create corrupt configs with a certain probability.
 
another option would be to search for  Setting NumberTimesDetected to
 
and setting a breakpoint and manually setting the next statement to the code that executes if the config is blank.
 
There are a couple of false positives that will come from this approach, if the configuration file is cleared out programmatically (say using FWTU), it'll probably show up as invalid even though there wasn't an issue with a bitflip.
 
Similarly, the configuration could be invalid because of different software or software versions and not necessarily a bitflip.  (say swapping the unit between sliceware and datapro).
 
I can enable the "MakeAMess" code when we are ready to test, or the FWTU can probably be used to write an invalid garbage config as well, which when going to download might also cause the configuration to be corrected.  Would run a test, then use the FWTU set file to write a garbage file to both filestores 0, 1 in manage base.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-07-11T15:02:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-11T14:44:41Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-11T14:44:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>every time it's corrected it updates this attribute.
 
2023-07-06 15:20:45.305 Setting NumberTimesCorrected to 2</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T22:22:18Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>every time it detects an error it updates this attribute
 
2023-07-06 15:19:23.378 Setting NumberTimesDetected to 1</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T22:20:56Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>whenever it writes the configuration it updates the user attribute like this;
 
2023-07-06 15:16:52.977 Setting NumberTimesWritten to 1</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T22:19:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T21:14:28Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>sure would be nice if we recorded the # of times armed or config written, etc.
 
here is where we recognize an issue with the xml:
 
eventAggregator.GetEvent&lt;DASConfigurationEvent&gt;().Publish(new DASConfigurationArg(this, blank, failedValidation));
 
here's where the correction is made
 
        protected override void AsyncUpdateConfigurationFromFile(object asyncInfo)</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T16:11:17Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T16:05:33Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T16:03:38Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>related to current silent logging in case 29585
 
related to recovery logic in case 28111
 
 
 
DP can write a user attribute that would note that we've had to recover the config on THIS unit. we can discuss with Jayden how to make use of that user attribute in the cal software to flag it for review when its back</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-06T16:02:56Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-06T15:59:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>using user attributes</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-07-06T15:59:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>