Hello! This is the Qualiteg Product Development Team.

The moment you run npm start in PyCharm's built-in npm tool terminal, the IDE vanishes without a single error message.

Restart it, try again, and it crashes again. The logs offer no clues.

In this post we document our encounter with this "silent crash" — from narrowing down the cause to establishing a workaround. We hope it helps anyone struggling with the same issue.

Environment

As noted above, this PyCharm is the latest version available at the time of writing (2026.1).

What we confirmed, and what we suspect

First, let us be clear about the confidence level of what this article describes.

What we confirmed

• The crash reproduces only via the built-in npm tool terminal (it does not reproduce in an external terminal)
• Disabling ConPTY avoids the crash
• Neither idea.log nor any JVM crash dump contains a solid trace
• The installation path still contains an old version name (PyCharm 2023.1.6)
• conpty.dll is loaded from the old version's path

What we suspect

• Native component inconsistencies caused by in-place updates may be involved
• conpty.dll is very likely at the heart of a compatibility issue
• It appears to be a native-layer fault that only manifests under heavy console output

conpty.dll — we did not diff its old and new versions or perform a detailed crash dump analysis, so our conclusions about the root cause are inferences from circumstantial evidence. That said,
based on the results of our isolation testing, we believe the cause lies somewhere around ConPTY with a very high degree of confidence.

Symptoms in detail

When you run npm start in PyCharm's built-in npm tool terminal, the PyCharm window disappears within a few seconds. It vanishes from the taskbar and the process is gone. The crash reproduced almost 100% of the time.

The following points stood out.

• No error dialog appears at all
  Not even the standard JetBrains crash notification appears. The window quite literally just vanishes.
  
• idea.log contains no trace of the crash
  After a normal startup and indexing completion, the log simply cuts off.
  
• Running Python scripts causes no problems
  Running Python via a Run Configuration is perfectly stable.
  
• Running npm start from a Command Prompt does not bring PyCharm down.
  Using an external terminal, everything works fine.

That last point turned out to be the most important clue for isolating the problem.

The challenge of a silent crash that leaves no logs behind

Normally, when PyCharm (or any IntelliJ-based IDE) crashes, a Java-level exception is recorded in idea.log, or a JVM crash dump (java_error_in_pycharm_*.log) is generated in the user's home directory.

This time, neither contained anything useful. That suggests the process is dying not in the Java layer but somewhere lower — in native code. The JVM is being terminated before it even has a chance to write a crash dump.

With nothing in the logs, the only viable approach was isolation testing: changing one thing at a time and seeing what makes the crash stop reproducing.

A note on log locations

Note that PyCharm stores its logs and settings in separate directories. Logs live in %LOCALAPPDATA% (AppData\Local), and settings in %APPDATA% (AppData\Roaming). Many articles online mention only %APPDATA%, which often leads people to search under Roaming and come up empty.

Logs:     %LOCALAPPDATA%\JetBrains\<version>\log\
Settings: %APPDATA%\JetBrains\<version>\

The easiest way is Help → Show Log in Explorer. In versions from 2025 onward, Help → Diagnostic Tools → Special Files and Folders lists the full paths of all relevant directories, which is also handy.

Clues gleaned from idea.log

The moment of the crash was not recorded, but idea.log did yield several indirect clues.

Mismatch between the installation path and the settings path

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

The settings path selector is PyCharm2026.1, yet the installation directory is still PyCharm 2023.1.6.

This shows that years of in-place updates have eroded the consistency of the environment. It gave us reason to suspect that the native binaries might not have been updated as expected.

Where ConPTY is loaded from

Loaded bundled ConPTY from C:\Program Files\JetBrains\PyCharm 2023.1.6\lib\pty4j\win\x86-64\conpty.dll

The conpty.dll used by the built-in npm tool terminal is loaded from the old version's path. We could not confirm whether it matches the version PyCharm 2026.1 expects, but the odd path is certainly suspicious.

A huge number of node_modules files registered

NodeModulesDirectoryManager - Contributed {
  allCalculationsDuration: 2263 ms,
  allIncludedFileCount: 45078,
  allRootsWorkspaceModel: 42960,
  ...
}

45,078 files were registered for indexing.

At first we suspected this was the culprit, but setting node_modules to Excluded did not make the crashes go away. (To be honest, we have seen cases where a directory marked Excluded still gets indexed when it is a library root, so we admit we do not fully understand what Excluded actually guarantees.) It was a performance problem, but apparently not the direct cause of the crash.

Duplicate JVM memory settings

-Xms256m, -Xmx2048m, ..., -Xmx8192m

-Xmx was accidentally specified twice (the latter wins, so it causes no functional problem). This is not the cause of the crash either, but it revealed the same lack of consistency in how the config files had been carried forward — another sign that something about the environment as a whole was off.

Isolation tests and narrowing down the cause

Test 1: Run npm start from an external terminal

With PyCharm open, we ran npm start from an external Command Prompt, and PyCharm did not crash.

This confirmed that the problem is not caused by npm start itself; it happens only when the command is run through PyCharm's built-in npm tool terminal.

This single test dramatically narrowed the range of suspects.

