Crash after Error Code c0000005

[Teksonik]

Anyone else get these errors periodically? Windows 10 Latest CWBL.

 

 

 

[Lord Tim]

It looks like it's in the plugin itself, but you'll see a link to a .dmp file in that error box - that file is something that you should be getting over to Cakewalk Support and the plugin vendor to see exactly where the problem is happening.

[Teksonik]

Yes that's obvious since it says" Obsession.dll-Crash Detected!" right in the image.

I already sent the files to the developer before posting here but that's not what I asked.

I asked if anyone else periodically experiences this issue. This is not the only plugin that has generated a c0000005 crash in Cakewalk, while those plugins work without issue in the other four DAWs I use.

I'm looking to build a list of plugins that have or can generate the error so I can test them as well.

[Lord Tim]

Then, no. I haven't.

[Glenn Stanton]

when i see it, i re-run my redistributables installer 🙂 

[User 905133]

1 hour ago, Teksonik said:

. . . it says" Obsession.dll-Crash Detected!" right in the image.

I already sent the files to the developer before posting here but that's not what I asked.

I asked if anyone else periodically experiences this issue. This is not the only plugin that has generated a c0000005 crash in Cakewalk . . . .

If you look through the forum, you will see that the general purpose c0000005 crash error has come up quite a bit.  It might be hard to find though, because it usually shows up as a picture posted by a user as opposed to text which can be searched.**

I have seen it myself as well as others mentioning it.

When I get it on my PC, I take it as a sign that I need to problem-solve the issue.  

6 minutes ago, Glenn Stanton said:

when i see it, i re-run my redistributables installer 🙂 

Yup! Part of problen-solving the issue. 

**CORRECTION:  I was wrong. This search produces 2 full pages of hits. 

Edited March 21, 2023 by User 905133
to post a correction

[bitflipper]

On 3/21/2023 at 8:36 AM, Teksonik said:

Anyone else get these errors periodically?

If you mean the literal definition of "periodically", meaning at consistent intervals, then no. If you're asking if anyone's ever seen an access violation, then yes, it's  unfortunately not uncommon. Especially in early builds, which is why you're far less likely to see them at version 1.1 than 1.0.

I understand that you're hoping to find some other plugins that frequently raise access violations and use them for testing, but unfortunately that's going to be an exercise in futility. It's always a bug in the software, in this case the specific DLL identified in the dialog, and it's something that only the plugin developer can fix. Your  only option is to stop using it until the dev releases a new version.

[Teksonik]

On 3/22/2023 at 11:43 AM, bitflipper said:

If you mean the literal definition of "periodically", meaning at consistent intervals, then no. If you're asking if anyone's ever seen an access violation, then yes, it's  unfortunately not uncommon. Especially in early builds, which is why you're far less likely to see them at version 1.1 than 1.0.

I understand that you're hoping to find some other plugins that frequently raise access violations and use them for testing, but unfortunately that's going to be an exercise in futility. It's always a bug in the software, in this case the specific DLL identified in the dialog, and it's something that only the plugin developer can fix. Your  only option is to stop using it until the dev releases a new version.

Sorry, I don't come here often so didn't see your reply until now.  The battle of who is at fault when a certain plugin doesn't function with a certain DAW will rage on in perpetuity. The DAW developer will blame the plugin developer and the plugin developer will blame the DAW developer. It's been that way since both have coexisted. 

When the plugin functions just fine in all other DAWs is it the fault of the plugin or the DAW  where it doesn't function?

