パソコン修理 ～ リチウムイオン電池パックの再生
2021.03.21
しばらく使用していなかった2010年製造の東芝 Dynabook ノートPCを修理していたところ、最後にリチウムイオン電池パックPABAS173(PA3533U-1BRS、10.8V、1790mAH）の充電をしようとしましたが、充電ランプがすぐに消灯して充電できないことがわかりました。
2010年製の電池パックですので、半分あきらめ気味でしたが、2パックありましたので、なぜ充電できないか分解して確認してみました。すると、電池電圧が6.8Vになっており、過放電防止のため、内部保護回路が電池を切り離しているようでした。これは、電池の劣化（寿命）ではなく、保護回路による充電不良と判断できます。
そこで、分解をしないで電池パックを再生する方法を紹介します。
下記の写真は、内部電池のプラス電極にアクセスするため、穴を開ける位置です。注意深くドリルで1.5mm程度の穴を開けていきます。
次の写真のように、電池パックコネクタ9ピン（または、8ピン）のGNDと穴奥の電極にピン立て、電圧を測定します。今回のパック定格電圧は、10.8Vですので、7.5V以下になっていると、過放電状態になりますので、補充電が必要です。
補充電は、12Vの電源に220Ω程度の直列抵抗を入れた状態で、GNDと内部電池のプラス電極に接続し、1時間程度充電すれば、50mAH程度充電ができると思います。補充電後、念のため電池の電圧が7.5V以上になっていることを確認できれば、ノートPCで充電が可能になります。補充電しても電圧が上がらない場合は、長い休眠期間から目覚めてもらうため、少し放電させた後、再度補充電すると良いようです。
この方法は、東芝の類似電池パックでも使えるのではないかと思いますが、自己責任でお願いします。
2010年製の電池パックですので、半分あきらめ気味でしたが、2パックありましたので、なぜ充電できないか分解して確認してみました。すると、電池電圧が6.8Vになっており、過放電防止のため、内部保護回路が電池を切り離しているようでした。これは、電池の劣化（寿命）ではなく、保護回路による充電不良と判断できます。
そこで、分解をしないで電池パックを再生する方法を紹介します。
下記の写真は、内部電池のプラス電極にアクセスするため、穴を開ける位置です。注意深くドリルで1.5mm程度の穴を開けていきます。
次の写真のように、電池パックコネクタ9ピン（または、8ピン）のGNDと穴奥の電極にピン立て、電圧を測定します。今回のパック定格電圧は、10.8Vですので、7.5V以下になっていると、過放電状態になりますので、補充電が必要です。
補充電は、12Vの電源に220Ω程度の直列抵抗を入れた状態で、GNDと内部電池のプラス電極に接続し、1時間程度充電すれば、50mAH程度充電ができると思います。補充電後、念のため電池の電圧が7.5V以上になっていることを確認できれば、ノートPCで充電が可能になります。補充電しても電圧が上がらない場合は、長い休眠期間から目覚めてもらうため、少し放電させた後、再度補充電すると良いようです。
この方法は、東芝の類似電池パックでも使えるのではないかと思いますが、自己責任でお願いします。
2021.03.21 16:20
| 
PCの不調を復旧する～見過ごされた破損ファイル～
2020.12.20
ほっとしたのもつかの間、12月の月次更新プログラムのWindowsUpdateが自動実行されましたが、なぜかインストール後の更新プログラムを構成で7%まで進行した後、リブートを経て「更新プログラムを構成できませんでした」となりました。エラーコードは、"0xE0001000" でした。PowerShellで"Get-WindowsUpdateLog" を実行して"WindowsUpdate.log" を抽出して確認しましたが、原因につながる詳細なログは、残っていませんでした。
世の中の事例を調べてはみましたが解決策は見つかりませんでしたので、まずは、WindowsUpdateカタログから個別の更新プログラム（kb4592438で検索）をダウンロードし、単独実行して、ログの採取を試みました。ログは、"C:\Windows\Logs\CBS\CbsPersist_2020xxxxxxxx.log" にありました。その内容を注意深く確認したところ、下記のように、"DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]"であることがわかりました。
2020-12-14 11:19:59, Info CBS Perf: Doqe: Install started.
2020-12-14 11:19:59, Info CBS Doqe: [Forward] Installing driver updates, Count 646
2020-12-14 11:19:59, Info CBS Progress: UI message updated. Operation type: Update. Stage: 0 out of 0. Percent progress: 7.
2020-12-14 11:20:01, Info CBS DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Doqe: Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Perf: Doqe: Install ended.
2020-12-14 11:20:01, Info CBS Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Error CBS Shtd: Failed while processing non-critical driver operations queue. [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Shtd: Rolling back KTM, because drivers failed.
このエラーに関するドライバーインストールのログが無いか調べてみると、"C:\Windows\INF\setupapi.dev.log" であることがわかり内容を確認すると、下記のようにinfファイル中のsignatureに問題があるとのエラーでした。対象のファイルを確認すると先頭のバイトが壊れて、正常なinfファイルになっていませんでした。infファイルは、sfcの対象になっていないようで、"Update Sequence Array" の不整合によるfixup処理によりで先頭のバイトが破損した可能性があります。MFTの構造上、1クラスタ内に収まる小さなファイルの場合、発生しやすいと考えられます。
>>> [Install Driver Updates]
>>> Section start 2020/12/10 15:41:19.614
cmd: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.680_none_e72768c3263f99bc\TiWorker.exe -Embedding
sto: Image State = Specialized
sto: Image Architecture = amd64
sto: Image OS Version = 10.0.19042
sto: Image Product Type = WinNT
sto: Transaction = CbsDriversAndPrimitives
sto: Driver Updates = 646
! inf: Unable to load INF: 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf'(e0000100)
! inf: Error 0xe0000100: The style of the INF is different than what was requested.
!!! inf: Invalid INF 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf', must contain [Version] section and have signature "$Windows NT$". Code = 1001
!!! sto: Failed to get version info for driver update 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf'. Error = 0xE0000100
<<< Section end 2020/12/10 15:41:22.020
<<< [Exit status: FAILURE(0xe0000100)]
前記で使用したmountされているWindowsイメージから同じファイルを見つけ、前記の手順で上書き復元をしたところ、無事更新プログラムが正常に実行できました。
やっとPCの不調を復旧できたようです。
同じようなWindowsUpadeトラブル事例を検索してみた感想では、ログ解析方法が明らかにされていないのか、原因の特定が難しいのか、効果があるかもしれない対策方法を列挙したり、自動修復プログラムを紹介したりすることが散見されていました。当たるも八卦当たらぬも八卦状態です。パソコンメーカーのサポートでも同じレベルでした。特に日本のマイクロソフトのサポート情報は、エラーコードに対応した対策に言及せず、うまくいった事例を紹介しているだけが多いようで、役に立たないことが多いと感じました。米国のマイクロソフトのサポート情報ほうが有用な感じでした。
WindowsUpadeトラブルは様々な要因で頻発する傾向があり、マイクロソフトがエラーコードの意味やそのエラーコードに対応した対策を公開するか、修復可能範囲を広げるDISM等の機能強化を提供してくれたら多くのユーザが助かるかと感じたのは、私だけではないと思います。マイクロソフトのサポートが大変になるので、ユーザがあまりやりたくない新規再インストールに仕向けようとしているのではと、勘繰りたくもなります。
いずれにしても、今後はバックアップを頻繁に行いたいと思います。ログの解析方法など、参考にしていただければと思います。
世の中の事例を調べてはみましたが解決策は見つかりませんでしたので、まずは、WindowsUpdateカタログから個別の更新プログラム（kb4592438で検索）をダウンロードし、単独実行して、ログの採取を試みました。ログは、"C:\Windows\Logs\CBS\CbsPersist_2020xxxxxxxx.log" にありました。その内容を注意深く確認したところ、下記のように、"DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]"であることがわかりました。
2020-12-14 11:19:59, Info CBS Perf: Doqe: Install started.
2020-12-14 11:19:59, Info CBS Doqe: [Forward] Installing driver updates, Count 646
2020-12-14 11:19:59, Info CBS Progress: UI message updated. Operation type: Update. Stage: 0 out of 0. Percent progress: 7.
2020-12-14 11:20:01, Info CBS DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Doqe: Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Perf: Doqe: Install ended.
2020-12-14 11:20:01, Info CBS Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Error CBS Shtd: Failed while processing non-critical driver operations queue. [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Shtd: Rolling back KTM, because drivers failed.
このエラーに関するドライバーインストールのログが無いか調べてみると、"C:\Windows\INF\setupapi.dev.log" であることがわかり内容を確認すると、下記のようにinfファイル中のsignatureに問題があるとのエラーでした。対象のファイルを確認すると先頭のバイトが壊れて、正常なinfファイルになっていませんでした。infファイルは、sfcの対象になっていないようで、"Update Sequence Array" の不整合によるfixup処理によりで先頭のバイトが破損した可能性があります。MFTの構造上、1クラスタ内に収まる小さなファイルの場合、発生しやすいと考えられます。
>>> [Install Driver Updates]
>>> Section start 2020/12/10 15:41:19.614
cmd: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.680_none_e72768c3263f99bc\TiWorker.exe -Embedding
sto: Image State = Specialized
sto: Image Architecture = amd64
sto: Image OS Version = 10.0.19042
sto: Image Product Type = WinNT
sto: Transaction = CbsDriversAndPrimitives
sto: Driver Updates = 646
! inf: Unable to load INF: 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf'(e0000100)
! inf: Error 0xe0000100: The style of the INF is different than what was requested.
!!! inf: Invalid INF 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf', must contain [Version] section and have signature "$Windows NT$". Code = 1001
!!! sto: Failed to get version info for driver update 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kdnic.inf'. Error = 0xE0000100
<<< Section end 2020/12/10 15:41:22.020
<<< [Exit status: FAILURE(0xe0000100)]
前記で使用したmountされているWindowsイメージから同じファイルを見つけ、前記の手順で上書き復元をしたところ、無事更新プログラムが正常に実行できました。
やっとPCの不調を復旧できたようです。
同じようなWindowsUpadeトラブル事例を検索してみた感想では、ログ解析方法が明らかにされていないのか、原因の特定が難しいのか、効果があるかもしれない対策方法を列挙したり、自動修復プログラムを紹介したりすることが散見されていました。当たるも八卦当たらぬも八卦状態です。パソコンメーカーのサポートでも同じレベルでした。特に日本のマイクロソフトのサポート情報は、エラーコードに対応した対策に言及せず、うまくいった事例を紹介しているだけが多いようで、役に立たないことが多いと感じました。米国のマイクロソフトのサポート情報ほうが有用な感じでした。
WindowsUpadeトラブルは様々な要因で頻発する傾向があり、マイクロソフトがエラーコードの意味やそのエラーコードに対応した対策を公開するか、修復可能範囲を広げるDISM等の機能強化を提供してくれたら多くのユーザが助かるかと感じたのは、私だけではないと思います。マイクロソフトのサポートが大変になるので、ユーザがあまりやりたくない新規再インストールに仕向けようとしているのではと、勘繰りたくもなります。
いずれにしても、今後はバックアップを頻繁に行いたいと思います。ログの解析方法など、参考にしていただければと思います。
PCの不調を復旧する～ほんとうの修復（復元）～
2020.12.19
ほんとうの修復（復元）のため、破損したパスを特定し、必要なファイルを上書きします。
①孤立ファイルの復元
まず、found.xxxディレクトリ内のファイル名および、バージョン情報からどのファイルパスから切り離されたかを特定します。アプリケーションの一部なら、アプリケーションを再インストールすれば、復元できます。幸いにもバックアップがあれば、切り離された部分の上位から上書きすれば、復元できます。また、アプリケーションの一部であれば、アンインストールや再インストールで、問題を解消できます。
②「破損した基本ファイル構造が見つかりました」の復元
ファイル名が記載されていると思いますので、前記と同様に、ファイルパスを特定後、上書きにより復元が可能になります。
③「ファイル *** のインデックス $I30 で、エラーが検出されました。」の復元
ファイル名が記載されていれば、前記と同様に、ファイルパスから上書きにより復元が可能になります。ファイル番号の場合は、DiskEditというツールで、ファイル番号からファイルパスに変換できます。「diskedit microsoft」の検索で、調べてみてください。
④「ディレクトリ "\***\***" のインデックス "$I30" に不要なリンク ($FILE_NAME: "******") が見つかりました」
これは、WindowsがDLLなどのバージョン管理のために、ハードリンクを多用しているために発生しやすいようです。今回は、ファイルシステムが損傷している時に、WindowsUpdateが走ってしまったので、多発したようです。PCにトラブルが発生した場合は、WindowsUpdateを停止させておくと無難なようです。いずれにしても、次の段階「DISMおよびsfcによる復元」で対応できると思います。
⑤「ブロック 0x** の USA 確認値 0x** が正しくありません。」
これは、NTFSのMFTと呼ばれる属性情報内で、"Update Sequence Array"値の不一致が見つかった場合です。今回のようなPCの不調のように、何らかの問題で属性情報の更新が中断してしまったようです。この不整合が見つかると、ファイル本体のfixupという操作が正しく行われない場合、ファイルクラスタ内の特定の1バイトが誤った内容になることがあります。対象となるパス名を特定することはできますが、非常に手間がかかりますので、「DISMおよびsfcによる復元」で解消できる期待することにします。この段階では、何もしませんが、Active@ Disk EditorというNTFSの内部を参照できるツールとNTFSの構造を理解すると、特定ができるようです。
⑥DISMおよびsfcによる復元
DISMは、Windowsのインストールイメージ作成のため、パッケージの追加・更新・削除ができる非常に多機能なツールです。稼動しているWindowsにたいしても、同様な機能を持っていますので、WindowsUpdateの一部として動作するようです。さらに、下記のようにインストールされているパッケージが破損していれば、復元してくれる便利な機能があります。
Dism /Online /Cleanup-image /RestoreHealth
期待して実行してみましたが、実行結果は「エラー: 0x800f081f ソースファイルが見つかりませんでした。」で復元できませんでした。いくつかのファイルは、復元できたようですが、復元できないファイルがあるようです。このエラーは、WindowsUpdateに対象のファイルが見つからなかったようです。このエラーが発生している事例が結構多いようです。
下記のようにsfcで、Windows本体以外のファイルの復元を試みましたが、これまた、復元できないファイルが残っているようです。
sfc /scannow
ここで、アプリケーションを保持しながらWindowsの上書きインストールを試してみましたが、途中で、何らかの問題があるようで、インストールが中断・ロールバックされてしまいました。
そのため、破損ファイルをできるだけ上書きするために"Windows10 20H2"の更新プログラムを実行したところ、正常に更新されました。
期待しながらDISMとsfcを実行しましたが、やはり破損ファイルが残っていました。ここまでは、自動的なツーツに頼ってきましたが、ここからは、手動操作しかないので、詳細な原因を調べていくしかありません。そこで、"C:\Windows\Logs\DISM\dism.log" と、"C:\Windows\Logs\CBS\CBS.log" を注意深く確認したところ、"Cannot repair"と記載された部分が破損しているが復元できなかったことがわかります。
多くの破損ファイルは、古いバージョンのパッケージに含まれているようで、"C:\Windows\WinSxS" 配下にありました。WindowsUpdateへのアクセスはありましたが、最新のパッケージ情報に基づいたWindowsイメージからしか修復ができないためか、ソースファイルが見つかりませんでしたになっているのではないでしょうか。古いバージョンのファイルは、復元が効かないようです。WindowsUpdateのバージョンは、すでに月次更新が適用されているのではないでしょうか。
そこで、DISMのメッセージ「機能の復元に必要なファイルの場所を指定するには、”Source” オプションを使用してください。ソースの場所 の指定の詳細について は、http://go.microsoft.com/fwlink/?LinkId=243077 を参照してください。」に従い/Sourceオプションを使用するため、rufusを使用してWindowsインストールイメージをUSBメモリに保存しました。各ビルド毎のWindowsインストールイメージが選べる点が優れています。今回は、破損したファイルのビルド番号から"Windows10 20H2"でした。
下記のようにDISMで、ローカルドライブにWindowsイメージを展開し、mount状態にします。mountと言っても、所有者をTrustedinstallerにして、容易な改ざんを防いでいると思われます。"index:3"は、Windows10 Professinalを指定しています。（それぞれのパスは、環境により変わりますのでご注意ください）
Dism /Mount-Image /ImageFile:H:\sources\install.wim /index:3 /MountDir:G:\dism\mount
次のように復元を試みましたが、依然「エラー: 0x800f081f ソースファイルが見つかりませんでした。」となりましたが、いくつかの破損したファイルは修復できたような感じです。
Dism /Online /Cleanup-Image /RestoreHealth /Source:G:\dism\mount /LimitAccess
ディレクトリ名からファイルのビルド番号がはっきりしていますので、Windowsの更新履歴から、WindowsUpdateカタログの番号を特定し、対象の更新プログラムを見つけダウンロードして再インストールを試みましたが、すでにインストール済になり、再インストールができませんでした。これは、パッケージの状態がパーマネント（更新プログラムがクリーンアップされている場合）であると、修復ができないのではないかと思われます。
最終手段として、破損しているファイルを手作業で上書きすることにしました。ところが、問題は、特定できたビルド番号のDLLなどの更新ファイルがWindowsUpdateカタログから入手した更新プログラムから直接取り出せないことでした。再インストールもできませんので、DISMのイメージ管理機能を使用し、mountできているWindows10インストールイメージに、更新プログラムを適用してDLLなどのファイルの実体を取り出すことにしました。C:\mountに更新プログラムを配置した場合、下記のようなコマンドとなります。
Dism /image:G:\dism\mount /add-package /PackagePath:C:\mount
Windows10インストールイメージ、"G:\dism\mount\Windows\WinSxS" から特定のパッケージのDLLなど、対象ファイルを上書きすることにしました。事前準備として、上書きが必要なファイルの所有者を変更し、更にフルコントロールの権限を付与しておく必要があります。上書き後は、元に戻しておく必要があります。残った破損ファイルが2つのファイルだけでしたので、それほどの手間ではありませんでした。
再度、DISMで修復確認を行うと、100%完了状態となりました。
次は、sfcで残ったファイルを復元することにしました。"C:\Windows\Logs\CBS\CBS.log" 内の"Cannot repair"の破損したファイルが対象になります。DISM時の復元手順と同じように上書きし復元しました。
また、"Visual C++ 2008 Redistribute - X64"のDLLが破損しているとのことで、これは、アンインストールし、改めて最新版をインストールすることで、破損部分を破棄できました。
以上のような復元にチャレンジした結果、CHKSDK、DISM、sfcをすべてクリアできました。まずは、ほっとしました。
①孤立ファイルの復元
まず、found.xxxディレクトリ内のファイル名および、バージョン情報からどのファイルパスから切り離されたかを特定します。アプリケーションの一部なら、アプリケーションを再インストールすれば、復元できます。幸いにもバックアップがあれば、切り離された部分の上位から上書きすれば、復元できます。また、アプリケーションの一部であれば、アンインストールや再インストールで、問題を解消できます。
②「破損した基本ファイル構造が見つかりました」の復元
ファイル名が記載されていると思いますので、前記と同様に、ファイルパスを特定後、上書きにより復元が可能になります。
③「ファイル *** のインデックス $I30 で、エラーが検出されました。」の復元
ファイル名が記載されていれば、前記と同様に、ファイルパスから上書きにより復元が可能になります。ファイル番号の場合は、DiskEditというツールで、ファイル番号からファイルパスに変換できます。「diskedit microsoft」の検索で、調べてみてください。
④「ディレクトリ "\***\***" のインデックス "$I30" に不要なリンク ($FILE_NAME: "******") が見つかりました」
これは、WindowsがDLLなどのバージョン管理のために、ハードリンクを多用しているために発生しやすいようです。今回は、ファイルシステムが損傷している時に、WindowsUpdateが走ってしまったので、多発したようです。PCにトラブルが発生した場合は、WindowsUpdateを停止させておくと無難なようです。いずれにしても、次の段階「DISMおよびsfcによる復元」で対応できると思います。
⑤「ブロック 0x** の USA 確認値 0x** が正しくありません。」
これは、NTFSのMFTと呼ばれる属性情報内で、"Update Sequence Array"値の不一致が見つかった場合です。今回のようなPCの不調のように、何らかの問題で属性情報の更新が中断してしまったようです。この不整合が見つかると、ファイル本体のfixupという操作が正しく行われない場合、ファイルクラスタ内の特定の1バイトが誤った内容になることがあります。対象となるパス名を特定することはできますが、非常に手間がかかりますので、「DISMおよびsfcによる復元」で解消できる期待することにします。この段階では、何もしませんが、Active@ Disk EditorというNTFSの内部を参照できるツールとNTFSの構造を理解すると、特定ができるようです。
⑥DISMおよびsfcによる復元
DISMは、Windowsのインストールイメージ作成のため、パッケージの追加・更新・削除ができる非常に多機能なツールです。稼動しているWindowsにたいしても、同様な機能を持っていますので、WindowsUpdateの一部として動作するようです。さらに、下記のようにインストールされているパッケージが破損していれば、復元してくれる便利な機能があります。
Dism /Online /Cleanup-image /RestoreHealth
期待して実行してみましたが、実行結果は「エラー: 0x800f081f ソースファイルが見つかりませんでした。」で復元できませんでした。いくつかのファイルは、復元できたようですが、復元できないファイルがあるようです。このエラーは、WindowsUpdateに対象のファイルが見つからなかったようです。このエラーが発生している事例が結構多いようです。
下記のようにsfcで、Windows本体以外のファイルの復元を試みましたが、これまた、復元できないファイルが残っているようです。
sfc /scannow
ここで、アプリケーションを保持しながらWindowsの上書きインストールを試してみましたが、途中で、何らかの問題があるようで、インストールが中断・ロールバックされてしまいました。
そのため、破損ファイルをできるだけ上書きするために"Windows10 20H2"の更新プログラムを実行したところ、正常に更新されました。
期待しながらDISMとsfcを実行しましたが、やはり破損ファイルが残っていました。ここまでは、自動的なツーツに頼ってきましたが、ここからは、手動操作しかないので、詳細な原因を調べていくしかありません。そこで、"C:\Windows\Logs\DISM\dism.log" と、"C:\Windows\Logs\CBS\CBS.log" を注意深く確認したところ、"Cannot repair"と記載された部分が破損しているが復元できなかったことがわかります。
多くの破損ファイルは、古いバージョンのパッケージに含まれているようで、"C:\Windows\WinSxS" 配下にありました。WindowsUpdateへのアクセスはありましたが、最新のパッケージ情報に基づいたWindowsイメージからしか修復ができないためか、ソースファイルが見つかりませんでしたになっているのではないでしょうか。古いバージョンのファイルは、復元が効かないようです。WindowsUpdateのバージョンは、すでに月次更新が適用されているのではないでしょうか。
そこで、DISMのメッセージ「機能の復元に必要なファイルの場所を指定するには、”Source” オプションを使用してください。ソースの場所 の指定の詳細について は、http://go.microsoft.com/fwlink/?LinkId=243077 を参照してください。」に従い/Sourceオプションを使用するため、rufusを使用してWindowsインストールイメージをUSBメモリに保存しました。各ビルド毎のWindowsインストールイメージが選べる点が優れています。今回は、破損したファイルのビルド番号から"Windows10 20H2"でした。
下記のようにDISMで、ローカルドライブにWindowsイメージを展開し、mount状態にします。mountと言っても、所有者をTrustedinstallerにして、容易な改ざんを防いでいると思われます。"index:3"は、Windows10 Professinalを指定しています。（それぞれのパスは、環境により変わりますのでご注意ください）
Dism /Mount-Image /ImageFile:H:\sources\install.wim /index:3 /MountDir:G:\dism\mount
次のように復元を試みましたが、依然「エラー: 0x800f081f ソースファイルが見つかりませんでした。」となりましたが、いくつかの破損したファイルは修復できたような感じです。
Dism /Online /Cleanup-Image /RestoreHealth /Source:G:\dism\mount /LimitAccess
ディレクトリ名からファイルのビルド番号がはっきりしていますので、Windowsの更新履歴から、WindowsUpdateカタログの番号を特定し、対象の更新プログラムを見つけダウンロードして再インストールを試みましたが、すでにインストール済になり、再インストールができませんでした。これは、パッケージの状態がパーマネント（更新プログラムがクリーンアップされている場合）であると、修復ができないのではないかと思われます。
最終手段として、破損しているファイルを手作業で上書きすることにしました。ところが、問題は、特定できたビルド番号のDLLなどの更新ファイルがWindowsUpdateカタログから入手した更新プログラムから直接取り出せないことでした。再インストールもできませんので、DISMのイメージ管理機能を使用し、mountできているWindows10インストールイメージに、更新プログラムを適用してDLLなどのファイルの実体を取り出すことにしました。C:\mountに更新プログラムを配置した場合、下記のようなコマンドとなります。
Dism /image:G:\dism\mount /add-package /PackagePath:C:\mount
Windows10インストールイメージ、"G:\dism\mount\Windows\WinSxS" から特定のパッケージのDLLなど、対象ファイルを上書きすることにしました。事前準備として、上書きが必要なファイルの所有者を変更し、更にフルコントロールの権限を付与しておく必要があります。上書き後は、元に戻しておく必要があります。残った破損ファイルが2つのファイルだけでしたので、それほどの手間ではありませんでした。
再度、DISMで修復確認を行うと、100%完了状態となりました。
次は、sfcで残ったファイルを復元することにしました。"C:\Windows\Logs\CBS\CBS.log" 内の"Cannot repair"の破損したファイルが対象になります。DISM時の復元手順と同じように上書きし復元しました。
また、"Visual C++ 2008 Redistribute - X64"のDLLが破損しているとのことで、これは、アンインストールし、改めて最新版をインストールすることで、破損部分を破棄できました。
以上のような復元にチャレンジした結果、CHKSDK、DISM、sfcをすべてクリアできました。まずは、ほっとしました。