Test 2: Disable ConPTY

Next, in PyCharm's internal registry we changed terminal.use.conpty.on.windows to false, then ran npm start from the built-in npm tool terminal.

The result: no more crashes.

From these two isolation tests, we concluded it was all but certain that the problem lies somewhere around ConPTY.

How to disable ConPTY

The Terminal section of the Settings dialog has no on/off switch for ConPTY, so you need to change it via the internal registry.

1. Help → Find Action (Ctrl+Shift+A) — open it
2. Registry — type this and press Enter
3. In the search box of the Registry dialog, enter terminal.use.conpty.on.windows.
4. Set the checkbox for that entry to off.
5. Restart PyCharm.

The terminal will now run on the older WinPTY mechanism instead of ConPTY. Color output quality may degrade slightly, but stability improves significantly.

Why does it crash with ConPTY? (speculation)

What follows is speculation based on circumstantial evidence. We have not backed it up with crash dump analysis or DLL version comparison, so please read it with that in mind.

ConPTY (Windows Pseudo Console) is a virtual terminal API introduced in Windows 10 version 1809. It replaces the older WinPTY with improved color output and Unicode support, and is used by VS Code, Windows Terminal, and the built-in terminals of JetBrains IDEs.

npm start launches a Node.js development server that writes compile logs, HMR notifications, and more to the console in large volumes at high speed. ConPTY is responsible for relaying that output to PyCharm's Java process.

In our environment, PyCharm 2026.1 was installed in a folder named PyCharm 2023.1.6, and conpty.dll was also being loaded from the old path. An in-place update does not guarantee that every native binary is reliably replaced, so our current hypothesis is that some inconsistency between the new terminal engine and conpty.dll causes an abnormal termination in the native layer under heavy output.

The absence of any record in idea.log is also consistent with this hypothesis: if the crash occurs in native code outside the JVM's control, the JVM's error handler never runs and has no chance to write a log.

For a more definitive diagnosis, useful next steps would include checking Application Error events in Windows Event Viewer, tracing DLL loads with ProcMon, and comparing the file versions of conpty.dll.

A problem that emerges only under combined conditions

This was the kind of problem that only manifests when multiple conditions coincide.

Remove any single one of these conditions and the crash goes away. The flip side is that the reproduction conditions are hard to pin down, which makes it look like the troublesome kind of problem that "happens on some machines but not others."

Preventing recurrence: a clean install

Disabling ConPTY is one workaround, but if inconsistent native components really are involved, a clean install is very likely to resolve the problem at its root.

"So it comes down to that after all," you might say — but yes, a clean install may well be the quickest and most reliable fix.

1. Uninstall PyCharm.
2. C:\Program Files\JetBrains\PyCharm 2023.1.6\ — if this folder is still there, delete it manually.
3. Install PyCharm 2026.1 fresh.

Your settings are stored in %APPDATA%\JetBrains\PyCharm2026.1\ and survive uninstallation, so they are picked up automatically after reinstalling.

Also, if you manage installs and updates through the JetBrains Toolbox App, each version is installed into its own directory, which makes path inconsistencies like the one we hit much less likely.

Lessons learned

1. For silent crashes, isolation testing is the most effective tool

When the logs contain nothing, staring at them harder will not produce an answer. Testing "what change makes it stop reproducing," one variable at a time, is the most effective approach. In our case, the single split between built-in terminal and external terminal narrowed the search space dramatically.

2. In-place updates via the updater carry more risk than you might expect

Not just with JetBrains IDEs — in-place updates across major versions can cause unexpected problems. When native binaries are involved in particular, leftover old files can create inconsistencies between old and new components. Consider a clean install for major upgrades.

3. Separate "what we confirmed" from "what we suspect"

This is a lesson we learned this time — or rather, one our senior engineers pointed out: when writing up a troubleshooting record, clearly separate the facts confirmed through isolation testing from the inferences drawn from circumstantial evidence.
If you mix facts and speculation, it becomes unclear in hindsight what was actually established and what was not.

4. Telemetry data is a source of information too

The workspaceModel metrics that PyCharm emits reveal things idea.log alone cannot, such as the scale of the file index and memory usage. This data is how we discovered the huge number of node_modules files registered for indexing. It turned out not to be the direct cause of the crash, but it was valuable input for performance tuning.

Summary

• We ran into a problem where running npm start in PyCharm's built-in npm tool terminal crashed the IDE.
• It was a silent crash that left no trace in idea.log or in a JVM crash dump. (Fortunately, it reproduced reliably, which made isolation testing relatively straightforward.)
• Based on our isolation tests, we concluded that the cause very likely lies somewhere around ConPTY.
• We suspect that native component inconsistencies from in-place updates are involved (we have not verified this by diffing old and new versions of conpty.dll).
• You can work around it by disabling terminal.use.conpty.on.windows in the internal registry.
• For preventing recurrence, a clean install of PyCharm is the strongest remedy.

Debugging a problem that leaves nothing in the logs can be demoralizing, but steady isolation testing — with some help from AI — is ultimately the fastest path.
We hope this helps anyone facing the same issue.

See you in the next post!