> .vs 配下の深いところに sqlite3 に関するフォルダーが存在してました。
.vs 配下に置かれる物については、そういう仕様ですね。

ソース管理システム(ローカル Git リポジトリ、GitHub 、SubVersion など)に対して、
ピリオドで始まるフォルダー(.vs や .svn など)を含めないようご注意ください。


> db.lock               * 常に存在
名前からして、排他処理制御用のファイルかな…?

> storage.ide　　　   * 常に存在 
> storage.ide-shm   x 場合によっては存在
> storage.ide-wal    x 場合によっては存在
ルートにあるものはさておき、上記の sqlite3 フォルダーが生成されている事例は、他にもあるようで。
http://ninagreen.hatenablog.com/entry/2018/10/31/004756
https://stackoverflow.com/questions/45802083/visual-studio-2017-15-3-0-git-changes-include-storage-ide-even-though-vs-in



まず、新規プロジェクトでも再現するかどうかを確認してみてください。

既存の特定プロジェクトのみで発生する事象なら、.sln や .vbproj をメモ帳で開き、
"..\..\..\" などの祖先パスへのアクセスが多用されていないか確認してみてください。
祖先パスへの参照が残ったままで、フォルダー名の変更やファイルの移動を行うことで
フォルダー階層が崩れてしまい、C ドライブのルートに作業フォルダーが
生成されてしまったのかもしれません。


> 6cly0yyOPNcv52xbHVttEsuVTI= という名前はbase64でエンコードされた文字列のように見えますが、
> ためしにデコードしてみるとエラーでした。どうもbase64としては不完全なもののようです。
自分も Base64 を疑いましたが、27 文字という点が不自然ではありますね。
24文字か 28 文字ならまだわかるのですが。

変形 Base64 と仮定して駄目元で復元してみましたが、
何らかの文字列を Base64 変換したものでは無さそうです。


末尾の "=" のパディングが 1 つ漏れているとすれば、
デコード結果は 19 バイト（28 文字 ÷ 4 × 3 － 2) な
　E9-C9-72-D3-2C-8E-3C-D7-2F-E7-6C-5B-1D-5B-6D-12-CB-95-4C
というバイナリだったことになります。

あるいは、先頭の 1 文字が欠けているとすれば、
デコード結果は 20 バイト (28 文字 ÷ 4 × 3 － 1) な
　XY-A7-25-CB-4C-B2-38-F3-5C-BF-9D-B1-6C-75-6D-B4-4B-2E-55-32
になります。（X 部は 0～F のいずれか、Y 部は 37BF のいずれか）



もう一つの可能性として考えたのは、vswhere.exe などで調べることのできる
Visual Studio の instanceId だったのですが、それにしては長すぎますね…。
https://docs.microsoft.com/ja-jp/visualstudio/install/tools-for-managing-visual-studio-instances?view=vs-2019


詳しく知りたい場合には、Process Monitor でファイルアクセスを追跡してみれば、何かわかるかも。
https://docs.microsoft.com/ja-jp/sysinternals/downloads/procmon