Intermittent exception in Fritz 21 using Stockfish dev-20260524-5b068c96 after extended runtime

[wattsgunn-mja]

Describe the issue

I am seeing intermittent Stockfish engine exception errors when running Stockfish dev-20260524-5b068c96 under Fritz 21.

The error is not immediate or deterministic. The engine can run multiple games successfully before and after the exception. The issue appears conditional, possibly related to elapsed runtime, repeated games, or session state accumulation.

Fritz displays this message:

"Stockfish dev-20260524-5b068c96 caused an exception.
This is a problem in the engine."

System shown in the Fritz dialog:
Win11.0 x64
64870 MB
AMD Ryzen Threadripper 9970X 32-Cores
N=1/P=1/C=32/L=64/G=1

Expected behavior

I would expect the engine to continue running indefinitely without exceptions during normal Fritz 21 gameplay sessions, even after many completed games and extended runtime.

The engine frequently performs very well for long periods, including deep searches, mate calculations, and multiple completed games without issue.

Because the exceptions are intermittent and non-deterministic, I suspect this may involve a runtime/session-state condition rather than an immediate startup or reproducible crash.

Steps to reproduce

1. Start Fritz 21 on Windows 11 x64.
2. Load Stockfish dev-20260524-5b068c96.
3. Configure engine for:
   • 30 threads
   • 24576 MB hash
4. Play multiple live games over an extended session.
5. During some sessions, additional browser tabs and concurrent desktop activity were also present.
6. The engine may run many games successfully before an exception occurs.
7. After the exception, restarting Fritz 21 usually restores stable operation again.

Additional observations:

• The exception does NOT occur immediately at startup.
• The exception is NOT reproducible on demand.
• The engine may continue operating normally for many games both before and after an exception.
• Reduced desktop/browser activity appeared to improve stability.
• Clean restart of Fritz 21 appears to temporarily reset the condition.

Anything else?

Additional observation:

The exception appears more likely to occur during longer Fritz 21 sessions involving additional browser tabs or concurrent desktop activity. Reduced desktop/browser activity and restarting Fritz 21 appeared to improve stability.

The engine frequently continued operating normally after restarting Fritz 21, suggesting the issue may involve runtime/session-state accumulation rather than immediate deterministic instability.

Operating system

Windows

Stockfish version

Stockfish dev-20260524-5b068c96

[wattsgunn-mja]

Additional observation after further testing:

The exception dialog itself is generated by Fritz 21, not directly by Stockfish.

The engine may run many games successfully both before and after an exception occurs. Clean restart of Fritz 21 frequently restores stable operation for extended periods.

This raises the possibility that the triggering condition may involve Fritz 21 runtime/session-state handling, UCI communication, timeout detection, or another interaction layer in addition to possible engine-side conditions.

Observed behavior continues to appear conditional and runtime-associated rather than immediately reproducible.

[vondele]

Based on the information in the issue, this is not so easy to diagnose. One question would be if you have large pages enabled?

https://official-stockfish.github.io/docs/stockfish-wiki/Advanced-topics.html#windows

The other question, have you tried running Stockfish outside of Fritz (command line / terminal)?

[wattsgunn-mja]

Hi Vondele,

Thank you for the suggestions and for taking the time to respond.

I do not have large pages enabled.

I also completed a fairly extensive standalone command-line test outside of Fritz using:
Stockfish dev-20260524-5b068c96

The engine ran continuously and completely stable for nearly 30 minutes on a Threadripper 9970X system, reaching approximately:

depth 59
~285 million nodes
~1.54M NPS sustained
hashfull = 1000 throughout

During the test, the system was also running multiple Firefox windows, YouTube video playback, and normal multi-monitor desktop activity. Windows remained fully responsive the entire time with no signs of instability.

At this point, the evidence seems to suggest the issue may be related more to the Fritz 21 integration layer/configuration than to Stockfish itself.

Thanks again for the helpful diagnostic ideas and guidance.

[vondele]

OK, nice.

From the nps, this looks like a single threaded run? You can test it multithreaded as well as you described above by pasting the following as input

setoption name Threads value 30
setoption name Hash value 24576
go infinite

[wattsgunn-mja]

Hi Vondele,

