Version 8.1.2 freezes chart and keeps compiling forever

[benJephunneh]

I am having huge issues with this latest release. So, if I save off my \Custom folder and uninstall, downgrade, and restore my \Custom folder, all is well? I am most concerned with my custom code, templates, and workspaces. I can save these off and restore, just wondering if there's a documented process for backing down a level. I see many of you have downgraded. Any advice would be greatly appreciated.

Backing up just the /Custom folder won't save /workplaces and /templates. Those are in the /NinjaTrader 8 parent folder. The folders should be untouched in the process, but don't let that stop you from making the backup. My backup consists of /workspaces, /templates, /AddOns, /Indicators, and /Strategies, but you could grab the whole /NinjaTrader 8 folder, to make it easy.

Backup, uninstall, reinstall, start NT, and you should have only to recompile to get back up and running without needing to restore from backup.

[cls71]

Same problem. I have had to reinstall the previous version. It is impossible to compile at 8.1.2.1, it never ends and Ninjatrader freezes.

[QuantKey_Bruce]

It's not a complex situation - NinjaTrader undertook something ambitious - something I'm glad they decided to tackle even if it has a few speed bumps to get there - and that is, they upgraded C# to a newer version (new compiler Roslyn) and some of the 3rd-party components, including the Actipro Syntax Editor in NinjaScript Editor to a newer version. This also impacted Agile.NET which is used for software protection. Predictably, that didn't go completely smoothly and there are some things to work out. While it's easy to say there should have been more testing, in some cases, it isn't possible to know all of the interactions until the software gets some exposure "in the wild". So, if you would like to stay on the "stable" build instead of the "latest" build, drop back to 8.1.1.7 which is before the major changes that happened to the compiling internals in 8.1.2.x. Give it a minor build or two to get these things sorted, then try again when the dust has settled.

[benJephunneh]

It's not a complex situation - NinjaTrader undertook something ambitious - something I'm glad they decided to tackle even if it has a few speed bumps to get there - and that is, they upgraded C# to a newer version (new compiler Roslyn) and some of the 3rd-party components, including the Actipro Syntax Editor in NinjaScript Editor to a newer version. This also impacted Agile.NET which is used for software protection. Predictably, that didn't go completely smoothly and there are some things to work out. While it's easy to say there should have been more testing, in some cases, it isn't possible to know all of the interactions until the software gets some exposure "in the wild". So, if you would like to stay on the "stable" build instead of the "latest" build, drop back to 8.1.1.7 which is before the major changes that happened to the compiling internals in 8.1.2.x. Give it a minor build or two to get these things sorted, then try again when the dust has settled.

If this is to me, I think you're misunderstanding me. Of course the software has bugs. It's software. I'll use buggy software all day long and find ways to help the developers solve the issues, if I can. What is off-putting to me is NT's response when people bring up the issues.

If the typical NT responses are genuine, and they really are learning about all these bugs for the first time such that they need me to walk through the code for an indicator that plots the sum of 2 and 2, and they need my trace files, etc., then I will conclude they don't do enough testing and/or they don't do the correct type of tests. Two new critical, work-stopping bugs with v8.1.2 would likely have been found with very little testing.

If the responses are not genuine, and they're perhaps trying to play off that the software has bugs, I still have a problem. The truthful response would be, "We're aware of the issue and a bugfix is forthcoming. In the meantime...." I cannot recall, however, a single time NT has said something along those lines in their initial response. Wouldn't such a response build more trust from the users than the feigning of ignorance? And shouldn't this have been labelled as a beta release, with the usual warnings? (Perhaps it was. I only scanned the changelog.) I'll jump on as a beta tester and you wouldn't hear a single complaint from me about bugs. I'd create tickets, describe my workflow, the machine state, attach my log, etc. and be on my way. Probably close to 100% of the posts in this thread would not have been made if this beta release was properly labelled.

[NinjaTrader_ChelseaB]

Hello benJephunneh,

When our team encounters bugs or issues and we can reproduce, we do immediately report these to our development.

With some issues, we may not be able to reproduce and need further clarification on specifically the cause or what is effected and need clear simplified (reduced) steps to reproduce before we are able to make a report to our development. This often means confirming version number and getting the sequence of events from the log and trace, and sometimes output from prints that can clearly show the issue.

Our QA team does work diligently to find issues before a release, and they find a lot, but not everything can always be caught before a release goes out.
After a release, it's up to the Engineering Support team to report any issues our users find with clear reproducible steps, and we do this by investigating, gathering enough information for us to reproduce on our end.

[benJephunneh]

Hello benJephunneh,

When our team encounters bugs or issues and we can reproduce, we do immediately report these to our development.

With some issues, we may not be able to reproduce and need further clarification on specifically the cause or what is effected and need clear simplified (reduced) steps to reproduce before we are able to make a report to our development. This often means confirming version number and getting the sequence of events from the log and trace, and sometimes output from prints that can clearly show the issue.

Our QA team does work diligently to find issues before a release, and they find a lot, but not everything can always be caught before a release goes out.
After a release, it's up to the Engineering Support team to report any issues our users find with clear reproducible steps, and we do this by investigating, gathering enough information for us to reproduce on our end.

