Noel Borthwick [Cakewalk]
If you are indeed getting a blue screen crash, then event viewer should list what happened and link to a Minidump saved on your system. If you can end me the minidump, I should be able to see what is crashing.
A BSOD is always a driver crash not an app crash. Apps talk to drivers in different ways so its completely possible that something that works in one app (X1) crashes in another (x2) just because of subtle differences that may expose the crash in one scenario but not another.

I've uploaded a minidump and the project.  I didn't include the audio.  I have a small version that manifests the problem in about 16 bars that I can bundle if you need it.
CWBRN-17845

Here is the minidump analysis for the file you sent in. The crash is in your Dakota driver. It would appear that they are releasing a mutex on the wrong thread. The crash is not from X2A itself.
Make sure you have the latest drivers for this. If its recurring despite this send the dump file to the hardware manufacturer...
 
MODULE_NAME: Dakota
IMAGE_NAME: Dakota.sys
 
EXCEPTION_CODE: (NTSTATUS) 0xc0000046 - An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
 
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000046, Exception code that caused the bugcheck
Arg2: fffff800030a97fc, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800271e0a0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 - An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
FAULTING_IP:
nt!RtlRaiseStatus+18
fffff800`030a97fc 488b8424b8010000 mov rax,qword ptr [rsp+1B8h]
CONTEXT: fffff8800271e0a0 -- (.cxr 0xfffff8800271e0a0)
rax=0000000000000000 rbx=00000000c0000046 rcx=fffff8800271e0a0
rdx=0000000000000001 rsi=0000000000000001 rdi=fffff880009e6180
rip=fffff800030a97fc rsp=fffff8800271dfe0 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff8800271e5f8 r12=0000000000000000 r13=0000000000000000
r14=fffffa800600b060 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
nt!RtlRaiseStatus+0x18:
fffff800`030a97fc 488b8424b8010000 mov rax,qword ptr [rsp+1B8h] ss:0018:fffff880`0271e198=fffff800030a97fc
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x3B
PROCESS_NAME: SONARPDR.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80003086fa1 to fffff800030a97fc
STACK_TEXT:
fffff880`0271dfe0 fffff800`03086fa1 : fffff880`0456ed50 fffff880`04559000 00000000`00000000 00000000`00000012 : nt!RtlRaiseStatus+0x18
fffff880`0271e580 fffff880`04571810 : fffffa80`00000001 fffff800`00000001 00000000`00000000 fffffa80`053ecb00 : nt!KeReleaseMutant+0x281
fffff880`0271e630 fffffa80`00000001 : fffff800`00000001 00000000`00000000 fffffa80`053ecb00 00000000`00000000 : Dakota+0x18810
fffff880`0271e638 fffff800`00000001 : 00000000`00000000 fffffa80`053ecb00 00000000`00000000 fffff880`045a445d : 0xfffffa80`00000001
fffff880`0271e640 00000000`00000000 : fffffa80`053ecb00 00000000`00000000 fffff880`045a445d fffffa80`05fa1420 : 0xfffff800`00000001

FOLLOWUP_IP:
Dakota+18810
fffff880`04571810 ?? ???
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: Dakota+18810
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Dakota
IMAGE_NAME: Dakota.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4696b865
STACK_COMMAND: .cxr 0xfffff8800271e0a0 ; kb
FAILURE_BUCKET_ID: X64_0x3B_Dakota+18810
BUCKET_ID: X64_0x3B_Dakota+18810
Followup: MachineOwner
---------
 
