NordVPN Windows Clientによるシステムドライブへの大量継続Writeバグについて

Last updated at 2026-05-07Posted at 2026-05-05

バージョン情報

問題が再現できたバージョン情報を示しておく．実際には数ヶ月にわたって問題が持続していたと予想されるが，過去バージョンの再現実験ができないため，正確な影響範囲は不明である．

OS: Windows 11 Home (25H2, 26200.8246)
CPU: Intel Core Ultra 7 255HX (x86_64)
DRAM: 32 GiB
SSD: SAMSUNG MZVLC1T0HFLU-00BH1 (1TB)
NordVPN client: version 8.1.2.0 (記事執筆時点の最新版), 8.2.2.0 (2026年5月6日リリース)

問題発生

先日（2026年5月5日），おもむろにCrystalDiskInfoを開いたら，ピコピコと警告音が鳴り，2025年12月28日に使い始めてから4か月しか使っていないはずのシステムドライブのTBW（Total Bytes Written）がとんでもないことになっていた．

一応Samsung Magicianで取得したS.M.A.R.T.のrawデータも置いておこう．TBWはData Units Writtenにユニットサイズ512KBを乗算することで計算できる：

この100TBWという数値は5年使ったPCのSSDよりも状態が悪い．使用時間800時間に対して総書き込み量が100TBである．配信・録画で秒間100MBオーダーの書き込みが長時間継続していれば，数ヶ月でも到達しうる数字ではあるが，このシステムドライブは配信・録画等には使用していない．通常のシステムドライブとしての使用なら数TBWが妥当である．

平均書き込み速度を考えると

$$100\mathrm{[TB]} / (800\mathrm{[h]} \cdot 3600\mathrm{[s/h]}) \approx 35 \mathrm{[MB/s]}$$

のwriteが走り続けていることになる．これは異常である．この調子で書き込みを続けると，1～2年でSamsung SSDの典型的な保証TBW（600-1000TBW程度；本SSDはTBW非公開）を食い尽くしてしまうことになる．（後で分かることだが実際にはもっと短い時間で食い尽くす．）

$$ 600\mathrm{[TB]} / (35\mathrm{[MB/s]} \cdot 86400 \mathrm{[s/day]}) \approx 200 \mathrm{[day]}.$$

原因究明

プロセスの特定

タスクマネージャ taskmgr.exe のディスク書き込みを見ると，システムドライブに対して毎秒30MB程度のwriteが走り続けていることが確認できた．リソースモニタ perfmon.exe にてディスク書き込みをしているプロセスを確認すると，nordvpn-service.exe が以下のファイルに対して毎秒30MB以上（1分間の書き込み量の平均として計算される）の書き込みをしていることを発見する．

C:\ProgramData\NordVPN\Analytics\NordVPN.db ... ファイルサイズ30MB程度
C:\ProgramData\NordVPN\Analytics\NordVPN.db-journal ... 確認忘れ

これはNordVPNというVPNアプリケーションのサービスデーモンである．おそらくアナリティクス記録のためのSQLiteデータベース及びジャーナルファイルだろうと推察された．

このまま放置しておくと1年も経たずにSSDが壊れかねない．しかもシステムドライブなので，正常起動しなくなるおそれがある．

応急処置

とりあえずタスクマネージャより nordvpn-service.exe をkillするとともに，スタートアップサービスを無効化した．PowerShellでやるなら

Set-Service -Name "nordvpn-service" -StartupType Manual

である．

リソースモニタ上にみられた異常書き込みは沈静化したが，これは問題の解決ではない．NordVPNを再起動してみたところ，再び nordvpn-service.exe デーモンが起動し，同様の異常書き込みを開始する．

サポートへの連絡

とりあえず連絡したところ「とりあえず再インストール」の指示を受けたので，とりあえず再インストールしたところ，異常な大量書き込みは止んだかに見えた．

さらなる原因究明

念のためにリソースモニタで再確認すると，nordvpn-service.exe の秒間書き込み量が50–60KBで，先ほどと同じくデータベースとジャーナルに書き込みを続けていることが分かった．これは

$$50\mathrm{[KB/s]} \cdot 86400 \mathrm{[s/day]} = 4.32 \mathrm{[GB/day]}$$

という書き込み量である．当初より1/1000に減っているとはいえ気持ち悪い．というより，なぜただのAnalyticsデータベースにもかかわらず，コンスタントな書き込みがここまで続いているのだろうか？

仮説

データベースファイルのサイズを確認すると

C:\ProgramData\NordVPN\Analytics\NordVPN.db ... 60KB（61,440B）
C:\ProgramData\NordVPN\Analytics\NordVPN.db-journal ... 0B

書き込まれているはずのジャーナルファイルが常に0Bで，データベースサイズが60KBである．ふと気付く：

当初の状態
- データベースサイズ：30MB程度
- 書き込み速度：30MB/s程度
再インストール後の状態
- データベースサイズ：60KB
- 書き込み速度：50–60KB/s

1秒毎にファイル全体をゼロから上書きしているのではないか？

