vst2xscanner.dmp (2.9 MB)
Apologies for the late response, here’s the file. Thank you
Thanks for the dump file but I don:t have my debugging tools at hand right now. I will have a look latest by Monday morning. Thank you for your patience
Hi @mrdixon, indeed, it is the same issue with you, the scanner is stuck within that atio6axx.dll.
So please also follow the advice given earlier here in this thread.
@Wallander, it appears to be a threading issue. The main thread of the scanner is calling into the atio6axx.dll and is then deadlocked waiting for another thread that was created by the AMD driver. Do you know of anything where your code is actively creating OpenGL threads or something?
We don’t. NotePerformer 3 doesn’t spawn threads in normal operation. OpenGL is only called from the host’s main thread at plug-in instantiation and from VST2 Editor calls, which none are made by vst2xscanner.exe.
Our trial version may produce message boxes in a separate and temporary thread. It’s necessary to avoid stalling VSTAudioEngine since the message box isn’t focused over Dorico. While that would be a potential source-of-error, the messages boxes are produced from the resume() VST2 function, which vst2xscanner.exe never calls. That’s intentional, as we don’t want message boxes during plug-in scanning.
For reference, we received the AMD Radeon system and were able to reproduce the bug. Thanks for the assistance in this.
While the problem remains in the driver, we’ve found a workaround to keep NotePerformer 4 from triggering the problem.
7 Likes
OK, So I just got a new windows machine with an AMD card, and I had this same problem again. Dorico was just hanging when it tried to scan NotePerformer.
Unfortunately, I just tried the “fixes” listed during the last time I posted here, which basically meant I spent a few HOURS uninstalling graphics drivers, rebooting, re-installing drivers, re-installing NotePerformer, etc. That’s when I decided to create minidumps of each different graphics driver version and post them here in hopes of some help. When I returned to this post, I was amazed to find an actual solution was available.
I think @Antonio_Freixas deserves a medal (or at least a free beer). Excellent debugging skills, my friend! I was so happy to see he figured out that bypassing the scan of NotePerformer (or forcing it to work with a junk graphics driver) just once allows the thing to work after that. Amazing.
I was also glad to see @Wallander joined the conversation and offered up the backdoor workaround and is also taking this bug into consideration for NotePerformer 4. Kudos!
That being said, being a professional software engineer myself of over 30 years, I was super disappointed that @Ulf and the Dorico team have just had the same response to everyone who has had this problem (across multiple threads) which boils down to: It’s not our problem because it’s an issue with a third-party plugin and a graphics card. That’s just nonsense and here’s why:
First, it IS your problem because it’s affecting YOUR customers. Without customers, you have nothing.
Second, previously when I said it was a Dorico problem because this all works fine with Sibelius, I was told that the fact it works with Sibelius proves nothing. Oh, but it does. The fact that it doesn’t work in the Dorico/AMD scenario is specifically because Dorico uses a command line utility to scan VSTs. It’s not required to, but that’s the way it was built, by the Dorico team.
But I’m not saying this is 100% a Dorico problem… I’m pretty sure the blame (if we must assign it) is spread between Dorico and NotePerformer. As I understand it, Dorico is scanning VSTs via it’s command line scanner at startup outside of a windowed environment. This is probably not the best choice since VSTs almost always have some sort of UI component. That being said, most VSTs do not require a UI/Windowed environment on load and only require a windowed environment when the UI is requested. In the case of NotePerformer, I suspect it’s the fact that it wants to show a graphical splash screen on load that is causing the issue. (I could be wrong, this is just a hunch). So really, it’s both pieces of software that could be seen as the cause, but… who cares?
The fact is, @Wallander has offered a workaround and is trying to correct this issue in the next version. Dorico, however, is just ignoring the problem and asking people to do a support meme (did you try rebooting?). Come on.
I’m not even saying you need to actually fix the issue (which would probably be simply building the VST scanning into the create/open screen of Dorico and not in a command line tool.) There are definitely other ways to help Dorico customers deal with this problem from the Dorico side.
For instance, you already have an allow/block list inside of Dorico in it’s VST configuration screen. Oddly, this never shows NotePerformer and I’m not sure why. At any rate, if NotePerformer showed up there, you could simply add an option to skip the scanning of individual plugins. This would allow users to workaround any plugins that may be problematic to the scanner.
I took 7 minutes and mocked this up for you. (see attached).
So, I’m sorry for the rant, but it’s very disappointing to see how little the Dorico team has done to try to debug/reproduce/fix this issue for their customers.
FYI, you can buy a mini pc with an AMD card that would reproduce this issue for less than half the price of a Dorico Pro license.
For the record, I think we’re crashing not just the scan but the VstAudioEngine in Dorico, too. It only goes unnoticed because the crash occurs when Dorico is shut down.
I also want to add, the crash only happens because we’re bypassing normal protocol for plug-ins in Dorico. We’re doing a hack (of sorts) that makes going between scores a no-delay operation. Consequently, NotePerformer isn’t unloaded until Dorico is shut down. At which point, this particular driver has invalidated the OpenGL context, fails to account for it, and crashes when we explicitly ask the driver to clear the context. While the driver is at fault for having this vulnerability, it only happens because of NotePerformer. There’s nothing (ordinary) that Dorico can do to avoid it, and it would be almost impossible for Dorico to debug this crash even with access to an AMD machine because it occurs at an OS level, possibly even after Dorico has exited, cleared all resources, and closed all threads.
7 Likes
Sure, I’ll take the medal! 
My amazing debugging skills involved noting that NotePerformer had been working fine with my up-to-date AMD driver, so I realized the problem was only with the scan. Once you get past the scan, you’re home free. and you only need to do a scan when you have new VSTs.
You left AMD out. It’s mostly a NotePerformer/AMD driver issue. When I first installed Dorico and NotePerformer, I had no problems. My NotePerformer version has not changed, but my AMD driver version has.
It looks like @Wallander understands why the driver is crashing and it’s based on a NotePerformer hack, so the responsibility for a fix is on AMD and any provisional work-around should come from NotePerformer.
Fair enough. Seems like I misunderstood the underlying issue and now that @Wallander explained it a bit more, I see that the root cause lies between NotePerformer and AMD.
I still think @Ulf and Dorico could be a bit more empathetic to customers in this situation and not just say “not our problem”. And I still think building in “escape hatches” like the one I mocked up are always a good idea when dealing with 3rd party plugins.
Thanks for shedding even more light on this topic @Wallander and @Antonio_Freixas !
And my apologies @Ulf for being so harsh… but you guys do have some room to improve.
Jonathan, I understand the frustration you have felt at running into this issue, and I appreciate the feedback that we could always do more to help our customers. Certainly we do our very best to help our customers as much as possible, and Ulf in particular routinely goes above and beyond the call of duty to help individual Dorico customers, including taking time out of his day to do remote debugging and screen sharing sessions with users.
Particularly given that Ulf is not employed by Steinberg to provide customer support (none of the Dorico team members who post here on the forum are in the support team, in fact), I think this demonstrates an extraordinary level of commitment to customer care.
Yes, we could go even further above and beyond the call of duty, you’re right, but don’t forget that there are many thousands of Dorico users and just a handful of us at Steinberg working on the software, so there is an issue of scale at play here.
Nevertheless, this specific issue is well-understood, and there is good information available here on the forum to help work around it. I hope that you will find things smoother sailing from this point onwards, but if you don’t, rest assured we will be here to support you.
10 Likes
If I am correct that @Ulf is working in Germany, and if I calculate the time difference correctly, I wonder when he gets to sleep, as I have seen responses from him posted close to midnight. I am in awe of–and grateful for–the level of support given by Team members here in addition to the commitment of fellow users to helping each other.
8 Likes
To add on Daniel’s comment: Actually no, I can’t go any further, because if I did, I would just break down. And @Doklovic , in your professional engineering career, how much time did you spend of your private spare time - also on weekends and holidays - on supporting customers? I may be accused of many things, but please do not accuse me of a lack of empathy for our customers.
11 Likes
@Ulf @dspreadbury Please know that I am only posting here because I like your product and I want your team to succeed. As you’ve both stated, Ulf puts in a lot of extra hours on nights and weekends and in a lot of cases, bends over backwards to help customers on this forum go through technical debugging of their issues. I’m not saying otherwise. What I’m trying to point out is that this may not actually be the best thing to be doing.
First off, Ulf needs to have some work/life balance. We all do. It just makes for happier people. Apart from that though, I feel like this is a community forum where we can come to seek out answers to questions that other customers may have encountered. With that in mind, I expect to see a lot of back and forth, as well as some trial and error from customers on here. When it comes to Steinberg employees chiming in, I feel that has a more “official” response to it.
You are representing the company and your responses are seen as “this is Steinberg and/or Dorico’s stance”. I’m just saying I guess I expect the responses from Steinberg on here to be less debugging with individuals and more measured overall larger problem solving.
My expected response when I first posted here would have been something like:
"Hello X! Thanks for posting on our community forum. We have had many customers with a similar issue, but unfortunately we have not yet found a root cause. We believe it is a video driver issue, and some customers have had luck downgrading and/or upgrading their driver versions.
We have already reached out to AMD and the makers of NotePerformer and will try to debug the issue with them when we get a response. We will post any updates here. If you’d like to walk through the specifics of your issue and try to debug it with our support team, they can be reached here:<> …"
That kind of response actually makes me feel better about this issue. It gives me some things to try, it let’s me know that Steinberg is aware of the issue, has narrowed it down to 2 other companies and is actively working with them to find a solution. It also let’s me, as the customer, off the hook in terms of being a middle-man between 3 companies when I don’t know the inner workings of any of their software. Finally, it also gives me the option of contacting “official” support if I really want to walk through this with somebody.
It may seem like this is less personal by not being hands-on and walking each customer through debugging, but it’s actually less frustrating for everyone and the time it takes to walk each individual with this issue through the same steps can be spent reaching out to the other companies.
So basically, I truly am sorry if I offended either of you. That was not my intent. I really enjoy using your software and I see myself using it for a long time, which is why I’m pointing any of this stuff out. I’m trying to let you know how I feel as a customer in this situation. And yes, I have had a career full of experience directly supporting customers and/or external developers (weekends and all) so I understand and appreciate the dedication. Thanks!
I think I understand your point. The problem with this expectation is that this development team is quite small. If music copying were a much bigger market, they could afford to hire more people to handle different jobs, and let their large user base figure out more stuff among themselves (like e.g. Apple). But the reality is more like these are our genius friends down the hall, all working on this project in one room.
And Steinberg itself seems to be lacking with customer support, from what I’ve heard on here. I can only be grateful that Steinberg has seen fit to give this (largely ex-Sibelius) team the business opportunity to make this project happen at all.
3 Likes
Hi @Doklovic , okay, peace on earth. I do understand and appreciate what you are saying. In an ideal world, yes, I would hunt down every issue and follow up on it, but in the real world this is simply not manageable, I would be spending most of my time just doing that. Please understand that at a certain point we have to make a cut and say: “Sorry, this is not our problem, please follow up with 3rd party”. And also as Arne explained, in this case there wasn’t anything that we could debug further on Steinberg side. And with the help of the community we do have a workaround now as well, plus the fix with NP4 from the developer. So in the end all is good, I would say.
6 Likes
@Wallander, for what it’s worth, I own a Radeon RX6800, installed after installing Noteperformer on my Windows machine.
I just ran into the bug after having to clean the VST cache to scan for a new plugin.
- The Create C:\np_use_software_rendering.txt fix didn’t work for me. Maybe I didn’t do it properly.
- Had to switch the driver to the Microsoft Basic Display Adapter as suggested by @Antonio_Freixas
Good news is that it’s easily solvable with those fixes. Thanks everyone for helping solve this issue.
1 Like
I got the same hang on a brand new Windows 11 PC with a Ryzen 7 5700g APU and no dedicated graphics card. And no Adrenalin software, as far as I am aware.
Hi @Nickie_Foenshauge , if it is true that you don’t have Adrenaline software, then please follow the description in my earlier posting and provide me the corresponding data, so that I can take a deeper look. Thanks
Hi Ulf.
I fixed it by following Antonio Freixas suggestion. I just wanted to let you know, that it is not exclusively an Adrenaline issue, because I never installed Adrenaline and I can’t find it anywhere on my PC. But, let me know if you still want the data. I expect I will be able to reproduce the hang by Clearing the Audio Engine Cache.
Hi @Nickie_Foenshauge , yes please, I’d like to find out what else can cause NotePerformer to hang our scanner. Thanks for your effort