WindowsのCドライブ直下に、DumpStack.log や DumpStack.log.tmp という見慣れないファイルが突然現れると、「ウイルスではないか」「削除してよいのか」「バックアップが失敗する原因ではないか」といった不安が生じやすいものです。特に、ファイル名に dump（ダンプ）という語が含まれているため、クラッシュや障害を連想して心配になる方も少なくありません。
本記事では、DumpStack.log.tmpの位置づけを整理したうえで、削除してよい条件と削除を避けるべき条件を明確にし、さらに「削除できない」「バックアップが失敗する」といった典型的な困りごとに対して、再現しやすい手順で対処方法を解説いたします。なお、レジストリ編集を伴う可能性があるため、手順の安全性（復元策・注意点）も重視して説明いたします。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
DumpStack.log.tmpとは何か
DumpStack.logとDumpStack.log.tmpの違い
まず押さえるべき点は、DumpStack.log と DumpStack.log.tmp は“ユーザーが自分で作成する用途のファイル”ではなく、Windows側の内部処理の結果として生成される場合がある、ということです。
DumpStack.log
主にログファイルとして扱われ、Windowsの障害対応やクラッシュ関連の処理と関係して作成されることがあります。環境によっては、サイズが小さいまま残ることもあれば、増減することもあります。DumpStack.log.tmp
一時ファイル（tmp）として見えることが多く、状態によっては「使用中」と表示され削除できない場合があります。これは、ファイルが破損しているというより、Windowsの処理や保護機構の都合でロックされているケースが典型です。
「log」と「tmp」の見た目だけで役割を完全に断定することはできませんが、一般には log＝記録、tmp＝一時的な作業領域の意味合いで理解すると、過度に不安になる必要はありません。
また、似た言葉として メモリダンプ（例：MEMORY.DMP） がありますが、これはクラッシュ時のメモリ内容を保存する大きなファイルであり、DumpStack.log.tmpとは別物です。混同しないことが重要です。
作成される主なきっかけ
DumpStack.log.tmpが生成される“きっかけ”として、よく見られるのは次のような状況です。
ブルースクリーン（BSOD） などのクラッシュが発生した
強制終了、フリーズ後の電源断、バッテリー切れなどで正常終了できなかった
スリープ・休止状態・高速スタートアップ周辺で状態遷移が不安定になった
大型アップデート直後に内部処理が走り、ログや状態を残す必要が生じた
ストレージ逼迫、ドライバー不整合、周辺機器の影響で不安定になった
重要なのは、「DumpStack.log.tmpがある＝必ずクラッシュした」という単純な話ではなく、クラッシュ“以外”の不安定要因でも生成され得るという点です。したがって、ファイルの有無だけで重大障害を確定させるのではなく、PCの挙動（突然の再起動、アプリの強制終了、フリーズ頻度、エラー通知）と合わせて判断することが適切です。
ウイルスとの見分け方の考え方
結論として、DumpStack.log.tmpという名前だけでウイルスと断定することはできません。ただし不安を減らすために、次の観点で“合理的な確認”を行うことを推奨いたします。
場所（パス）を確認する
典型はC:\DumpStack.logやC:\DumpStack.log.tmpのように、OSドライブ直下です。これ自体は珍しくありません。
一方で、ユーザーのダウンロードフォルダや、見覚えのないアプリフォルダ配下に同名ファイルが大量にある場合は、別の要因の可能性もあります。ファイルの作成日時・更新日時の前後関係を見る
直近の強制終了や更新とタイミングが一致しているなら、OS起因の可能性が高まります。PC全体の異常兆候を見る
常駐プロセスが不審、広告が急増、ブラウザの設定が勝手に変わる、CPU使用率が不自然、などの兆候がある場合は、ファイル単体ではなく“端末全体”としてセキュリティ確認が必要です。ウイルス対策でスキャンする
これは最も確実で、心理的負担の軽減にもつながります。ファイル名で悩み続けるより、スキャンで白黒をはっきりさせる方が安全です。
DumpStack.log.tmpは削除してよいか
削除してよい条件
DumpStack.log.tmpは、状況によっては削除しても致命的な問題が起きにくいことがあります。一般的に、次の条件を満たす場合は削除を検討して差し支えないケースが多いです。
PCが安定して動作している（突然の再起動や頻繁なフリーズがない）
容量確保が目的で、他の安全な削減策（不要ファイル削除、ストレージ整理）を行っても足りない
バックアップ失敗の原因になっている可能性が高い（エラーメッセージやログに明示されるなど）
企業PCなどで「障害解析のためにログを保持する」運用ではない
直近でトラブルシューティングをしており、ログ保持の必要性を理解したうえで削除する
ここで大切なのは、「削除してよいか」はファイルの性質だけで決まるのではなく、利用者の状況（安定性、目的、運用ルール）で決まるという点です。
削除を急がない方がよい条件
一方で、次に該当する場合は削除を急がない方が安全です。
直近でBSODや強制再起動が発生した
PCが不安定で、原因調査の途中である
メーカーサポートや情シスに相談予定で、ログ提出を求められる可能性がある
何を削除したかの管理が難しい（複数台管理、業務端末など）
このような局面では、ログや関連情報が“原因究明の糸口”になる場合があります。ログを消してしまうと、後から「いつ・どのタイミングで・何が起きたか」を説明しにくくなるため、結果的に解決が遅れることがあります。
削除しても再作成されるケース
DumpStack.log.tmpは、削除できたとしても再作成されることがあります。再作成される背景としては、主に以下が考えられます。
PCの不安定さが解消されていない（フリーズ・強制終了が続いている）
Windows内部のログ取得が同様の条件で動作する
更新やドライバー変更により、状態遷移の負担が増えている
ストレージ空き容量が少なく、内部処理が失敗しやすい
このため、「削除できたのにまた出てくる」という場合は、削除作業よりも、再発条件を潰す（安定化する）方向へ切り替えることが合理的です。
DumpStack.log.tmpを安全に削除する手順
削除前チェックリスト
削除作業そのものは難しくありませんが、状況によってはレジストリ編集や再起動など、影響範囲の大きい操作が必要になります。最低限、次のチェックを行ってください。
重要データのバックアップがある（クラウド、外付け、NAS等）
可能なら復元ポイントを作成済み（戻せる状態を確保）
管理者権限のあるアカウントで作業する
直近のBSOD・強制終了・フリーズの有無を把握する
企業PCの場合、社内ルールに抵触しないことを確認する
特に「復元ポイント」は、“最悪のケースの保険”になります。レジストリ編集に進む可能性がある場合は、必ず用意しておくことを推奨いたします。
まず試す手順
最初は、リスクが低く失敗しにくい順に進めます。
再起動する
シャットダウン→起動ではなく、「再起動」を推奨いたします。再起動はWindows内部の状態を整理しやすく、ファイルロックが解除されることがあります。管理者権限で削除を試す
エクスプローラーから削除できない場合でも、管理者権限のコマンドプロンプト（またはPowerShell）で削除できることがあります。
ただし、コマンド操作に不慣れな場合は無理をせず、まずは再起動と権限の確認を優先してください。.logと.tmpを分けて確認する
DumpStack.logは削除できても、DumpStack.log.tmpだけが削除できない、というケースがあります。これは異常ではなく、tmpがロックされているだけの可能性があります。セーフモードの検討（必要な場合のみ）
どうしても削除できない場合、セーフモードでファイルロックの影響が減ることがあります。ただし、セーフモードは手順が増えるため、次項の設定変更を検討する前に“最後の選択肢”として位置づけるのがよいでしょう。
EnableLogFileを0にする手順
DumpStack.log.tmpが削除できない場合、関連する設定として CrashControl配下のEnableLogFile が言及されることがあります。ここで注意すべき点は、これは単なる「削除テクニック」ではなく、ログ取得の挙動に関わる可能性がある設定だということです。したがって、以下を前提として進めてください。
復元ポイントを作成してから実施する
企業端末や保守契約端末では、勝手に変更しない
変更後に挙動が変わった場合、元に戻せるように記録しておく
手順（一般的な流れ）
Win + Rを押し、regeditを入力してレジストリエディターを起動します。次のキーへ移動します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl右側の一覧で
EnableLogFileを探します。EnableLogFileをダブルクリックし、値を 0 に設定します。レジストリエディターを閉じ、PCを再起動します。
再起動後、
C:\DumpStack.log.tmpの削除を試します。
実務上の注意点
EnableLogFileが存在しない場合があります。この場合は、環境差・バージョン差の可能性があり、安易な新規作成は推奨いたしません（作成してよいかは運用次第です）。値を変更しても必ず削除できるとは限りません。ファイルロックやバックアップ機構、セキュリティ設定など、他要因が関与する可能性があります。
元に戻す手順とリスク対策
設定を変更した場合は、元に戻す手順も必ず理解しておく必要があります。
EnableLogFileを 1 に戻す（または、変更前の値に戻す）変更前の状態が不明な場合は、復元ポイントで戻す
企業PCでは、元に戻す前に情シスへ共有し、判断を仰ぐ
また、レジストリ変更後に「クラッシュログが取りにくくなる」「障害解析に必要な情報が欠落する」可能性があるため、安定性に不安がある端末ほど、変更は慎重にすることを推奨いたします。
DumpStack.log.tmpが原因のトラブル対処
バックアップが失敗する場合の分岐
DumpStack.log.tmpは、バックアップの方式によっては“失敗のトリガーとして目立つ”ことがあります。特に、次のような状況が典型です。
バックアップ対象にOSドライブ直下が含まれており、DumpStack.log.tmpがロックされる
バックアップ時に「読み取りできないファイル」があると処理が中断される方式である
VSS（ボリュームシャドウコピー）や権限周りの問題が連鎖し、特定ファイルが原因のように見える
ここでは「DumpStack.log.tmpが悪い」と決め打ちせず、バックアップ方式ごとに分けて考えることが重要です。
ファイル単位のバックアップ（例：ファイル履歴、同期系）
失敗ログに対象ファイルが明示されることが多い一方で、実際には権限やロックが原因になりやすいです。除外設定が可能な方式なら、除外で回避できる場合もあります。システムイメージ系（OS領域を丸ごと扱う）
除外の自由度が低く、単一ファイルを除外して解決するというより、VSS・容量・ディスク状態・システム整合性の問題が潜んでいることが多いです。
したがって、バックアップ失敗時は次を順番に確認すると切り分けが進みます。
バックアップ方式（ファイル単位か、イメージ系か）
エラーメッセージやログで、ファイル名が“原因”として明示されているか
対象ファイルがロックされているだけか、他にも読み取り不能があるか
ディスクの空き容量、権限、VSSの状態、システム整合性に問題がないか
「DumpStack.log.tmpを消せば終わる」ケースもありますが、根本が別にある場合、再発や別ファイルでの失敗につながります。焦らず“バックアップの仕組み”として見るのが確実です。
容量が増える場合の確認点
DumpStack.log.tmp自体のサイズが大きいこともありますが、容量問題では“関連ファイル”が原因になっているケースが多々あります。併せて次を確認してください。
C:\Windows\MEMORY.DMPやミニダンプ（C:\Windows\Minidump\）が増えていないかpagefile.sys（ページファイル）が極端に大きく設定されていないかhiberfil.sys（休止状態ファイル）が有効になっており容量を取っていないかWindows Updateの一時ファイルや配信最適化キャッシュが溜まっていないか
ゴミ箱、ダウンロード、不要な動画・重複写真が増えていないか
容量圧迫の解決は、「怪しいファイルだけ消す」よりも、安全に削除できる領域を体系的に削減する方が事故を避けられます。DumpStack.log.tmpの削除にこだわりすぎず、全体最適で考えることが重要です。
BSODや強制終了が疑われる場合の確認点
DumpStack.log.tmpが繰り返し生成される場合、端末が不安定になっている可能性があります。この場合は、ファイル削除よりも次の確認を優先してください。
イベントビューアーで「重大」「エラー」が継続していないか
ドライバー更新やWindows更新の直後から不安定になっていないか
周辺機器（USBハブ、外付けSSD、ドッキングステーション等）追加後から不調が出ていないか
ストレージの空き容量が逼迫していないか（更新失敗やフリーズの原因になります）
メモリ増設やXMP設定変更など、構成変更が直近にないか
特に、突然の再起動やフリーズが頻発する場合、ストレージ・メモリ・電源・ドライバーが関与している可能性があります。DumpStack.log.tmpはあくまで“結果として見えるもの”であり、根本原因を解消することが最重要です。
DumpStack.log.tmpを増やさないための予防策
Windows更新とドライバーの基本
DumpStack.log.tmpが増える背景に「不安定な状態」があるなら、まずは安定化の基本を徹底することが有効です。
Windows Updateを適用したら、再起動を後回しにしない
GPU、チップセット、ストレージ系（NVMe/IRST等）のドライバーは、メーカーの正規手順で更新する
不具合が出た直後に更新したものがある場合、更新の巻き戻し（復元）も検討する
常駐ソフト（セキュリティ、最適化系、バックアップ系）が競合していないか確認する
「更新は怖い」という印象を持つ方もいらっしゃいますが、更新を長期で止めると、逆に不具合や互換性問題が解消されないまま残り、結果的に不安定要因が増えることがあります。計画的に適用し、適用後の再起動まで含めて“更新完了”と捉えることが重要です。
ストレージとページファイルの基本
ストレージ（特にCドライブ）の空き容量が少ないと、Windows内部処理が失敗しやすくなります。以下を基準にするとよいでしょう。
Cドライブの空き容量は、可能なら数十GB単位で余裕を確保する
一時ファイル削除（設定→システム→記憶域）を定期的に実施する
ページファイルは、通常は自動管理のままにする（極端な手動設定は避ける）
ページファイルを無効にしたり極端に小さくしたりすると、挙動が不安定になることがあります。性能改善のつもりが逆効果になる場合もあるため、特別な理由がない限り標準運用を推奨いたします。
再発時の記録の取り方
再発する場合、原因究明を進めるために「記録」が非常に重要です。次をメモしておくと、後から切り分けが容易になります。
発生日時（可能なら分単位）
発生直前に行った操作（更新、ドライバー導入、周辺機器追加、ソフトインストール等）
表示されたエラーコードや停止コード（出た場合）
直後の挙動（再起動した、フリーズした、復旧した、など）
バックアップ失敗であれば、失敗した方式とエラー文言
「何となく不調」から「いつから・何がきっかけで」に変わるだけで、対策の精度が大きく上がります。自己解決が難しい場合でも、サポートへ相談する際の説明が格段にスムーズになります。
DumpStack.log.tmpに関するFAQ
削除したら起動しなくなりますか
通常、DumpStack.log.tmpの削除それ自体が起動不能を直接引き起こす可能性は高くありません。ただし、端末が既に不安定であったり、システム関連の別の問題が存在していたりする場合、削除を契機に別の症状が表面化する可能性はゼロではありません。
不安がある場合は、削除前に復元ポイントを作成し、削除後は再起動して動作確認する流れを推奨いたします。
空ファイルに見えるのはなぜですか
ログファイルや一時ファイルは、メモ帳で開くと内容が表示されないことがあります。また、ログがまだ書き込まれていない、あるいは特定の形式で書かれている場合、視覚的に“空”に見えることがあります。空に見えるから不要、と短絡せず、目的（容量、バックアップ、安定性）に沿って対応を判断してください。
システムイメージ作成では除外できますか
システムイメージ系は「OS領域を丸ごと扱う」性質があるため、特定の単一ファイルだけを自由に除外できない場合があります。除外できない場合は、DumpStack.log.tmp単体ではなく、VSSやストレージ状態、権限、整合性などを含めた切り分けが必要になります。
「除外できる前提」で進めると解決しないことがあるため、方式の仕様として理解しておくことが重要です。
企業PCでの運用注意はありますか
企業PCでは、障害ログの保持、レジストリ変更の禁止、バックアップ方式の指定など、運用ルールが定められていることがあります。特に、レジストリ編集は監査やセキュリティの観点から制限される場合があるため、必ず情シスや管理者の指示を優先してください。自己判断で変更すると、復旧対応が複雑化する可能性があります。
まとめと次に取るべき行動
放置・削除・調査の判断早見表
| 状況 | 推奨アクション |
|---|---|
| 見慣れないがPCは安定している | 放置でも問題になりにくいです。容量やバックアップで困っていなければ経過観察を推奨いたします。 |
| 容量確保が必要で、削除したい | 再起動後に削除を試し、削除前のチェックリスト（復元ポイント等）を実施したうえで対応してください。 |
| DumpStack.log.tmpが削除できない | 再起動と権限確認を優先し、それでも不可なら設定変更（EnableLogFile）を“リスクを理解したうえで”検討してください。 |
| バックアップが失敗する | バックアップ方式（ファイル単位／システムイメージ）で分岐し、除外可否だけでなくVSS・容量・整合性も含めて切り分けてください。 |
| BSODや強制終了が続く | ファイル削除より原因調査を優先してください。イベント、更新履歴、ドライバー、周辺機器、ストレージ状態の確認が重要です。 |
DumpStack.log.tmpは、見た目が不安を誘う一方で、実際にはWindows内部処理の結果として現れることが多いファイルです。したがって、最も安全な進め方は、目的を明確にする（不安解消／容量確保／バックアップ復旧／安定化）→状況に応じて判断することです。
また、Windowsの挙動は更新で変化する可能性があります。削除しても再発する場合は、削除の継続ではなく、再発条件の特定と端末の安定化へ舵を切ることを推奨いたします。