Child-SP RetAddr Call Site
fffff880`0271d748 fffff800`0307c1a9 nt!KeBugCheckEx
fffff880`0271d750 fffff800`0307bafc nt!KiBugCheckDispatch+0x69
fffff880`0271d890 fffff800`030a775d nt!KiSystemServiceHandler+0x7c
fffff880`0271d8d0 fffff800`030a6535 nt!RtlpExecuteHandlerForException+0xd
fffff880`0271d900 fffff800`030a9832 nt!RtlDispatchException+0x415
fffff880`0271dfe0 fffff800`03086fa1 nt!RtlRaiseStatus+0x4e
fffff880`0271e580 fffff880`04571810 nt!KeReleaseMutant+0x281
fffff880`0271e630 fffffa80`00000001 Dakota+0x18810
fffff880`0271e638 fffff800`00000001 0xfffffa80`00000001
fffff880`0271e640 00000000`00000000 0xfffff800`00000001
 
 

I'd be considering another interface.  If I was on the right page, support didn't look very recent.

Noel Borthwick [Cakewalk]
Here is the minidump analysis for the file you sent in. The crash is in your Dakota driver. It would appear that they are releasing a mutex on the wrong thread. The crash is not from X2A itself.
Make sure you have the latest drivers for this. If its recurring despite this send the dump file to the hardware manufacturer...
 
MODULE_NAME: Dakota
IMAGE_NAME: Dakota.sys
 
EXCEPTION_CODE: (NTSTATUS) 0xc0000046 - An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
 
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000046, Exception code that caused the bugcheck
Arg2: fffff800030a97fc, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800271e0a0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 - An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
FAULTING_IP:
nt!RtlRaiseStatus+18
fffff800`030a97fc 488b8424b8010000 mov rax,qword ptr [rsp+1B8h]
CONTEXT: fffff8800271e0a0 -- (.cxr 0xfffff8800271e0a0)
rax=0000000000000000 rbx=00000000c0000046 rcx=fffff8800271e0a0
rdx=0000000000000001 rsi=0000000000000001 rdi=fffff880009e6180
rip=fffff800030a97fc rsp=fffff8800271dfe0 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff8800271e5f8 r12=0000000000000000 r13=0000000000000000
r14=fffffa800600b060 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
nt!RtlRaiseStatus+0x18:
fffff800`030a97fc 488b8424b8010000 mov rax,qword ptr [rsp+1B8h] ss:0018:fffff880`0271e198=fffff800030a97fc
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x3B
PROCESS_NAME: SONARPDR.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80003086fa1 to fffff800030a97fc
STACK_TEXT:
fffff880`0271dfe0 fffff800`03086fa1 : fffff880`0456ed50 fffff880`04559000 00000000`00000000 00000000`00000012 : nt!RtlRaiseStatus+0x18
fffff880`0271e580 fffff880`04571810 : fffffa80`00000001 fffff800`00000001 00000000`00000000 fffffa80`053ecb00 : nt!KeReleaseMutant+0x281
fffff880`0271e630 fffffa80`00000001 : fffff800`00000001 00000000`00000000 fffffa80`053ecb00 00000000`00000000 : Dakota+0x18810
fffff880`0271e638 fffff800`00000001 : 00000000`00000000 fffffa80`053ecb00 00000000`00000000 fffff880`045a445d : 0xfffffa80`00000001
fffff880`0271e640 00000000`00000000 : fffffa80`053ecb00 00000000`00000000 fffff880`045a445d fffffa80`05fa1420 : 0xfffff800`00000001

FOLLOWUP_IP:
Dakota+18810
fffff880`04571810 ?? ???
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: Dakota+18810
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Dakota
IMAGE_NAME: Dakota.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4696b865
STACK_COMMAND: .cxr 0xfffff8800271e0a0 ; kb
FAILURE_BUCKET_ID: X64_0x3B_Dakota+18810
BUCKET_ID: X64_0x3B_Dakota+18810
Followup: MachineOwner
---------
 
