When Sonar Crashes I usually just relaunch.
 
I'm not sure I can remember a crash in X3. Scratching my head... hmmm. It's been a while, anyway.

You're limited as to what you can glean from the dump file, but some useful information can be had. You'll first need a program that can decipher the dump. The standard tool is WinDbg, which you can download from Microsoft for free.
 
Open the dump file, and the program will immediately display some information about it. At the bottom of that initial listing you'll find the first piece of useful information: the type of fault that occurred. More often than not, it'll be an access violation (0xc0000005), in which case you can assume that the problem is a bug in either SONAR or in a plugin, and you'll have to take it up with the vendor. Next step is to determine if it's a plugin, and if so, which one - so you'll know who to complain to.
 
Type "!analyze -v" in the command window at the bottom. Give it a minute or two to process the dump. It'll complain about the lack of symbol files, but ignore that. After it's done, scroll to the bottom and you'll see the name of the faulting module. Look for a line that reads "MODULE_NAME". It might be the name of your video driver, your audio driver, a Windows module, SONAR itself, or a plugin. If it's a plugin, the file name will be labeled "IMAGE_NAME", as shown in the example below.
 
If the faulting module is sonarpdr.exe, you won't be able to determine much more than that, because
you need a symbol table to correlate addresses to functions within the executable. If the fault originated in SONAR, it's best to send the dump to Cakewalk, where they'll have the required symbol file. If it's a plugin, send the dump to the plugin vendor, who will have the required symbols for their DLL needed to determine where in their code the problem originated.
 
Here's an example:
 
TACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: BarkOfDog_x86+6b25
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: BarkOfDog_x86
IMAGE_NAME: BarkOfDog_x86.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 51e4d41c
FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_BarkOfDog_x86.dll!Unknown
BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_BarkOfDog_x86+6b25
 
I've bolded the most-significant bits of information, which show that the error occurred in a plugin called BarkOfDog_x86.dll and that it was an access violation (INVALID_POINTER_READ_c0000005). The line labeled "SYMBOL_NAME" would show the actual function name within the DLL if you had the symbol file, but only the vendor will have that. That's why it's helpful to send the crash dump to the vendor.
 
BTW, this particular crash happened with an early version of Bark of Dog, a bass-boost plugin. Such occurrences are commonplace when you're beta-testing or running a 1.0 version of a new plugin.
 

Brilliant stuff Bit!!
 
Where do you get all this knowledge from???

Bristol_Jonesey
Brilliant stuff Bit!!
 
Where do you get all this knowledge from???

My guess would be from painful experience.
 
Bob Bone
 

Thanks Bit, I'll try that program! I Googled how to read dump files some time ago and couldn't find a reader, good to know there is one.
 
-1 points for those who suggested things I already discounted in my description. no jbridge, 32-bit, and no, power cycling the audio interface does not solve the problem. It allows SONARPDR.exe to close, but on restart SONAR will NOT recognize the interface unless I cold boot.
 

robert_e_bone

Bristol_Jonesey
Brilliant stuff Bit!!
 
Where do you get all this knowledge from???

My guess would be from painful experience.
 
Bob Bone
 

BINGO.

Very sorry you are fighting this issue.
 
I am wondering, once Sonar crashes, and actually also during hang, does Windows still show your USB drivers loaded in Device Manager, for your OctaCapture? 
 
I recall some flaky issues where some USB-connected devices get themselves or Windows confused if they have either gone to sleep, been affected by Windows Selective Suspension, or that sort of thing.  
 
Quick question - not related to the loss of the interface being detected, but just on the crashes when loading certain older projects.
 
Do these failing projects load in Safe Mode in Sonar, with no plugins loading?  (you can tell Sonar to skip loading up plugins during Safe Mode launch).  I am just wondering if that would help in the analysis of the issues.  If these projects load in Safe Mode with no plugins, but fail when loading normally, then you could take one of these projects and load in Safe Mode - allowing it to load a single plugin at a time, until you get to one that fails.  Then load again in Safe Mode, get to that point again, skip the load of the failing plugin, then continue loading one at a time past that, to make sure others are also not failing.
 
The above would be a GIANT pain in the back porch, but it might be a way to come up with a list of which plugins don't work anymore for some reason in Sonar.
 
Bob Bone
 

...wickedand no, power cycling the audio interface does not solve the problem. It allows SONARPDR.exe to close, but on restart SONAR will NOT recognize the interface unless I cold boot.

hmm, disable/enable cycle in device manager maybe?

If the device is powered off, Windows will release the loaded drivers for it, and they will reload with the unit coming back on.
 
Bob Bone
 

"should" be put in that sentence somewhere I think, because I do exactly that and on restarting SONAR it doesn't see the interface. Other media apps and browsers will still play sound though...