Noel Borthwick

Crash dumps are invaluable to developers to pinpoint the source of crashes. Even when a crash isn't specifically DAW related, the dump file can sometimes provide information on the nature of the problem for further investigation.

Cakewalk products automatically intercept crashes and capture a minidump file whenever possible. However, in certain rare circumstances, a dump may not be saved if the crash happened very early in the startup process.

If asked by support or development, you can manually capture a crash dump using the Microsoft WinDebug tool using the steps below.

1. Install Windbg from the Windows Store. https://apps.microsoft.com/detail/9PGJGD53TN86
    
2. Find the location of your desktop in File explorer and copy the full path to the desktop from file explorer. (you will need this path below). We'll call this path <desktop-path>
   
   You can right click on the word "Desktop" and choose "Copy Address" to get the full path to the desktop.
   It should look something like this "C:\Users\yourname\Desktop"
    
3. Open Windbg and choose File | Start Debugging | Launch Executable.
    
4. Navigate to the Sonar exe file and open it. This will load the executable into the Windows debugger. You will typically see a window like this:
   
   
    
5.  In Windbg, now  press F5 to run Sonar once it has loaded or press the Go button.
   If it starts running successfully, you will see something like this. 
    
   
   
   After Sonar starts executing you may now perform the steps needed to reproduce your crash (or hang)
    
6. If the application crashes in WinDbg before the UI opens, then the crash is caused early during startup.
    
7. If WinDbg intercepts the crash, you will see a message in the WinDbg Command Window indicating the crash. If the app is hung then proceed directly to the next step.
    
8. Find the command prompt of Windbg at the bottom of the Command window and type this in the command prompt.
   .dump /ma "<desktop-path>\sonar.dmp"
   
   Replace desktop-path with the path you saved in step 2 above. Note the period before the dump command and also the quotes around the path. Press Enter when you are ready.
   
   See example below
9. If you entered the command correctly, WinDbg will save a dump file to the specified file on your desktop.

Finally, you may now zip the minidump file and send it to Cakewalk

Im not sure what you are doing wrong but the operation as shown in the video works perfectly in Sonar here.
New empty project
Go to Metronome bus and assign output to New Aux track
Arm aux track and start recording

Metronome records fine here.

Its much better to default to only having one project open because people forget and open multiple projects when they dont intend to.
If you end up opening 10 or 20 large projects then It will start paging to virtual memory and slow things down, potentially cause playback glitches etc.

This is fixed for the next release. It only impacted bus envelopes.

7 hours ago, Andrey_rbk said:

I have exactly the same problem. I registered a request (2036005) there in the message there is a dmp file and a project.

Here's the video.
https://drive.google.com/file/d/1FyezxSiPDThg0ru4D01oPNHD6B4bOKcQ/view?usp=sharing

@Andrey_rbk I downloaded your project and cannot reproduce the crash following your steps. I don't have all the plugins however.
Your dump file was not very useful unfortunately. It also references an older build. Please retest this in the latest build which is 109. Dump files should always be submitted using the latest version of the Program since the bug could already be fixed. If you can still reproduce it submit a new dump file.

Fixed for next release.

If you log a crash send the ticket number or PM it to me.

We’ll fix it. Thanks for reporting it.

most likely the save as dialog was hidden by something else. There is no way it won't launch - its a simple system dialog.

Its not that we select the device. Sonar enumerates all ASIO devices and these devices cause problems simply as part of being enumerated.
Its unfortunately how these wrapper devices work. I think the driver vendors have coded them only testing it with apps like Cubase so never see the problems. That is really the root problem here. The only solution is to not use them for now.

8 hours ago, Bass Guitar said:

I think this is the heart of the problem with this new version due to the overhaul of the graphics . I have a long list of weird behaviour issues that are all graphic related. 
Example : yesterday I was exporting and I unchecked a track’s microscopic selection box. 
But the track was included in the export?

I reopened the export dialogue and the box was still unchecked. It’s almost invisible to see. I had to squint and get closer to my monitor. So I re checked it and it didn’t show? It took 3 tries? I then unchecked it again and re exported the song and this time it worked. 
I also have had lots of issues working with the PRV where common moves Ive made a million times in older versions worked perfectly fine and now do not. 
It’s sad that they truly have done something wrong with the interface of this new version. 

You kinda just get used to the weirdness and carry on. Hopefully this will improve with time and by then we can also purchase a license. 

 

No its not related to "graphics".
We'll have to investigate but its likely something related to the mouse tool handling.

My response was to the OP. That error is a generic message and can be caused by different issues. It may not be related to disk space but something failed while writing the file. Did you try writing to a different drive?
 

I can reproduce this. It does seem to be an unexpected side effect of bypassing the rack. 
Its losing the assigned edit filter. No envelope data is lost just the selection.
We'll investigate it.

@profwacko Can you try this? First keep a backup of your project before saving or save to a new name afterwards.

• Select the clips you edited and open the AudioSnap palette. 
• Right click on the power button
• Choose "Clear all audiosnap markers"