Thank you for the response. The process is not unfamiliar to me, and I understand that not every bug will be found in testing (and likely never, no matter the coder's diligence). Who's talking about finding every bug, though? And your QA team's inability to reproduce problems that take almost no effort to reproduce seems to indicate a lack of familiarity with the product, does it not?

Again, "Thanks for the comment. We're aware of the problem and a bugfix is forthcoming" is much more valuable than, "Interesting. So you're getting an error when you divide by zero? We've never encountered that error. Do you have Calculate set to OnBarClose? Could you send your simplified code and trace files for review?"

[kevinenergy]

Speaking as someone who was worked as a professional .NET Software Engineer for 20 years in medium-large sized businesses. Chelsea’s response below highlights everything that is wrong with Ninjatrader’s bug/issue triage system.

Reports are only made to development when the support team encounters bugs & issues they can reproduce. Until a reproducible example is available there is a firewall between support and development.

Sometimes issues come up that are non-deterministic. Non-determinism is a property of computer systems and algorithms which means that the same inputs or steps can have different results. External factors can cause inconsistent results such as hardware differences or external data. Or multi-threaded/concurrency issues which require perfect timing between two unrelated threads to reproduce an issue. Maybe the issue happens on a Ninjatrader install with a large database and a huge amount of stored historical data, but not on a clean install.

Clearly Ninjatrader is the type of application that might suffer from non-determinism with respect to live bugs and issues. There are so many external factors, realtime inputs, live data streams and hundreds of threads.

So it’s a lousy policy that there’s this refusal by development to look at any issues unless there’s reproducibility. This is developer laziness. Yes in an ideal world there would be a series of steps a dev can carry out to trace the problem, but we do not live in an ideal world - certainly not when concurrent programming is involved.

A statistically significant number of users reporting an issue should be enough to get some developer attention. Sometimes you just need to get a developer thinking about a potential problem and they will often instinctively know where the problem might be.

"prove there's a problem, or there's no problem" is a bad attitude on engineering teams and and it’s a policy that doesn’t serve Ninjatrader’s users or the business well.

When our team encounters bugs or issues and we can reproduce, we do immediately report these to our development.

Our QA team does work diligently to find issues before a release, and they find a lot, but not everything can always be caught before a release goes out.
After a release, it's up to the Engineering Support team to report any issues our users find with clear reproducible steps, and we do this by investigating, gathering enough information for us to reproduce on our end.

[QuantKey_Bruce]

kevinenergy I agree with what you are saying here. What would be great would be if the developers spent a small fraction of their time (1/2 a day a week?) directly providing support, so they are in an immediate understanding of what is happening. The idea that they're too important to waste time on petty user issues is simply a management mistake - in this view, the purpose of support is to protect the company from its users wasting its time. I would posit that the real value to the company inheres in the fact that all future revenues come from users, and users are in the best position to tell the company what it is they need and want.

[SilverSurfer1]

Hello Elirion. I'm getting the same "unable to load" messages that you are getting. I was at 8.1.2.1. I uninstalled it and reinstalled 8.1.1.7. Then I started to get the "unable to load" messages. How did you get out of this to a clean uninstall and reinstall?

[Leeroy_Jenkins]

"If I ignore it, maybe it will go away" – NT staff, probably

[wzgy0920]

I can confirm I have the same issue. It occurs randomly many times. Most recent occurrence, I waited 20 mins and the compiling was still stuck and it did NOT complete. Every time compiling gets stuck, I have to force close NT using Task Manager. This often leads to corrupted ...\Documents\NinjaTrader 8\bin\Custom\ folder resulting in the same error screenshot that @elirion posted when launching NT. To bypass this error, I have to rename the bin\Custom folder and run the NT installer and click repair. Then I have to launch NT, compile the native Ninjascript, close NT then copy my custom indicators/strategies back to bin\Custom folder then relaunch NT. This often results in my strategies templates getting deleted, so I always have to keep a bakcup and restore them. I do several times within 2-3 hours coding window. This issue should be highest priority. I hope NT can figure it out. I can't downgrade because I upgraded all my code to newer C# version.

[Balage0922]

I'd like to report the same issue, compiling takes forever since the latest release. Today NT started compiling right after startup and doesn't stop, restarts don't solve the issue. Strategy builder does not even open but freezes the control center and charts.

[NinjaTrader_ChelseaB]

Hello wzgy0920 and Balage0922,

I will add your impacts to our report.

[markl]

I'd like to add my voice to the chorus. I have been having significant problems with my code since upgrading to 8.1.2.1.
My problems are:
- Substantially increased compile times
- Invalid debug pdb files being produced by the NT Editor

I have gone as far as creating a fully clean, fresh install of NT and (with nothing but the default environment) NT continues to produce invalid (and huge) debug files.

Edit: I just rolled back to 8.1.1.7 and everything works again.

Also, To replicate the invalid pdb from a fresh clean install:
1) launch NT
2) open the Editor in NT
3) right click in the Editor and enable debug
4) click compile in the editor
5) click the VS launch button in the editor
6) in VS, set a valid breakpoint anywhere in any in indicator .cs file
6) in VS attach to NT.

In version 8.1.2.1 at step 6 Visual Studio will complain it is unable to load the symbols for the custom.dll
In version 8.1.1.7 at step 6 the symbols are loaded successfully.

[NinjaTrader_ChelseaB]

Hello markl,

Thank you for your note.

I've added your post to the impact for this issue.