PyCharmで npm start 実行時にIDEがサイレントクラッシュした事例と切り分け
こんにちは!Qualitegプロダクト開発部です!
PyCharmの内蔵npmツールで npm start を実行した瞬間、何のエラーメッセージもなくIDEが消える。
再起動してもう一度試すとまた落ちる。ログを見ても手がかりがない——。
今回はこの「サイレントクラッシュ」に遭遇し、原因の絞り込みから回避策の確立まで至った過程を書き残しておきます。同じ現象で困っている方の参考になれば幸いです。
環境
| 項目 | 内容 |
|---|---|
| OS | Windows 10/11 |
| PyCharm | 2026.1(2023.1.6時代から連綿とUpdateをした状態) |
| Python | 3.11.4(venv使用) |
| Node.js | v25.2.1 |
| プロジェクト | Python + Node.js 混合構成 |
上記のとおり、PyCharmは執筆時点の最新版(2026.1)となります。
確認できたこと・推測していること
まず最初に、この記事で述べる内容の確度を整理しておきたいとおもいます
確認できたこと
- npmツール内蔵ターミナル経由でのみクラッシュが再現する(外部ターミナルでは再現しない)
- ConPTYを無効化すると回避できる
- idea.log、JVMクラッシュダンプともに有力な痕跡がない
- インストール先のパスに旧バージョン名(
PyCharm 2023.1.6)が残っている conpty.dllが旧バージョンのパスからロードされている
推測していること
- 上書きアップデートに伴うネイティブコンポーネントの不整合が関与している可能性がある
conpty.dll周辺の互換性問題である可能性が高い- 大量のコンソール出力時にだけ顕在化するネイティブ層の異常と考えられる
conpty.dll の新旧バージョンの差分比較やクラッシュダンプの詳細解析までは行っていないため、根本原因については状況証拠に基づく推測となりますが、
切り分けの結果としてConPTY周辺が原因である可能性は非常に高いと判断しています。
症状の詳細
PyCharmのnpmツール内蔵ターミナルで npm start を実行すると、数秒以内にPyCharmのウィンドウが消えます。タスクバーからも消え、プロセスも終了しています。再現率はほぼ100%でした。
特徴的だったのは以下の点です。
- エラーダイアログが一切表示されない
JetBrains標準のクラッシュ通知も出ません。ウィンドウが文字通り「消える」だけです。 - idea.logにクラッシュの痕跡がない
正常に起動・インデックス完了した後、ログがプツッと途切れています。 - Pythonスクリプトの実行では問題が起きない
Run ConfigurationからPythonを実行する分には安定しています。 - コマンドプロンプトから
npm startしてもPyCharmは落ちない。
外部ターミナルを使えば問題なく動作します。
最後の点が最も重要な切り分けポイントとなります。
ログに何も残らないサイレントクラッシュの難しさ
通常、PyCharm(IntelliJ系IDE)がクラッシュすると、idea.log にJavaレベルの例外が記録されるか、JVMクラッシュダンプ(java_error_in_pycharm_*.log)がユーザーのホームディレクトリに生成されます。
今回はそのどちらにも有用な情報がありませんでした。これはJava層ではなく、もっと低いレイヤー——ネイティブコード層でプロセスが異常終了している可能性を示唆しています。JVMがクラッシュダンプを書く暇もなく終了させられている状態です。
ログに何も残らないため、「何を変えたら再現しなくなるか」を1つずつ試す切り分けテストが唯一の手段でした。
ログの場所について補足
なお、PyCharmのログと設定は別々のディレクトリに保存されています。ログは %LOCALAPPDATA%(AppData\Local)、設定は %APPDATA%(AppData\Roaming)です。ネット上では %APPDATA% としか書かれていないことが多く、Roamingを探して「ない!」となるケースがよくあります。
ログ: %LOCALAPPDATA%\JetBrains\<バージョン>\log\
設定: %APPDATA%\JetBrains\<バージョン>\
一番手軽なのは Help → Show Log in Explorer です。2025年以降のバージョンでは Help → Diagnostic Tools → Special Files and Folders で全ディレクトリのフルパスが一覧表示できるので、こちらも便利です。
idea.log から読み取れた手がかり
クラッシュの瞬間は記録されていませんでしたが、idea.logからはいくつかの間接的な手がかりが得られました。
インストールパスと設定パスの不一致
Djb.vmOptionsFile=C:\Users\ml\AppData\Roaming\JetBrains\PyCharm2026.1\pycharm64.exe.vmoptions
Djna.boot.library.path=C:\Program Files\JetBrains\PyCharm 2023.1.6/lib/jna/amd64
設定ファイルのパスセレクタは PyCharm2026.1 なのに、インストール先は PyCharm 2023.1.6 のままです。
これは、長年の上書きアップデートによって環境の一貫性が崩れていることがわかります。ネイティブバイナリが想定通りに更新されていない可能性を疑う材料になりました。
ConPTYのロード元
Loaded bundled ConPTY from C:\Program Files\JetBrains\PyCharm 2023.1.6\lib\pty4j\win\x86-64\conpty.dll
npmツール内蔵ターミナルが使用する conpty.dll が旧バージョンのパスからロードされています。PyCharm 2026.1が想定するバージョンと一致しているかどうかは確認できていませんが、パスの不自然さは気になる点です。
node_modules の大量ファイル登録
NodeModulesDirectoryManager - Contributed {
allCalculationsDuration: 2263 ms,
allIncludedFileCount: 45078,
allRootsWorkspaceModel: 42960,
...
}
45,078ファイルがインデックス対象として登録されていました。
最初はこれがクラッシュの原因ではないかと疑いましたが、node_modules をExcludedに設定してもクラッシュは解消しませんでした。(実はexcludedにしても、librootにしてるとインデックスしちゃう事象がありますので、excludedの効能が正直理解しきれていない面もあります)パフォーマンスの問題ではありましたが、クラッシュの直接原因ではなかったようです。
JVMメモリ設定の重複
-Xms256m, -Xmx2048m, ..., -Xmx8192m
-Xmx がうっかり2回指定されていました(後者が有効なので動作上は問題なし)。これ自体はクラッシュの原因ではありませんが、設定ファイルの引き継ぎにも一貫性のなさが見え、環境全体に違和感があることを示していました。
切り分けテストと原因の絞り込み
テスト1: 外部ターミナルから npm start を実行する
PyCharmを開いた状態で、外部のコマンドプロンプトから npm start を実行したところ、PyCharmは落ちませんでした。
これにより、問題が npm start 自体ではなく、PyCharmのnpmツール内蔵ターミナルを経由して実行したときだけ起きることが確認できました。
この1つのテストで、疑わしい範囲が一気に狭まりました。
テスト2: ConPTYを無効化する
次は、PyCharmの内部レジストリ設定で terminal.use.conpty.on.windows を false に変更し、npmツール内蔵ターミナルから npm start を実行しました。
結果、クラッシュしなくなりました。
この2つの切り分けから、問題がConPTY周辺にあることはほぼ確実と判断しました。
ConPTYの無効化手順
Settings(設定画面)のTerminalセクションにはConPTYのオン・オフ項目がないため、内部レジストリから変更する必要があります。
- Help → Find Action(
Ctrl+Shift+A)を開く Registryと入力してEnterを押す- レジストリ画面の検索欄に
terminal.use.conpty.on.windowsと入力する - 該当項目のチェックボックスをオフにする
- PyCharmを再起動する
これでターミナルはConPTYではなく旧方式のWinPTYで動作するようになります。カラー出力の品質が若干落ちる場合がありますが、安定性は大幅に向上します。
なぜConPTYで落ちるのか(推測)
ここからは状況証拠に基づく推測です。裏付けとなるクラッシュダンプの解析やDLLのバージョン比較は行っていないため、その前提で読んでいただければと思います。
ConPTY(Windows Pseudo Console)は、Windows 10 バージョン1809で導入された仮想端末APIで、従来のWinPTYに代わりカラー出力やUnicode対応を改善した仕組みです。VS Code、Windows Terminal、JetBrains系IDEの内蔵ターミナルなどで採用されています。
npm start で起動するNode.jsの開発サーバーは、コンパイルログやHMR通知などを大量かつ高速にコンソールへ出力します。ConPTYはこの出力をPyCharmのJavaプロセスに中継する役割を担っています。
今回の環境では、PyCharm 2026.1が PyCharm 2023.1.6 のフォルダにインストールされており、conpty.dll も旧パスからロードされていました。上書きアップデートではすべてのネイティブバイナリが確実に更新される保証がないため、新しいターミナルエンジンと conpty.dll の間で何らかの不整合が生じ、大量出力時にネイティブ層で異常終了に至っている——というのが現時点での仮説です。
idea.logに記録が残らないのも、この仮説と整合的です。クラッシュがJVMの管理外のネイティブコードで発生している場合、JVMのエラーハンドラ自体が呼ばれず、ログを書く余地がないためです。
より確度の高い原因特定を行うのであれば、Windows Event ViewerでのApplication Errorの確認、ProcMonによるDLLロードのトレース、conpty.dll のファイルバージョン比較などが有効な次のステップになると思います。
複合的な条件で発生する問題
今回の問題は、複数の条件が重なって初めて顕在化するタイプのものでした。
| 条件 | 結果 |
|---|---|
上書きアップデート + ConPTY有効 + npm start(大量出力) |
クラッシュする |
上書きアップデート + ConPTY無効 + npm start |
問題なし |
| 上書きアップデート + ConPTY有効 + Pythonスクリプト(少量出力) | 問題なし |
上書きアップデート + 外部ターミナル + npm start |
問題なし |
どれか1つの条件を外すだけでクラッシュは回避できます。裏を返すと、再現条件の特定が難しく、「環境によって起きたり起きなかったりする」ように見える厄介な問題でもあります。
再発防止のための対策: クリーンインストール
ConPTYの無効化は1つの回避策ですが、そもそもネイティブコンポーネントの不整合が関与しているのであれば、クリーンインストールで解消される可能性が高いと考えています。
結局それかよって感じですが、やっぱりクリーンインストールするのが一番手っ取り早く効果があられるかもしれません。
- PyCharmをアンインストールする
C:\Program Files\JetBrains\PyCharm 2023.1.6\フォルダが残っていれば手動で削除する- PyCharm 2026.1を新規インストールする
設定ファイルは %APPDATA%\JetBrains\PyCharm2026.1\ に保存されており、アンインストールしても消えないため、再インストール後に自動的に引き継がれます。
また、JetBrains Toolbox Appを使ってインストール・アップデートを管理すると、バージョンごとに独立したディレクトリにインストールされるため、今回のようなパスの不整合が起きにくくなります。
教訓
1. サイレントクラッシュには切り分けテストが最も有効
ログに情報がない場合、ログをいくら睨んでも答えは出ません。「何を変えたら再現しなくなるか」を1つずつ試す切り分けが最も効果的です。今回は「内蔵ターミナルか、外部ターミナルか」という1つの切り分けで原因の範囲を大幅に絞り込めました。
2. Updaterによる上書きアップデートには(案外)リスクがある
JetBrains系IDEに限らず、メジャーバージョンをまたぐ上書きアップデートは予期しない問題を引き起こすことがあります。特にネイティブバイナリが関わる場合、古いファイルが残ることで新旧の不整合が生じる可能性があります。メジャーアップデートの際はクリーンインストールを検討すべきです。
3. 「確認できたこと」と「推測していること」を分ける
これは今回きづいた教訓というか、先輩方に指摘されたことですが、トラブルシューティングの記録を残すとき、切り分けで確認した事実と、状況証拠からの推測を明確に分けておくことが大切です。
事実と推測を混ぜてしまうと、後から振り返ったときに「結局何がわかっていて何がわかっていないのか」が曖昧になってしまいます。
4. テレメトリデータも情報源になる
PyCharmが出力するworkspaceModelのメトリクスからは、ファイルインデックスの規模やメモリ使用状況など、idea.logだけではわからない情報が得られます。今回はこのデータから node_modules の大量ファイル登録を把握できました。結果的にクラッシュの直接原因ではありませんでしたが、パフォーマンス改善のための有益な情報でした。
まとめ
- PyCharmのnpmツール内蔵ターミナルで
npm startを実行するとIDEがクラッシュする問題に遭遇しました。 - idea.logにもJVMクラッシュダンプにも記録が残らないサイレントクラッシュでした。(ただし、再現性が高かったのでわりと切り分けがしやすくてそこは助かりました)
- 切り分けの結果、ConPTY周辺が原因である可能性が非常に高いと判断しました。
- 上書きアップデートによるネイティブコンポーネントの不整合が関与していると推測しています(
conpty.dllの新旧差分までは未検証)。 - レジストリで
terminal.use.conpty.on.windowsを無効化することで回避できます。 - 再発防止にはPyCharmのクリーンインストールが有力な対策です。
ログに何も残らない問題のデバッグは心が折れそうになりますが、AIの力もかりつつ地道な切り分けが結局は一番の近道だとおもいます。
同じ現象で困っている方の助けになれば嬉しいです。
それでは、次回またお会いしましょう!