Now save the project and see if it rectifies the problem
You can also select all clips in the project (CTRL-A) and do this operation. 
NOTE: This will delete all user edited audio snap markers. 

Sometimes after an error or with many edits the number of audiosnap markers can get huge in the hundreds of thousands. Clearing them like this will allow you to start over.

Its possible. We'll investigate it. If you change the folder to a non Chinese name does it work ok?

I've PMed Mark and Max a build with this fix to try.

Even though we're had a lot of changes to the UI code in Sonar I'd still be surprised if this is an issue thats entirely new to Sonar. I expect Cbb would have similar issues if its indeed Windows shuffling things around.

7 minutes ago, Mark Morgon-Shaw said:

Here's an observation from today.

I was working on a project this morning , all plugins opening where expected. No issues.

I had to take a break as our dog needs walking , and knowing I'd be gone for quite some time I switched my 3 screens off ( I do this manually as I use a performance power plan with no automatic sleeping or powering off peripherals ) but left Sonar running as I planned to continue on my return.

So I came back 90 minutes later, powered the 3 screens back on, waited for them to sort themselves out and lo & behold, the next plugin I tried to open was down in the corner like in the video I posted.

My console view which I normally place on the right hand monitor had minimised itself so I restored that up back to where it had been. This made no difference to where any plugins opened.

I tried various functions, like inserting new plugins from both the right click menu and dragging from the browser - all had the same result

If I inserted a new VSTi  with "Open Synth Properties" ticked, this also opened itself at the bottom with only the title bar visible.

Nothing short of dragging it to the right place seems to cure it once it happens.      

This narrows it down a bit. My theory that when you are turning off the monitors and turning them back on somehow windows is reconfiguring the setup that invalidates the last saved position Sonar has. So when you open its falling back to doing something wrong. 
If instead of opening the window immediately after this, you close Sonar, reload the project and then open a plugin window does it work then? If so it would seem to imply that Sonar is relying on some stale information.

3 hours ago, Mark Morgon-Shaw said:

8 hours ago, Noel Borthwick said:

The window is always sized correctly, just below the screen right?

Yes, just the menu bar visible - always on monitor 1

Can you elaborate? Does it only mess up the window position for plugins that were originally on monitor 1 or was  the plugin originally on Monitor 3 when you closed it? 
Just to reiterate only the last plugin position is saved. There is no mechanics to remember the last position of every plugin you close. When you open a plugin it looks up the static last saved position and places the window there. I suspect something is getting confused in that mechanism.

We don’t support these combo ASIO driver wrappers for this reason. We infact display a message saying its not supported.
Depending on what other ASIO devices you have, It interferes with how drivers are enumerated when the app starts up, leading to a feedback loop of sample rate change notifications.
Someday I plan to change our ASIO startup to only load/enumerate specific user selected drivers that might alleviate problems with drivers that cause side effects like this.

Any non reproduceable crashes require a crash dump to investigate. Read this FAQ. 

50 minutes ago, jeejeestudio said:

I Had 3 crashes yesterday, just using CTRL-D duplicating a clip.
I'm not sure what the culprit was. 4th time restart it went ok.

Thanks for the feedback guys. I’m pretty sure we can fix this easily once I root cause it. I’ll send a build to try once we have a proposed fix.
I unfortunately don’t have a 3 output video card to try this.

5 hours ago, Max Arwood said:

I had this happen too. I reported it. After I finally found the plugins under the bottom of the track view, I was relieved. I was going to look into it again the next day, but after I moved a couple of plugins where I wanted them to be, they started working correctly. It was the 1st time I opened a song after an update. It never happened again. Sorry I don’t have more info. 
edit - I think I accidentally found the pluggins by pressing F for full screen. 

Are you also running more than a 2 monitor config?

1 hour ago, Wayne Riggall said:

I have had the same issues mentioned here and it has continued over the last 2 days.

Some observations:

• In a track that I have recorded into, if I open a Plugin UI and then close it, I cannot open it again.
• I cannot locate any minimized windows at the bottom for any UI's that I may have minimized.
• If I add a Plugin to a track that I haven't yet recorded into, I can open the UI. If I close it and then try to open it again, it either very briefly appears then disappears, or it returns (no discernable pattern).
• If I delete the Plugin in a track I am working on and then add it in afresh, the UI opens but all settings are lost. (I am taking screen shots of each plugin setup for my recording notes document as a crude backup).
• When creating a new project, I am able to open Plugin UI's, close them and then open them again.
• This behavior only started occurring for me 2 days ago.

I think you are confusing plugin state with UI position. If you delete a plugin and reinsert it of course its not going to retain its settings because it goes back to defaults. If you cant locate minimized UI its possible that the windows menu bar is obscuring it. 

7 hours ago, Mark Morgon-Shaw said:

Yes 3 screens,  1920 x  1080 native resolution  - 100% scaling

can you post a screenshot of your monitor layout from  display properties? I wonder if its somehow related to a 3 monitor config.
Is one monitor lower than the other two?

The window is always sized correctly, just below the screen right?