仮説検証

これは nordvpn-service.exe のDisk I/O挙動を正確に解析する必要がある．このようなときはProcess Monitorの出番である．結果は以下の通り．

Rawログファイルは数万行に達するので，本質的なインターバルのみを抽出したものである．Rawログはこのインターバルが3秒毎に繰り返されていることを示していた．

各インターバルにおいて nordvpn-service.exe は次のようなディスクI/Oを行っている：

SQLiteジャーナル C:\ProgramData\NordVPN\Analytics\NordVPN.db-journal への書き込み
- Offset 0から512バイト書き込み
- Offset 512から4バイト書き込み
- Offset 516から4096バイト書き込み
- ……
- END OF FILEまで上記を繰り返し（つまりジャーナル全体をゼロから再構築）
- ファイルバッファをフラッシュ
（SQLiteジャーナル C:\ProgramData\NordVPN\Analytics\NordVPN.db-journal への実際の書き込み）
- Offset 0からファイル全体をSynchronous Paging I/Oで一括書き込み
- Offset 0から12バイト書き込み
- ファイルバッファをフラッシュ
SQLiteデータベース C:\ProgramData\NordVPN\Analytics\NordVPN.db への書き込み
- Offset 0から4096バイト書き込み
- Offset 4096から4096バイト書き込み
- ……
- END OF FILEまで上記を繰り返し（つまりデータベース全体をゼロから書き込み）
- ファイルバッファをフラッシュ
（SQLiteデータベース C:\ProgramData\NordVPN\Analytics\NordVPN.db への実際の書き込み）
- Offset 0からファイル全体をSynchronous Paging I/Oで一括書き込み
- ファイルバッファをフラッシュ
SQLiteジャーナルファイルをクリア
- Offset 0にEOFを書き込み
- アロケーションサイズを0に設定

つまり，3秒毎にデータベース及びジャーナルファイルを丸ごと再書き込みしているということである．しかもジャーナルファイルを毎回クリアしている．

このことは前記の仮説をほぼ裏付けている．

ジャーナルファイルのファイルサイズがファイルプロパティ上は0Bと報告されることは，各インターバル毎にジャーナルファイルを初期化していることによって説明可能である
毎秒の書き込み量がデータベースファイルサイズとほぼ同じオーダーであることは，データベースサイズとジャーナルサイズ（毎回クリアされるが）が大凡同じ位のサイズであることと，データベース及びジャーナルへの全書き込みが3秒毎に1回走ること，よって1秒毎にデータベースサイズの2/3倍相当の書き込みが発生することから説明可能である

Linux Clientのソースファイル

Windows版クライアントは公開されていないが，Linux版はソースコードが公開されており，SQLiteを使っていることが確認できる．

考察

なぜこのような変なディスク書き込みが起きているのだろうか？

確定事項：ジャーナルファイルを毎回生成→削除している (journal_mode=DELETE)
- 根拠： ProcMon ログで -journal ファイルの作成・削除サイクルが各トランザクション毎に観測されることから
- 注意：これはSQLiteのデフォルト設定であり，それ自体異常ではない
高確度の推定事項：データベース全件を変更するようなトランザクションが毎回走っている
- 根拠：ジャーナルサイズがデータベースサイズとほぼ同じであることから，ロールバック対象ページ数 = DB全ページ数となっており，全ページが変更されていると判断できる．具体的な実装パターンとしては以下が考えられる：
  - データベースを毎回全件DELETE→再INSERTしている
  - データベースを毎回全件UPDATEしている
  - ORM (Entity Framework Core等) のChange Trackingが誤動作し，全エンティティがModified扱いで SaveChanges() されている

いずれにせよSQLiteの使い方に何らかの問題がある可能性を示唆する．またそもそも利用統計のアナリティクスをSQLiteで保持する必要があるのかどうかというアーキテクチャレベルの問題もある．

結論

NordVPNのクライアントサービスデーモン nordvpn-service.exe は，アナリティクス用SQLiteデータベース及びジャーナルファイルへの全書き込みを3秒毎に繰り返す挙動をする．

サービスデーモンはNordVPNクライアントアプリケーションを閉じている間も基本的に動作し続ける．NordVPNクライアントにはアナリティクス収集・送信への同意／不同意の設定が存在する．しかし，一部のアナリティクスの収集・送信への同意は必須（同意で固定）となっているため，アナリティクスSQLiteデータベース及びジャーナルファイルへの書き込みを完全に停止することはできない．

したがって，当該不具合を回避するためには，NordVPNの使用を一時的に中止し，サービスデーモンを停止させるとともに，バックグラウンドで起動しないように設定を変更する必要がある．

想定される悪影響

ここで，SQLiteデータベースサイズが利用時間に比例して増加するとすれば（実際，インストール時には60KBだったものが，問題発覚時には30MBに膨れ上がっていた），書き込み速度は $O(t)$ で増加し，総書き込み量は $O(t^2)$ で増加することになる．