Thank you again for encouraging the multithreaded standalone testing outside Fritz.

I completed a very extensive command-line stress test using:

Stockfish dev-20260524-5b068c96

Configuration:

• Threads = 30
• Hash = 24576 MB
• go infinite

System:
AMD Threadripper 9970X
64 GB RAM
Windows 11 Pro

Results were extremely revealing.

The engine ran continuously and completely stable for nearly 12 minutes under sustained heavy multithreaded load while reaching approximately:

• depth 56
• seldepth 76+
• 21.7+ billion nodes searched
• sustained ~30–37 million NPS
• hashfull pinned at 1000
• correct NUMA thread binding reported throughout

Importantly, this was not a “clean-room idle test.” During portions of the run, the system was also handling normal desktop activity, Firefox windows, and video playback while Windows remained fully responsive.

At no point during the entire stress test was there:

• instability,
• freezing,
• corruption,
• scheduler chaos,
• memory exhaustion,
• or any indication of fragile engine behavior.

The software simply continued operating calmly and predictably even with the transposition table fully saturated.

At this point, I think the evidence strongly suggests that Stockfish itself is not the weak link here. The standalone engine behavior under extreme multithreaded load appears exceptionally robust.

Increasingly, the instability seems more likely related to Fritz 21 integration/interaction behavior rather than to Stockfish or the underlying hardware platform itself.

Thanks again for pointing me toward the multithreaded standalone test. It turned out to be extraordinarily informative.

[wattsgunn-mja]

One important point worth stating for the record:

While the standalone multithreaded command-line Stockfish stress test produced extremely strong evidence that Stockfish itself, the Threadripper 9970X platform, and Windows 11 remained completely stable under very heavy load, we do NOT yet possess equivalent direct evidence proving that ChessBase proper would necessarily behave differently than Fritz 21 under identical conditions.

The standalone test demonstrated:

• 30-thread NUMA-aware operation
• 24 GB hash saturation (hashfull 1000)
• 21+ billion nodes searched
• sustained ~30M+ NPS
• extended runtime stability
• no crashes/freezes/instability

However, concluding from that alone that ChessBase proper would automatically behave better than Fritz 21 would go beyond the evidence currently available.

That would require equivalent direct stress testing using ChessBase proper itself under the same workload and conditions.

At this point, the strongest evidence specifically supports the conclusion that Stockfish standalone operation appears extremely robust under severe multithreaded load.

[wattsgunn-mja]

Additional observations after extended testing of Stockfish dev-20260527-313ea4ab under Fritz 21 on a Threadripper 9970X system:

After many additional hours of testing, we now strongly suspect that the Fritz 21 exception message:

“This is a problem in the engine.”

is at minimum overly definitive and potentially misleading.

Operational evidence gathered during repeated testing does NOT currently support the conclusion that the Stockfish engine itself is unstable or corrupted.

Observed facts:

• Stockfish dev-20260527-313ea4ab repeatedly completed extremely deep and tactically complex searches successfully.

• Sustained searches exceeded depth 100 in some positions with coherent PVs and stable evaluations.

• Mate calculations repeatedly converged correctly.

• Multiple full games completed normally.

• No illegal moves, corrupted analysis, frozen searches, or nonsensical evaluations were observed.

• System stability remained excellent throughout testing:

  • AMD Threadripper 9970X
  • 30 engine threads
  • ~24 GB hash
  • No WHEA errors observed
  • No independent signs of CPU/RAM instability

The exception often appears AFTER game completion/resignation or during state transitions rather than during active calculation itself.

Because of this, we now suspect the issue may instead involve:

• Fritz 21 GUI/engine synchronization,
• engine termination handling,
• asynchronous state cleanup,
• protocol interaction,
• or another orchestration-layer edge case.

At this point, we do not believe there is sufficient evidence to specifically implicate Stockfish dev-20260527-313ea4ab itself as the primary fault source.

The current Fritz 21 exception wording appears to point directly at the engine as the culprit, despite repeated evidence that the engine is otherwise operating correctly and very stably under heavy workloads.

[wattsgunn-mja]

Additional update after further controlled testing:

We conducted several additional Fritz 21 + Stockfish dev-20260527-313ea4ab test games under controlled conditions on a Threadripper 9970X system (30 threads / ~24 GB hash).

