Bruce — that’s a really clean isolation. Ruling out UI and indicators entirely (bare install, one chart, one DOM) and still reproducing the freeze purely from stacked same-price orders points squarely at the order/execution engine rather than the rendering path.
One way to separate that from BillMilton’s OnRender/ChartTrader theory: run the same stacked-order sequence with ChartTrader fully disabled and no chart open at all (orders placed via DOM only, or via an ATM strategy). If the freeze/serialization still happens with zero OnRender calls involved, that confirms it sits in the order/execution pipeline itself (event queue, order state machine, fill callbacks), not in chart rendering.
It would also help to capture a trace/log on 8.6.3 and on the newer build during the exact same stacked-order sequence, then diff the timestamps between consecutive OnOrderUpdate/fill events. If 8.6.3 processes them with noticeably shorter gaps, that’s strong evidence something changed in how order events are queued or dispatched between versions rather than a UI regression. Since your test is so deterministic (single contract fine, stacked at one price broken), a side-by-side trace comparison on the identical sequence across both versions seems like the fastest way to pin down exactly what changed
I can give you half an answer to your first point re: disable Chart Trader so as to eliminate the ‘#BillMilton Q’
In the example I gave, I wasn’t using Chart Trader - I backed up from that path when first encountered its’ potential for problems & still stick to simple stood-the-test-of-time DOMs
#Bill’s further test seems to clearly associate this back with the good ‘ol’ SoundsDirectory-gate scandal of yore, & I guess a repeat of that with no chart whatsoever enabling/disabling ConseqSounds might put it to bed.
But, there’s nothing to see here. Just ask Ninja….
(if I get very very bored I might fire up my virgin naked .17 install. I deleted all the pesky sound files installed by default, but don’t know if default is Play Consecutively or not. I don’t expect I would have changed it one way or the other seeing as I’d deleted the files anyhow, so it’s safe to say whatever is default is what I was using, even though no files to play)
I am (with AI) working on indicator that manages orders and testing seems to show that orders do not come from single thread:
AI conclusion:
“Entry, Stop1, and Target1’s initial submission/acceptance/fill all ran on thread 50 (the same thread as OnMarketData ticks). Then the moment you manually cancelled a leg, every subsequent CancelPending/CancelSubmitted/Cancelled event ran on thread 17 — a different thread, in the same session, same account, same instance. That’s exactly the kind of proof the earlier cross-session comparisons couldn’t give you: thread identity for order events isn’t fixed, it depends on what triggered the state change. Market-driven progression (fills as data arrives) lands on the instrument thread; a synchronous UI-triggered action (your manual cancel click) lands on a different one entirely. The in-flight exit-qty dictionary in the real Trigger file needs to be safe against both, not just “the data thread””
“conclusion for the design: no code touching shared state from these handlers can assume any particular thread”
There is a couple of confirmed bug withs the latest release. In 8.1.7.2. They added a fix for this:
44274 - Restored non-overlapping notification sounds when Play consecutively is disabled
But it must have broken something because when you have the Play sounds consecutively unchecked it causes some erratic playback of sounds. I reported 2 bugs related to this and they were able to repeat it.
Interesting finding, especially the freeze disappearing with “Play Consecutively” enabled. That suggests the audio/UI path shouldn’t be ruled out yet.
Have you tried reproducing the same stacked-order sequence with no chart open, using the DOM only, while keeping the audio setting as the only variable?
If the behavior changes consistently with that setting, comparing the logs and traces around the same order sequence might help narrow down where the stall originates.
Does it solve the crashing issues? I don’t see anything in the release notes that would indicate that this has been identified as an issue or fixed in that release.
I’m currently on 8.1.6.3 - the last stable release I know of.
Kevin, the official 8.1.8.3 notes do not establish that the freezes in this thread are fixed.
The September 29 patch lists two prop-provider connectivity fixes: missing accounts at login (54539) and unavailable Trade Performance results (54540). Neither entry identifies the order-fill/chart/Control Center freeze described here.
There is an earlier, separate audio-alert stability fix in 8.1.8.1 (48260). That is relevant to the sound-setting reports above, but it is not proof that every crash has the same cause.
I would treat an upgrade comparison as a reproducibility test, not a confirmed fix: preserve the existing workspace, use simulation only, and repeat the same order sequence with the same indicators and audio setting. Record the exact build, incident time, log and trace. If it still fails, that gives support a specific remaining case.
Does your freeze happen on a fill, or only when several notification sounds overlap?
I’m running 8.1.6.3 on my trading PC.
I have newer ones on my laptop.
I don’t want to upgrade my trading PC because of the freezing issues.
Today, ONLY MNQ froze when multple orders filled very close to each other.
MES charts were still operational. Strange that only one instrument froze and would not respond.
This has not been an issue lately but ended up costing me until I could Taskklill and reset NT to restart and close the trades.
FWIW
This behavior is not strange, from NT docs: 8. Reduce the number of duplicate instances of the same instrument within your Workspace.
NinjaTrader assigns each instrument to a separate CPU core to isolate performance issues. Having multiple charts of the same instrument can lead to inefficiencies and slower performance. Using fewer duplicates of the same instrument can significantly enhance overall responsiveness.
Hinsel, MNQ freezing while MES still responds narrows the case, but it doesn’t identify the cause. Bill’s instrument-specific workload point fits that symptom; it doesn’t establish that duplicate charts caused this incident.
I’d preserve the current workspace and the log/trace files around the exact fill time. Then repeat the same closely spaced MNQ fills in simulation with one plain MNQ chart and no custom indicators, keeping the build and audio setting unchanged. Compare that with the original workspace. If the plain case also stalls, send both cases to support rather than treating a workspace change as a fix.
Were MNQ’s chart, SuperDOM and Control Center all unresponsive, or only the chart?
All charts with MNQ were non-responsive. If another MNQ chart worked I would have closed the trade. Only other charts opened were MES. They were updating.
I tried the hot-key. CTRL-Z but it was not doing anything.
My solution was to close NT with the task manager and use admin command prompt and the taskkill command. Then restart NT. I was able to close the trade. I probably should have used my laptop to close but it was not turned on at the time.
I also tried to close on the chart by clicking the CLOSE button. Nothing happened.
Thanks, Hinsel. That confirms every MNQ chart stalled while MES still updated. The failed chart Close button and hotkey still leave the separate order-management windows untested.
For the support report, separate chart behaviour from whether Control Center and SuperDOM could accept clicks, and include the exact fill time plus the log/trace files from that session.
The next controlled comparison is still one plain MNQ chart in simulation on the same build. If that also stalls, keep that second log alongside the original workspace log. A restart or fewer charts is not a proven fix from this incident.
Is this a problem a VPS could resolve? I haven’t used Ninjatrader in months due to these issues MNQ was so bad I couldn’t take it anymore.
The issues began with change from Continuum to Live for me. With same version of Ninjatrader Continuum was great. With Live, orders would turn yellow and sit there for over a minute, leaving me not knowing where I was filled… etc.
A VPS might help if the bottleneck is your own PC or connection. Your report does not establish that, so I would not pay for one as the first fix.
The change from Continuum to Live with the same build is worth isolating. Compare one plain MNQ chart in simulation on that build, with the same connection and no custom indicators. Record the exact order State text, connection status and matching log/trace times. A simulation comparison checks responsiveness, not live routing or fills.
If a live order is uncertain, verify its status with the broker before resubmitting. Did the Orders tab show Initialized, Trigger pending or another State during that minute?
The orders would be “initialized”, then “pending” during the delay.. Doesn’t MNQ being much worse than any other instrument suggest it’s high volume related..?
Yes, heavier tick traffic could explain MNQ being worse, but it does not prove the cause. Initialized means local validation. Which full State followed it: Trigger pending, Cancel pending or Change submitted? Save that label and timestamp with your log/trace files. One plain MNQ chart in simulation helps separate chart load from live routing.
Switching feeds could help, but only if the feed is where the stall begins. I’d test it as an A/B comparison rather than assume it is a fix: keep the NinjaTrader build, workspace, instrument, session, and simulated order sequence the same, and change only the data connection.
Log last-tick age and timestamps, connection events, UI responsiveness, and the exact order State transitions. If incoming ticks stop before the UI or order stall and the symptom repeatedly follows one feed, that points toward the feed or adapter path. If ticks remain fresh while MNQ charts and order controls stop responding, changing feeds may only mask a platform workload or order-event issue.
For any uncertain live order, verify broker-side status before resubmitting. A short side-by-side log around the incident would be stronger evidence than whether the screen simply appears smoother.
DoAndBecome, use this small incident record: PC time + timezone | instrument | last tick time | exact Orders State | chart responsive | Control Center responsive
Keep a before/during pair with the matching logs. Fresh ticks plus frozen controls differ from stopped ticks. Verify uncertain live orders with the broker before retrying. Which window stayed responsive?