Not sure this is your problem but I've seen IK plugins crash often in SONAR if you use the VST3 versions.  It has been like this for a long long time.  I pretty much make it a habit of disabling the VST3 versions of all IK plugins in SONAR's plugin manager.  The VST2 versions seem much more reliable.
 
As for Visual Studio not being recommend on a production machine, I would argue that every single developer of every piece of software you run on a daily basis most likely has Visual Studio installed (in my case I have 3 different versions even).  It is unlikely to be a problem for anyone.  That said, you don't need Visual Studio on "the" machine to open the crash dump, you can transfer the crash dump to another machine (though you'll need copies of the exe's and dll's (the software and plugins) on that other machine if you want to get a decent amount of information).
 
I don't really recommend regular users try messing with debuggers, but it's not black magic.

pwalpwal

msorrels
Install Visual Studio

not recommended on a production machine (sorry)

agreed, that seems like a lot of work to go through just to read a dump file.
cant you right click on it and choose "open as TXT file ?
This may screw with your Windows file association but you can always just change it back. 

It's not a text file.  It's a binary dump of the memory of the process at the state it crashed.  It is the best black box software crashes can get.  There are tools that can create English versions of the dump but none are as rich as opening it in a debugger.  Especially if the developer has saved symbol data for the software (which they can link up).

Hey, visual studio is working.....
Vst3 may be a problem...... Great, I just disabled the Vst2 versions to try to eliminate the error. Guess I'll try the other way around.

Okay so you want to learn to read a crash dump file a few things that must be said first do you know that most programs come with two versions retail and debug retail is what we get when we buy the program debug is what the company use to produce the retail version. Retail versions have all debugging information striped from it so you may think this will not be useful think again learning to read a crash dump is very helpful when you get in touch with a company to point out a bug that is the purpose of a crash dump. A big mistake people make when debugging a program is thinking they can change the code unless you are a programmer for a company that produce the program you can not change the code. If you want to learn to read a crash dump a good start would be to get Visual Studio next do one of the sample examples they have many of all levels whichever one you choose get it working. Now place some break points when a break point is hit step though the program to get an idea of what the program is doing. Now you want to produce a crash (terms used here you may not understand yet if you made it this far you will have some understanding of what they are) the best way to produce a crash would be to write a method that is incomplete. Another way would be to take a piece of code out this may or may not work because Visual Studio is smart and may correct before a crash happen. By using a sample example you get a debug version, all of the symbol files, and the source code.
 
The warning "not recommended for production machine" my understanding of this is depending on what version of Visual Studio you are using or the "sample example" used you see this warning to let you know that a method, API, or technic used maybe old or new and should not be used in a retail or debug version.
 
An example of a crash, company A has program company B has a program that maybe used in company A program. You run company A program it crashes now you open the crash dump and it says it crashed because of company B program that maybe true or not it could be that company A did not write correctly to company B program or it could be that company A or company B is not a fault or it could be that both programs are at fault.
 

Well, I want someone to fix the code. As a former programmer 18 years ago I know the difficulties. I don't even have any source code! Anyway, I found the error, contacted IK and included the dump file. I would have done the same with Cakewalk, but I have zero faith the company will respond. I did send the crash report. Of course I have done that several times in the past with no follow up from Cakewalk. 

If all you want to find out is which plugin caused the crash, then there's no need to read a dump file at all. That information can usually be obtained via the Windows Event Viewer.

bitflipper
If all you want to find out is which plugin caused the crash, then there's no need to read a dump file at all. That information can usually be obtained via the Windows Event Viewer.

Earlier I posted that the BlueScreenView free app http://www.nirsoft.net/utils/blue_screen_view.html can read dump files.  But that apparently only opens blue screen crash .dmp files.
 
The same developer has another free app called AppCrashView.  It can read the WER (Windows Error Reporting) file created by the app crash.  It's basically the same info in the Windows Event Viewer, with some more details.  It's cool if you just want to see what happened without loading Visual Studio to read the .dmp file.
 
http://www.nirsoft.net/utils/app_crash_view.html
 
I just had AAS player crash Sonar earlier today, so I had a chance to try this out.  Restarted Sonar and everything is cool again.

I am experiencing crashes on every session. Usually I am just trying to move a plugin from one track to the next.
 
I get around 60 fault report windows open & only one of them sends the error report.
 
Takes me a good half hour of clicking to try and get to a point where I can close SPLAT down.
 
I haven't had any luck being able to view the mini dumps with the tools mentioned above.
 
Does anybody know how to open the SPLAT mini dump files???
 
Is there a way I can get Cakewalk to follow up on the error reports?

I have been checking on the status of theses reports for months now & it would appear they haven't been looked at.
 
Any advice would be appreciated.
 

Start with the Windows Event Viewer. This won't tell you a whole lot, but it will let you know if the faulting module is SONAR or (more commonly) a plugin, and if the latter, which one. If the entry in the event log indicates a plugin, then the issue should be taken up with the plugin vendor.
 
When you send a crash dump to CW, that's the first thing they'll do. Then they'll try to duplicate the problem (I think they have every plugin known to man over there) to make sure it's not SONAR's fault, which is possible but atypical. They will then contact the vendor and let them know about the problem. At that point, there isn't really much more the CW folks can do for you, since only the plugin's developer can drill any deeper.