OK here's the latest. installing the latest update did not solve the issue. ever since windows 10 came out I have made the habit of downloading the .ISO that contains install.wim when ever I upgrade builds. This habit saved me several time in the past on my old system. these version were called techbench ISO's at one point I believe. anyways, I mounted the ISO, and moved the install.wim to c:\temp. then I dropped to the recovery mode command prompt. from here I performed an offline image repair using two different methods. neither method of using dism worked. I tried mounting the install.wim into c:\mount and then opened a second dos prompt and compared the two copies of the files (srmclient.dll & srmscan.dll) there were minor differences, mostly having to do with the dates on the files. mutliple passes of SFC had failed to fix the issue, despite SFC saying it had. and then I got the bright idea of using one of SFC other features, a targeted scan focusing on only one file. basically I used the following command - "sfc /scannow /offbootdir=c:\ /offwindir=c:\windows\ /scanfile=c:\windows\syswow64\srmscan.dll" this gave the same message that I had been seeing all along, but when run a second time, the message saying no resource protection errors found was displayed. I ran the same command on srmclient.dll and here is where things get a bit weird. fixing the other file seems to have fixed both files at the same time. So, I rebooted back into windows, and ran SFC once more. now here is where things get really, really weird. SFC still says those two files have a file hash mismatch. BUT, when running at targeted scan using either /verifyfile or /scanfile, SFC says 'Windows Resource Protection did not find any integrity violations.'
in a side note, trying to run the copy of SFC that exists in c:\windows\syswow64\fails with a "windows resource protection could not start repair service " error message. I don't know if this is normal, or if this is a symptom of a problem.