この不具合に遭遇したユーザーは仕方がなく、ログオン時に再度パスワードを入力している人がほとんどです。この不具合について、Microsoftは「認めて」います。しかし、この不具合の原因は現時点で分かっていません。

　一部のユーザーによれば、Windows 10 2004と今回のバージョンである20H2でクッキーが保存されていないか、またはChromeブラウザでログインデータを使用しているのではといった問題を提起しています。また、あるユーザーが発見した原因は、タスク計画のタスクS4U「TASK_LOGON_S4U」が原因ではないかということです。

　この原因かもしれないと言われているタスク「TASK_LOGON_S4U」は、より安全な代替案を提供するのオプションで、ユーザログオンサービス（S4U）を利用して、パスワードを保存することなく、指定したユーザ名でタスクを実行します。

　タスクスケジューラはローカルシステムのアカウント内で動作するため、S4Uのログオンセッションを作成し、ローカルコンピュータ上で本人確認だけでなく、パーソナライズにも使用できるトークンを受け取ることができます。通常、S4Uトークンは識別にのみ適しています」。

　このサービスが原因かどうか調べる場合は、PowerShellで調べることができます。

　PowerShellを管理者権限で起動し、下記のコマンドを入力します。

Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName("LogonType").'#text' -eq "S4U") { $_.TaskName } } } }

PowerShellにタスクが表示されるようになりました。

これでタスクスケジュールを開いてタスクを検索して無効化できるようになりました。

　「これは、UBPM が S4U トークンを作成するために使用する RPC が lsass に保存されている資格情報を削除してしまうことがあるからです」

と発見したユーザーは bugs.chromium でさらに説明しています。

　とりわけ、保存された資格情報 (というかハッシュ) は DPAPI ユーザ暗号化キーを生成するために使用され、それらが削除されると、lsass は空の文字列 (!!) のハッシュのみを使用します。

　マイクロソフトは現在この症状について情報を収集していますが、いくつかのコメントから、この回避策が機能することが確認されています。1つの回答では、タスクを無効にする代わりに、「ユーザーがログオンしているときだけ実行する」という変更が妥協案として提案されていますが、これは回避策としてかなり有効な方法となります。