One important update:

We can no longer conclude that Windows Snipping Tool is required to trigger the Fritz 21 exception popup.

During the latest session:

• Snipping Tool was NOT used at all
• WPR/browser audio tabs were also closed
• The Fritz 21 popup still appeared

However, the most important observation is this:

After the popup appeared, the game continued normally and the engine continued operating coherently.

Observed after the popup:

• evaluations remained logical and progressive
• analysis continued normally
• Stockfish converted the position cleanly
• deep mate calculations remained coherent
• mate compression proceeded normally (Bsfq #18 → Tune trapped rook #16 → Use compiler intrinsic instead of inline assembly for popcnt #15 → size_t cast in TranspositionTable::first_entry() #14 → Minor threats b #13 → Add AUTHORS #5 → Adding comment to describe relative_rank. #1)
• game ended in successful checkmate

This behavior appears inconsistent with actual catastrophic engine failure.

At this point, the evidence increasingly suggests:

• the popup may represent a recoverable GUI/interface/state/orchestration anomaly,
• but the wording:
  “This is a problem in the engine.”
  appears increasingly misleading or overly definitive.

Importantly, we still have NOT observed:

• illegal moves
• corrupted PVs
• nonsensical evaluations
• frozen searches
• WHEA/system instability
• or evidence of hardware instability.

The engine itself continues to appear operationally healthy even after the popup occurs.

[wattsgunn-mja]

Additional Observation After Extended Testing

After several additional hours of testing Stockfish dev-20260527-313ea4ab under BanksiaGUI on an AMD Threadripper 9970X (30 threads, 24 GB hash), I wanted to report an unexpected finding.

The original purpose of my testing was to investigate engine stability. Thus far, BanksiaGUI has remained completely stable despite multiple games, deep analysis sessions, and repeated use of Windows Snipping Tool. No engine exceptions have occurred.

A second observation emerged that I was not looking for:

The workstation's cooling behavior is dramatically different from what I had experienced under Fritz 21.

During active analysis, the cooling fans ramp normally. When analysis ends or the engine is waiting, fan activity subsides. This behavior has been obvious and consistent throughout every game tested.

Importantly, this testing was performed without any opening book loaded, using only Stockfish dev-20260527 under BanksiaGUI.

I have not yet performed formal CPU, power, or thermal measurements, so I cannot explain the cause. I can only report the operational behavior I observed.

Whatever the reason, the difference was significant enough that it became immediately noticeable during ordinary play.

In addition to solving my original stability concerns, BanksiaGUI has proven to be an exceptionally stable and pleasant environment for running modern Stockfish development builds.

[wattsgunn-mja]

Additional Observations After Extended Testing

After additional testing, I believe we can now state the issue more precisely.

Our position is not that Stockfish development builds are necessarily free of bugs. Development builds, by definition, may contain bugs and unexpected behavior.

Rather, our concern is with the certainty of Fritz's conclusion.

Fritz reports:

"This is a problem in the engine."

However, the evidence available to us does not appear sufficient to support that level of certainty.

The same family of Stockfish development builds has now been tested extensively under BanksiaGUI on the same hardware platform (AMD Threadripper 9970X, 30 threads, 24 GB hash) with no corresponding engine exception dialogs observed.

This does not prove that Stockfish is innocent, nor does it prove that Fritz is wrong.

What it does suggest is that several explanations remain possible:

• A genuine Stockfish engine issue.
• A GUI-to-engine communication issue.
• A timing or synchronization issue.
• A state-management issue.
• A condition that Fritz interprets as an engine exception but which may originate elsewhere in the software stack.

In short:

"The evidence does not justify Fritz's certainty."

That statement best summarizes our current position.

One additional observation may be relevant. During many hours of testing under BanksiaGUI, the overall behavior of the workstation was dramatically different. The same Stockfish development builds that previously generated exception dialogs under Fritz operated smoothly and consistently. The workstation's cooling fans were significantly less active, suggesting a substantially different workload profile or resource-management approach within the GUI environment.

This observation is admittedly subjective, but it was repeated consistently across many games and many hours of testing and was significant enough to immediately attract attention.

We continue to investigate and will report any additional findings.