Support Board
Date/Time: Sat, 29 Aug 2026 23:25:59 +0000
v2891: All chart updating silently stops mid-session (3 dumps, all threads idle)
View Count: 390
| [2026-07-15 04:46:12] |
| User703790 - Posts: 5 |
|
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? |
| [2026-07-15 14:10:24] |
| Sierra_Chart Engineering - Posts: 24703 |
|
We would need to be able to reproduce the problem to be able to understand it. The first thing to do is update to the current version and see if the problem happens again. We would not think it would make a difference but we have to see. Do you also have the problem when, Global Settings >> General Settings >> General >> Update Intervals >> Use OS Timer For Charts is set to Yes. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2026-07-16 03:30:29] |
| User703790 - Posts: 5 |
|
Answers: 1. Use OS Timer For Charts = Yes: yes, the freezes also occur with Yes. That was our setting through 2026-07-09; the 07-07 and 07-09 freezes happened with Yes. We changed it to No on 2026-07-10 as a single-variable test; the two 07-14 freezes and two further freezes since then all occurred with No. Same end state under both settings. 2. Two new occurrences since our first post: 2026-07-15 at 10:05:50 chart time, and overnight at ~17:41 chart time (Globex session, zero network events in the Message Log around it). Both occurred with "Minimum Delay Between Chart Updates" already raised from 1 ms to 10 ms before that session, so that mitigation did not prevent it. Both dumps were auto-captured. We also captured a dump of a related after-state: once frozen, if the monitor sleeps and wakes, the chart region repaints fully black; tab switching and minimize/restore do not recover it. 3. We are scheduling the update to the current version (our ACSIL studies must be recompiled for the 2895/2897/2911 type changes) and will report whether it reproduces there. 4. Reload and Recalculate at the moment of a freeze: not yet tested; we will run it on the next occurrence and report. How should we submit the dump files? |
| [2026-07-16 14:43:35] |
| Sierra_Chart Engineering - Posts: 24703 |
|
The dump file you would provide would not be helpful to us. The dump file concept might be a good way for us to debug this, but we need to internally go over this, and give you a method to have Sierra Chart generate a dump file.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2026-07-16 22:08:37] |
| User703790 - Posts: 5 |
|
Update: we completed the update and ran a first full session on 2927 (our ACSIL studies recompiled against the 2927 headers). Result: zero chart-update freezes across the full session (~7 hours). The session did include five data-feed interruptions on our network route (trade stream, depth stream, and one full disconnect at ~14:25 chart time, followed by automatic "Reconnect Wait"), but the chart update engine kept running through all of them — none of the silent-freeze end state we reported on 2891. We will keep testing on 2927 and report if the freeze reproduces. You mentioned providing a method to have Sierra Chart generate dump files internally — we are standing by for that, and will use it instead of externally captured dumps on any future occurrence. |
| [2026-07-18 11:18:40] |
| User703790 - Posts: 5 |
|
Follow-up with our completed analysis — we finished the 2-night retest on 2927 and did a deep forensic pass on night two (Fri 7/17). Correcting our earlier working theory: this now looks like an application-level stall, not only a network issue. Night one (Thu) had five data interruptions we have not yet re-analyzed under this lens. All times CDT, Fri 7/17: 1. 09:03–09:19 — five cycles of "Denali Data Feed | There has been no activity on the network socket for 60s. Will reconnect.", hopping ds7→ds26-2→ds32-2→ds26→ds28→ds32→ds45 (ports 10048/443), errors mostly 10053, some 10054. Full SC restart at 09:28 cured it. 2. 10:07 — all our ACSIL studies stopped executing, with no reconnect or error entries in the Message Log from 09:40 to 10:15. Full SC restart at 10:19 cured it. 3. 11:05:24 — every study across all three charts in the chartbook stopped within the same ~20-second window (our studies run UpdateAlways=1 and UsesMarketDepthData=1 and write throttled heartbeat logs; all logs ceased between 11:05:05 and 11:05:24 and never resumed). At 11:05:31 the server force-closed the feed socket (10054); reconnect succeeded at 11:05:35 ("Market Depth data restarted", "Clearing market depth", 2.3-minute intraday catch-up completed 11:05:41). From then to the 16:00 close, the receive/write side stayed perfectly healthy — 259,187 records written to the .scid, max inter-record gap 11.4 seconds — while zero study executions occurred for 5 hours. The process stayed alive (scheduled Daily HD Request logged at 16:50, feed-lost notice at 17:01) and the UI kept painting live bid/ask while chart times stayed frozen. We also analyzed our two full-memory dumps locally (captured during episodes 1 and 2 that night): in both, all 24 threads are idle in kernel waits — the worker pool parked in WaitForMultipleObjects at a common return address — no critical section is owned by any thread, no thread is busy in user code, and zero stack frames reference our custom-study DLL (loaded but never on a stack). It looks like the study/chart-update workers are waiting on a wake-up that never arrives, while the network receive path keeps writing the .scid. So: data reception and .scid writing = healthy; study/chart-update execution = permanently stopped; only a full restart recovers. The study stall began seconds BEFORE the server-side disconnect, and episode 2 had no network event at all — the disconnect may be a consequence rather than the cause. Questions: 1. Is this a known issue — chartbook-wide study/chart-update scheduling permanently stalling around a feed disconnect + market-depth clear/restart sequence? We saw five freezes with the same on-screen signature on 2891, so it does not appear new in 2927. 2. We hold the two externally captured full-memory dumps described above. You asked us not to upload externally captured dumps — please either share the exact steps for SC's built-in dump generation so future captures match your requirements, or tell us how you'd like to receive the existing files. Thank you. |
| [2026-07-20 13:47:56] |
| Sierra_Chart Engineering - Posts: 24703 |
|
Are you located in China? We want you to enable the option to save the Message Log to files: Message Log: Automatically Saving Message Log to File And we want you to see if you see this message in the log files anytime you notice problems: Error posting message in c_AsyncWindow::PostMessage
This absolutely should never be necessary: . Full SC restart at 09:28 cured it.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2026-07-20 13:48:32
|
To post a message in this thread, you need to log in with your Sierra Chart account: