Charts Crashing: Write lock may not be acquired with read lock held.

[QuantKey_Bruce]

Well, that seems possible, though we don't have enough information from this to say. But, if it were a bug in NT alone, we should be seeing a reproduce scenario for this without any custom NinjaScript and I don't think any of the reports all the way back to the beginning had no custom NinjaScript. I don't want to distract from the issue - there COULD be a bug in NT in this regard, but my intuition at this time is that NT simply makes it easy to program the indicators wrongly. I've had my own code make this message in past years, but I've grown defensive in how I program things and I haven't seen it happen in a long time. That certainly isn't evidence, really - I'm just sharing my own personal experience with it for whatever it's worth. It would be great, in one odd sense, if it were a bug in NT, because then there is the potential that it could be fixed once and for all. My fear and really operating assumption however is that NT just makes it easy to mess this up, and that many have messed it up many times.

[kevinenergy]

I'm aware the issue has been coming up on and off for years.

The systematic process of elimination I went through was as follows:

1 write down in my notepad all the indicators and addons I have running
2 reproduce the issue (having lots of bars, on a full screen chart, 4K monitor and scrolling the chart back and forth very fast caused the chart to freeze/crash for me)
3 after restarting Ninjatrader remove one indicator
4 repeat 2 again until the chart freezes
5 strike the removed indicator from the list (since the problem still occurs without it, it is not the cause)
6. Repeat steps 3-5 until only one indicator remains. This final indicator must be the cause...
7. Repeat the whole process without the item identified in 6 to confirm that it was the cause.... however chart still crashes.

I went on like this for hours. Even making a clean install with just a few indicators. I could not identify any one indicator that was causing the issue.
I then launched a Hyper-V instance and tried to reproduce the problem with all the indicators I previously tested and could NOT reproduce the problem in the Hyper-V.

Furthermore. Another user had the issue when only using "UniRenko Bars" (this is not something I have ever used or installed). Ninjatrader Support tested this BarsType for over an hour, but couldn't reproduce the issue.

So it isn't reproducible with a specific third-party indicator or across different machines/environment. The issue only appears from 8.0.27.0 onwards (and all releases since then) and only affects a minority of users. Nobody has an issue with 8.0.26.1.

I might DM affected users and ask for some environment information.
- Version of Windows being used. (might it be a windows 10 issue?)
- Screen Resolution (might it be a 4K issue)
- Number of CPU cores
- Graphics card
- Laptop/Desktop
- Antivirus software

I'm convinced this is a Ninjatrader issue rather than a third party issue. Just need to figure out why some environments cause the issue to manifest itself regularly and some don't.

[backtester831]

Besides the database change, I wonder what else is different in 8.0.27 vs. 8.0.26.1? I think 8.0.27 was also the first time the 32 bit version was removed. Maybe some other changes in the 64bit related to multithreading?

[QuantKey_Bruce]

You might be interested to know that the message itself happens when using the framework class ReaderWriterLockSlim, a class that NT uses internally but that few indicator developers use because it has kind of a narrow use case. The message occurs when there's already a read lock held, and another section of code tries to write lock the same mutex. If you'd like to know how to reproduce it separate from NinjaTrader use Microsoft's own example: https://learn.microsoft.com/en-us/do...ramework-4.8.1.

The question is, how is NinjaTrader code ever trying to get a write lock when it already has a read lock? And is there something that any indicator writer is doing that is leading to this situation happening or is it an inherent flaw? Someone would have to review NT's own code for the ReaderWriterLockSlim class usage to see where this is happening in order probably to go further with this and fix it or advise what it is specifically that indicator writers need to not do. That having been said, it sounds like you're saying kevinenergy that you can make it happen just scrolling around on an empty chart, in which case, that seems pretty clear it's something NT needs to take on at that point.

[jculp]

I updated to 8.0.28.0 over the weekend from 8.0.26, and got the WriteLock error for the first time today. Charts just stopped updating. DOM continued to update price. I use a 6-core CPU, 2 GT710 graphics cards, 6 monitors, lots of charts and 3 different bars types, products from several different vendors, and custom code, some of which includes drawing global lines. Never had a problem with it before the upgrade. At the same time (related?) my Rithmic connection failed, which has never been a problem before either.

After re-start, no errors (so far). Got me spooked now after reading this thread. If no one knows root cause, what's to prevent it from happening again at seemingly random times?

EDIT JUNE 22
Happened again this morning, about the same time, same instrument. Two curious things: DOM never stopped updating price, and after closing workspace, I could open charts normally, EXCEPT for the instrument (MNQ) that had been open and stopped updating. After closing NT8, could not re-start it until after system re-boot. Error msg said the Vendor.dll file was being used by another process, even 10 minutes later.

If the error were truly custom/vendor-specific, why does it lock up the instrument from charting with no indicators applied?

[Lancer]

