Support Board
Date/Time: Wed, 15 Jul 2026 07:19:13 +0000
Post From: v2891: All chart updating silently stops mid-session (3 dumps, all threads idle)
| [2026-07-15 04:46:12] |
| User703790 - Posts: 2 |
|
Environment: - Sierra Chart 2891 64-bit, Windows 11 x64 - Denali Exchange Data Feed + Teton CME Order Routing (Sim trading only) - One chartbook, 3 charts: NQU26_FUT_CME Daily, ESU26_FUT_CME Daily, NQU26_FUT_CME 1-min - Update Intervals at incident: Use OS Timer For Charts = No; global Chart Update Interval = 100 ms; Timer Management Enable = Yes (multiplier 3, max 500 ms); Minimum Delay Between Chart Updates = 1 ms - Custom ACSIL studies loaded (see dump analysis below) Symptom: All chart updating stops silently during RTH. After the stop: the title bar clock keeps running; the DF counter keeps incrementing; netstat shows all three sockets (Denali, Teton, HTTPS) still ESTABLISHED; the process reports Responding=True; CPU is ~1% (0.31 s over a 30 s window); the Message Log has no entries at or after the stop. ACSIL study update callbacks stop (our studies' log writes stop). Charts never recover on their own; only restarting Sierra Chart recovers. Occurrences: 2026-07-07, 2026-07-09, and twice on 2026-07-14 (the second freeze came 24 minutes after restarting SC). On the 07-14 first freeze, chart painting stopped at 08:33:07 (chart time zone) immediately after a 17-second historical intraday download for NQU26 completed and "Real-time Intraday chart data file updates started"; study update callbacks continued until 09:09:42, then everything stopped. The second freeze that night had zero network events in the Message Log, and all studies' last callbacks fell within the same second. Dump analysis: We captured full process dumps of all three recent freezes and analyzed them with cdb (!analyze -v; ~*kb; !locks). Identical signature in all three: all 24 threads are in wait states (main thread in user32!GetMessageW; chart window threads in GetMessageW; I/O threads in GetQueuedCompletionStatus); zero critical-section contention; no busy thread. The main-thread frames are byte-identical across the three dumps: win32u!NtUserGetMessage / user32!GetMessageW / SierraChart_64+0x13a795b / +0x13a7fe9 / +0x15601a7 / +0x151d00e. No frame from our custom study DLL appears in any thread of any dump, and the freezes span several different builds of our studies, so this does not appear to be custom-study code stalling the update thread. Questions: 1. Version 2870 resolved "timers would stop completely on charts" (2867-2869, stated as single-chart sessions). We see the same end state on 2891 with 3 charts. Is there a known multi-chart variant, and was anything related fixed between 2892 and 2927? 2. The 2760 release notes describe the primary thread's message queue filling up and message processing silently stopping (fixed there for DTC Trading messages). Could chart-update timer notifications be subject to the same failure mode on 2891? Is there an equivalent safeguard for chart updates? 3. Per the 2867 notes we are raising Minimum Delay Between Chart Updates from 1 ms back to 10 ms. Is this the correct mitigation for this condition, and what value do you recommend for 3 charts? 4. In this state, does Chart >> Reload and Recalculate restart the chart timers (per Help Topic 3), or is a full restart required? We will test this on the next occurrence. 5. We can provide all three dump files (~180 MB each). How should we submit them? |