Child-SP RetAddr Call Site
fffff880`0271d748 fffff800`0307c1a9 nt!KeBugCheckEx
fffff880`0271d750 fffff800`0307bafc nt!KiBugCheckDispatch+0x69
fffff880`0271d890 fffff800`030a775d nt!KiSystemServiceHandler+0x7c
fffff880`0271d8d0 fffff800`030a6535 nt!RtlpExecuteHandlerForException+0xd
fffff880`0271d900 fffff800`030a9832 nt!RtlDispatchException+0x415
fffff880`0271dfe0 fffff800`03086fa1 nt!RtlRaiseStatus+0x4e
fffff880`0271e580 fffff880`04571810 nt!KeReleaseMutant+0x281
fffff880`0271e630 fffffa80`00000001 Dakota+0x18810
fffff880`0271e638 fffff800`00000001 0xfffffa80`00000001
fffff880`0271e640 00000000`00000000 0xfffff800`00000001
 
 

Thank you, Noel.
 
At least, if I HAVE to buy a new piece of hardware, I will know for sure that it is the culprit in this case instead of throwing money out the window an hoping it fixes something.

doncolga
I'd be considering another interface.  If I was on the right page, support didn't look very recent.

Yeah.  It looks like Frontier couldn't keep up with the changing competition.  It's a pity because up through Win XP they were rock solid and the actual hardware is built like a tank.  I hate to put away good gear because support for it has more or less died.

 
Here's an interesting take on a situation like this:
 
from: http://stackoverflow.com/questions/10402934/releasing-the-mutex
 
 
"In your previous question, it's important to note that you are running that code with multiple threads and that the same race condition is present in each thread. Multiple threads may have failed to acquire the mutex while one thread held on to it, and so multiple threads will likewise fail to release it. Take the following path of execution as an example.

• Thread 1 acquires the mutex.
• Thread 2 fails to acquire the mutex because Thread 1 has it.
• Thread 3 fails to acquire the mutex because Thread 1 has it.
• Thread 3 attempts to release the mutex, throwing an ApplicationException because it doesn't own it.
• Thread 1 releases the mutex.
• Thread 2 attempts to release the mutex, throwing an ApplicationException because it doesn't own it.

The fact that Thread 3 blew up when it failed to release the mutex has no correlation to the fact that Thread 2 also blew up by doing the same thing."
 
 
 
 
 
Thread 1 may be having a party and refuse to turn the music down causing Thread 3 to call in the exception.
 
 
best regards,
mike
 

Unfortunately, it's pretty apparent that Frontier has dropped support for the Dakota because it's not even listed on the drop down menu on their support contact page.
 
It looks like an RME Fireface UFX or an UAD Apollo is on my horizon.  It would certainly streamline my set up regardless of why I have to consider it.

mike_mccue
 
Here's an interesting take on a situation like this:
 
from: http://stackoverflow.com/questions/10402934/releasing-the-mutex
 
 
"In your previous question, it's important to note that you are running that code with multiple threads and that the same race condition is present in each thread. Multiple threads may have failed to acquire the mutex while one thread held on to it, and so multiple threads will likewise fail to release it. Take the following path of execution as an example.

• Thread 1 acquires the mutex.
• Thread 2 fails to acquire the mutex because Thread 1 has it.
• Thread 3 fails to acquire the mutex because Thread 1 has it.
• Thread 3 attempts to release the mutex, throwing an ApplicationException because it doesn't own it.
• Thread 1 releases the mutex.
• Thread 2 attempts to release the mutex, throwing an ApplicationException because it doesn't own it.

The fact that Thread 3 blew up when it failed to release the mutex has no correlation to the fact that Thread 2 also blew up by doing the same thing."
 
 
 
 
 
Thread 1 may be having a party and refuse to turn the music down causing Thread 3 to call in the exception.
 
 
best regards,
mike
 

I don't mind if Thread 1 is having it's party but I sure hate getting the bill for the party and the clean up services.

lawp
why would you change how sonar talks to the driver?

Possibly to solve a more general issue or to improve performance, but some drivers don't play nicely with the revised code...they should follow specs, but it's clear they don't (especially older drivers which weren't written for a multi-CPU environment).

Dave, you will not be sorry with the Fireface UFX. RME drivers are rock solid in win7.