つまり，当初の見立てでは，1～2年のうちにSSDのTBWを食い尽くすと予想していたが，実際にはそれより遥かに短い期間で食い尽くす可能性があるということである．書き込み速度はシステムドライブの書き込み速度の上限に達するまで増加し続けるからである．

同じ不具合に遭遇したユーザの書き込みを見つけたので引用する：

私の場合は発見時の速度は30MB/s程度だったが，この方は10倍の300MB/sに達している．もしこのスピードがそのまま続いた場合，20日程度の連続稼働で600TBWに達する．つまり，1日の稼働時間にも依存するが，1–2ヶ月程度で故障域に入りうるということである．

不具合報告

この不具合は，SSDへの過剰な継続書き込みを発生させ，数ヶ月から1年程度でSSDの保証TBWを喰らい尽くし，SSDの故障等を引き起こしてしまう深刻なバグである．これはサポートセンターでは対応が困難であろう．

そこで，影響の深刻さ（ユーザのマシンの物理的故障が起こりうること）と，開発部門へのエスカレーションすべきこととを，前述の証拠類とともにメールにて送付した．すると当日中に開発部門までエスカレーションされたようである．対応の速さに驚いた．

ひとまずの対策

当該不具合は現時点では調査中であり修正されていない．したがって当該不具合が修正されるまでの間は，前述の応急処置を参考に nordvpn-service.exe を起動しないようにするべきである．また，必要に応じて，上記を参考にしてディスクI/Oログなどの証拠を収集しておくことを推奨する．

当該不具合はWindows Clientにて発見したものであるが，Linux，macOS，iOS，iPadOS，Android版などにおいても再現されるかどうかは不明である．もしアナリティクス周りの実装が共通していた場合，同じ不具合が再現される可能性もあるので，当該プラットフォームの技術者は，ぜひ調査してほしい．

追記（2026/05/07）

エスカレーションされたはいいものの，どうもこの不具合を単なる「CPU/メモリなどのリソースの大量消費バグ」と誤解しているのではないかと疑っている．

私は本記事にて特定した原因の推測を ProcMon ログなどの十分なエビデンスとともに提出した．また，本不具合がユーザ端末の破壊を生じさせうるものである以上，不具合が解消されるまで一時的にアンインストールしている旨を付記しておいた．

それに対してサポート担当者は，以下を要求してきた：

やり取りを開始した後にリリースされたバージョンの再インストール
診断ツールを用いた診断ログの提出
メモリダンプの提出
タスクマネージャやリソースモニタにてNordVPNサービス（ThreatProtectionなど含む）のリソース使用率のスクショ

(4)が重要である．本不具合はデータベース全件書き換えトランザクションが3秒毎に発生するために，DBサイズに比例した継続ディスク書き込みがなされるというものである．結果としてDBが大きい場合に大量継続ディスク書き込みが発生しうるが，インストール直後などDBが小さい間はディスク書き込み速度も小さいままである．よってリソース使用率のスクショは何の意味もない．再インストール済みである以上は「高いリソース使用率」のスクショが撮れないことも明らかである．つまりサポート対応者はこれを単にリソース使用率が異常に高くなるバグと誤解していると考えるのが妥当である．

最新バージョンの再インストールについては，それが私の指摘した実装不備を修正したものであれば理解可能である．しかし実際にはそうではない．全く同じI/Oパターンが継続している．私が指摘した部分を修正していないのに，ユーザ端末に故障リスクがあるにもかかわらず，無意味な追試を求めているわけである．（この追試は単に同じもののクリーンインストールを試すのと変わらない．それで改善されないことは既に伝えている．）

メモリダンプについて．何か意図せざる変なこと（メモリリークなど）が起きているならメモリダンプには意味があろうが，本不具合はデータベース設計又は取り扱いの不具合であるので，あまり意味はないだろう．イベントビューアでもエラーは吐いていないので，データベース破損というのも考えにくい．クリーンインストールでも再現されるのだからなおのことである．（メモリダンプの範囲次第ではsensitive dataが含まれる場合がある以上，何でもかんでも不用意に渡すわけにもいかない．）

そして何よりも問題なのはユーザ環境をデバッグ環境代わりに使っていることである．エンジニアリングチームは，自社の開発環境でNordVPN Clientを実際に動作させるなり，自分たちが持っているソースコードを読むなりすれば，不具合の再現もデバッグも可能であるはずだ．それにもかかわらず，そうした不具合再現やデータ収集といったデバッグ作業にユーザを巻き込んでいる．これは単にユーザの時間を不当に奪っているというだけではない．既に再三述べてきた通り，当該不具合はユーザ端末を物理的に故障させうるものであるから，デバッグのためにユーザに追加でリスクを負わせることになっている．

そもそも私の報告によって既に原因は特定されているようなものである．まともなデータベースエンジニアであれば，提出された ProcMon ログを読めば2秒で事情を把握し，ソースコードのどのあたりにバグがあるかのアタリもつけられるはずだ．

追記（2026/05/07）

Linux Clientでも同様の不具合を再現できたためGitHubにIssueを立てた：

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up