I know DAW loyalty always plays a part (it can't be the DAW's fault because it's my favorite DAW and so on).

So to reiterate the part of my post you failed to quote:

"This is not the only plugin that has generated a c0000005 crash in Cakewalk, while those plugins work without issue in the other four (now 5) DAWs I use".

So you can turn a blind eye to the issue in order to protect your DAW but that serves no one including yourself.

Oh and the "literal definition" of periodically is:

pe·ri·od·i·cal·ly

from time to time; occasionally.

[bitflipper]

I'm not battling anyone, nor am I blindly defending my preferred DAW. Just basic troubleshooting while trying to avoid a classic causation vs. correlation logical fallacy. Let me explain my reasoning, and feel free to correct any logical errors I may make in the process.

Let's start at the beginning, by looking at what a c0000005 error is, and how it comes to be raised. 

This particular error code represents an access violation, which means the software has attempted to write to an address location that it does not have permission to write to. Usually, this is the result of an uninitialized pointer, a variable that contains a memory address but that hasn't been given a value. Because all variables initially default to zero, the pointer is pointing at address 0. Although 0 is a valid memory address, it's in a part of memory that's reserved for the operating system kernel and cannot be written to by user applications. The O/S protects itself by refusing the operation and raising an error so that the offending application can deal with it.

How does a pointer get initialized? That's up to the programmer who wrote the code. That's why it's safe to assume that a c0000005 error is a bug in the code that raised it, and ultimately human error.

I apologize if you knew all that already, but it's important to understand how this error happens and why. The key concept is in your statement that "...This is not the only plugin that has generated a c0000005...". The salient point is that it was the plugin that attempted to write to protected memory, not the DAW. The error was raised by the plugin, not the DAW.

Granted, the plugin may have been referencing an invalid pointer that the DAW supplied it with, that's not impossible. However, any pointers passed to the plugin (e.g. input and output buffers) would be the same pointers the host passes to all plugins. If they were invalid, the DAW would crash every time you attempted to use any VST plugin. From a software developer's perspective, it is always the module's responsibility to validate arguments, and to never assume that the caller guarantees they are valid. Usually, that means the plugin will refuse the invalid pointer and notify the host that the call has failed, in which case the host would be tasked with processing the error. When this is the case, it won't be the plugin that was identified as the offending module in the dump, but rather the DAW. But if the stack dump shows a plugin's DLL as the failing module, then that's where the problem originated.

 

[Teksonik]

2 hours ago, bitflipper said:

Let's start at the beginning

How do you explain the fact that these same plugins do not generate the same errors in any of other 5 DAWs  I own on the same system ? Could it be some DAWs are more robust and some more fragile? For example the plugin in the screenshot in my first post has worked flawlessly in all the other DAWs  I own.

When a plugin only has issues with one DAW whose fault is it? Like I said this debate has and will rage on as long as DAWs and Plugins exist. Again, each developer will blame the other. If I bring the issue up at the plugin's forums the fans there will likely blame the DAW so  round and round we go. 

If there is an issue with CbB and it's not fixed in the last update then we're stuck with it so it would benefit us all to make sure that bug is squashed before its too late.

I was a private beta tester for Cakewalk back before all the buyouts and takeovers and have been a tester for many of the biggest names in the business so I'm willing to help but it's probably too late for CbB. 

If the issue carries over to to the new Sonar then we'll just have to deal with it then.....if we decide to stick around under the new scheme.

 

[Terry Kelley]

2 hours ago, bitflipper said:

I'm not battling anyone, nor am I blindly defending my preferred DAW. Just basic troubleshooting while trying to avoid a classic causation vs. correlation logical fallacy. Let me explain my reasoning, and feel free to correct any logical errors I may make in the process.

Let's start at the beginning, by looking at what a c0000005 error is, and how it comes to be raised. 

This particular error code represents an access violation, which means the software has attempted to write to an address location that it does not have permission to write to. Usually, this is the result of an uninitialized pointer, a variable that contains a memory address but that hasn't been given a value. Because all variables initially default to zero, the pointer is pointing at address 0. Although 0 is a valid memory address, it's in a part of memory that's reserved for the operating system kernel and cannot be written to by user applications. The O/S protects itself by refusing the operation and raising an error so that the offending application can deal with it.

How does a pointer get initialized? That's up to the programmer who wrote the code. That's why it's safe to assume that a c0000005 error is a bug in the code that raised it, and ultimately human error.

I apologize if you knew all that already, but it's important to understand how this error happens and why. The key concept is in your statement that "...This is not the only plugin that has generated a c0000005...". The salient point is that it was the plugin that attempted to write to protected memory, not the DAW. The error was raised by the plugin, not the DAW.

Granted, the plugin may have been referencing an invalid pointer that the DAW supplied it with, that's not impossible. However, any pointers passed to the plugin (e.g. input and output buffers) would be the same pointers the host passes to all plugins. If they were invalid, the DAW would crash every time you attempted to use any VST plugin. From a software developer's perspective, it is always the module's responsibility to validate arguments, and to never assume that the caller guarantees they are valid. Usually, that means the plugin will refuse the invalid pointer and notify the host that the call has failed, in which case the host would be tasked with processing the error. When this is the case, it won't be the plugin that was identified as the offending module in the dump, but rather the DAW. But if the stack dump shows a plugin's DLL as the failing module, then that's where the problem originated.

 

That and girls. I've had many an access violation.

Seriously, great overview of the issue. C0000005 is frustrating to deal with. And there have been times where the developers were able to point to the specific issue and contact the VST company. It's not silence like some believe.

Edited June 7, 2023 by Terry Kelley

[msmcleod]

14 minutes ago, Teksonik said:

How do you explain the fact that these same plugins do not generate the same errors in any of other 5 DAWs  I own on the same system ? Could it be some DAWs are more robust and some more fragile? For example the plugin in the screenshot in my first post has worked flawlessly in all the other DAWs  I own.

When a plugin only has issues with one DAW whose fault is it? Like I said this debate has and will rage on as long as DAWs and Plugins exist. Again, each developer will blame the other. If I bring the issue up at the plugin's forums the fans there will likely blame the DAW so  round and round we go. 

If the crash is in the plugin DLL, then 99% of the time it's the plugin's fault.  If it was the DAW (and sometimes it can be), then it would happen on far more plugins than just that one (and by far more I mean most).

All VST plugins must conform to the VST2/3 spec, which is a list of functions they must implement, and some they may decide not to fully implement, but must refuse gracefully. 

For the most part (i.e. unless the spec says otherwise),  these functions can be called at any time and in any order.  In reality, a lot of plugin developers assume you will never call function "B" before you've called function "A".   Their reasons may be that function B might not return reasonable results until you've called function A.  However, that doesn't mean you shouldn't be able to call function B before function A, and it certainly shouldn't crash if you do.  It should just fail gracefully, or ignore it silently.

It maybe that the other 5 DAW's only ever call function B after they call function A, so the plugin developer might assume that's the norm and never bother dealing with any other circumstance... but unless they've tested with every DAW / audio editor / NLE, that's a big assumption.

There are many different areas plugins can be called from, such as:
- loading the plugin presets, either internally in the plugin, or from an external file
- binding automation parameters
- setting the initial automation value

The order in which parameters can be read/written to can be completely arbitrary - i.e. it could be in parameter order, automation lane order etc... and the order of other calls such as setting the tempo, or other system wide settings could happen at any time. The plugin shouldn't make any assumptions about ordering.  When they do - that's when crashes happen.

As for the DAW vs Plugin blame game... put it his way... I have over 2000 plugins, and maybe 3 or 4 crash on me. 

There are probably 10,000+ plugins out in the wild. Should a DAW manufacturer test 10,000+ plugins to make sure every one of them works?  And test them twice for both VST2 + VST3?  And then you hack the code to make one plugin work, and that causes another bunch of plugins to crash... it's like a game of wack-a-mole.

On the other hand, a plugin developer has to support maybe 20-30 DAW's.  Should the plugin manufacturer test their plugin on every one of them? 

The plugin dev doing the testing obviously is the more reasonable scenario, but with 20+ DAWs?  How much will that cost them to do that,  and therefore you?

The plugin dev will likely pick 5 DAWs at max - realistically only 2 or 3... and if that doesn't happen to be the DAW you're using, there's a possibility there will be issues.

[Teksonik]

3 minutes ago, msmcleod said:

If the crash is in the plugin DLL, then 99% of the time it's the plugin's fault. 

The plugin dev will likely pick 5 DAWs at max - realistically only 2 or 3... and if that doesn't happen to be the DAW you're using, there's a possibility there will be issues.

All you're doing is regurgitating the same old lines.  I get it, this is a DAW forum so defense of DAW mode is to be expected. 

As for your "The plugin dev will likely pick 5 DAWs at max - realistically only 2 or 3", that's simply not true. Every developer I've ever tested for (including Cakewalk back in the Z3ta+2 days) tests in as many DAWs as possible. That's one reason to have a beta team. Each member brings different DAWs to test with and different methods of testing. I test in 6 DAWs alone and the other testers and people who write the code test in most all of the others. Of course there are some obscure, discontinued, or outdated DAWs that may not get tested but their user bases are so small that it's usually not an issue. 

No DAW (or plugin) is 100% bullet proof not even CbB. To ignore potential issues serves no one...not even yourself.

Like I said when a plugin I use only has issue in one DAW then I'm going to report that issue to the DAW developer. In this case I never received a response so make of that what you will.

[bitflipper]

1 hour ago, Teksonik said:

All you're doing is regurgitating the same old lines.

Logic and Reason have left the chat.

[Noel Borthwick]

On 6/7/2023 at 4:52 PM, Teksonik said:

All you're doing is regurgitating the same old lines.  I get it, this is a DAW forum so defense of DAW mode is to be expected. 

As for your "The plugin dev will likely pick 5 DAWs at max - realistically only 2 or 3", that's simply not true. Every developer I've ever tested for (including Cakewalk back in the Z3ta+2 days) tests in as many DAWs as possible. That's one reason to have a beta team. Each member brings different DAWs to test with and different methods of testing. I test in 6 DAWs alone and the other testers and people who write the code test in most all of the others. Of course there are some obscure, discontinued, or outdated DAWs that may not get tested but their user bases are so small that it's usually not an issue. 

No DAW (or plugin) is 100% bullet proof not even CbB. To ignore potential issues serves no one...not even yourself.

Like I said when a plugin I use only has issue in one DAW then I'm going to report that issue to the DAW developer. In this case I never received a response so make of that what you will.

No, he's not regurgitating "old lines". He's giving you a reasonable explanation of why plugin crashes occur, but you are not prepared to listen to a reasonable explanation. We have no interest in being defensive about crashes and fix any issues in our software promptly as many will attest. (that are actually ours)
Read this article which explains why plugin crashes occur and how to diagnose them. 99% of plugin crashes occur because the vendor has not tested them with all the combinations of operations that occur in a DAW. Also many of the smaller vendors tend to test their plugins in their favorite DAW and call it a day. Another common thing I've seen over the years is that some vendors only test in Mac DAW's so completely skip Cakewalk.
The advice in the article I posted is the best way to get a resolution, if you must use a plugin that crashes. If you send us the dump we can sometimes pinpoint the crash and follow up with the vendor but most of the time only the vendor can solve it, and it is indeed the vendor's responsibilty to investigate first and contact us later if they actually claim its an issue with the host. Cakewalk has been around more than 30 years and our VST infrastructure is very stable (even Steinberg has commented about this)

 

 

[Byron Dickens]

Yeah. And I seem to recall an issue with Steinberg's e-licenser that apparently only affected Cakewalk that turned out to be Steinberg's fault and the next release of the e-licenser fixed it.