I get the same NT chart lock ups and error message sometimes during fast market times when charts are lagging. Maybe that is your case as well. To test if your charts are lagging when you get the error, go here and download and install the ChartLagTime indicator script. Next time you get the error and your charts freeze (usually only the active symbol charts), see if you charts were lagging at that time. Might help troubleshooting.

[jculp]

Lancer - thanks for the tip. I may look into that, but for now I have reverted back to v.26 on my primary analysis machine which I use for prop account and trade copying. I am keeping a second machine at v.28 for my cash account. Using the same setup, I have never encountered the deadlock error on v.26. NT support insists that the problem is vendor or custom code, and they are probably right; but it seems apparent to me that they introduced some change after v.26 which is causing code that worked fine in 26 to error under certain scenarios in 28. And since it is intermittent - perhaps related to market velocity or other fast screen/render changes - I do not see a clear path forward to troubleshoot it. So I have reverted, which had its own challenges, since NT didn't make a clear path to downgrade the db back to what it was. But I am satisfied I have a stable environment for what I do now.

[PhilBeachBoy]

I was never able to get to the bottom of the issue despite very exhaustive testing and a process of elimination on custom code.

I downgraded to 8.0.26.1 and I am still using that release today.

I don’t use Kinetic.

I am having the same issues. I "upgraded" to 8.0.28.0 and am getting the same error message regarding "write lock cannot be acquired with read lock held, etc.", my cursor cannot address the screen and the system is effectively frozen. If I shut down Ninja, it will fail to reboot as it does not close out very memory intensive processes and will not restart until I then close those processes. The system keep freezing at random times and this problem has rendered Ninjatrader a platform that is not "Fit to task". I did try the many procedures here recommended by Ninjatrader support and they clearly do not address what the core problem is with multithreading, the migration to SQL Lite from SQL CE, the replacement of 32/64 bit functionalities with sole 64 bit support or some other thing or combination of things that were added or removed or changed in the upgrade.

Just today, I again contacted platform support and they suggested that what is needed to do is to not run so many indicators on so many charts, especially of the same futures contract. I responded to them that was not relevant as to test things, unsuccessfully, I have been running a new workspace with just one chart with several indicators and it still crashes the same way. It is easy to respond that it is a third party add-on issue and thus, the vendors' problem. Almost all users have few or many third party add-ons. This is the reality of how this platform is used by the traders so efforts to resolve or solve such big crippling platform issues should be done with a collaborative spirit as nearly every example of Ninja on customers' computers have evolved into hybrid organisms that blend original Ninja platform features with add-on capabilities.

When you consider what this platform is designed to do, to use real money at risk and all the challenges of deploying a profitable approach, it becomes a matter of serious consequences in not addressing such problems and steering resources towards a real fix. I am hearing that NOBODY is having issues like this write lock/read lock freezing with version 8.0.26.1 and I would think to roll back to such a version that I could trust my trading capital with.

[kevinenergy]

Hi Phil.

Ninjatrader are in denial about this problem. Most people are just manually installing the certificate and staying on 8.0.26.1

I've attached the cert.

After you have installed 8.0.26.1,
Close Ninjatrader, then replace the "ca.pem" file in:


C:\Program Files (x86)\NinjaTrader 8\bin
C:\Program Files (x86)\NinjaTrader 8\bin64

with the one in the attached zip file.

Then restart Ninjatrader and enjoy a crash-free experience on 8.0.26.1

[jculp]

kevinenergy = thanks for uploading the cert. I did not realize a manual install was an option, but I will certainly take advantage of it.

[Opie5000g]

I am having these same crashes every day and would like to try 8.0.26.1, where can I download that version?

[kevinenergy]

Its too big to attach to the Forum, but you can grab it from my OneDrive here: https://1drv.ms/f/s!Ajlj7dTld4OYht4K...ZrbhQ?e=qgJtFT

[backtester831]

Hi Phil.

Ninjatrader are in denial about this problem. Most people are just manually installing the certificate and staying on 8.0.26.1

I've attached the cert.

After you have installed 8.0.26.1,
Close Ninjatrader, then replace the "ca.pem" file in:


C:\Program Files (x86)\NinjaTrader 8\bin
C:\Program Files (x86)\NinjaTrader 8\bin64

with the one in the attached zip file.

Then restart Ninjatrader and enjoy a crash-free experience on 8.0.26.1

You're a legend!

[Opie5000g]

Its too big to attach to the Forum, but you can grab it from my OneDrive here: https://1drv.ms/f/s!Ajlj7dTld4OYht4K...ZrbhQ?e=qgJtFT

Thank you so much. I have been dealing with the freezing charts for way too long. It happened several times every day even after several clean installs. I followed your advice with the 8.0.26 version and have now gone 2 days without one freeze.

[kevinenergy]

My pleasure I'm glad it has helped. Trading is too important to have the platform crashing. Capital is at risk.

I had exactly the same experience, crashes multiple times per day but rock solid stable after going back to 8.0.26.1

It is very unusual that this issue comes up for only a minority of users. But for those users the crashing happens regularly.


Is anyone from Ninjatrader Support reading this thread? Do you even care?