I do not think a great crime has taken place because you were not saying anything that hasn't been said in some threads already. I think the other reason to close such already to death talked thread is that such negative sounding talk that was taking place might scare away somebody who was looking for a good trouble free DAW. But I think the thread closing might have happened with a nicer way. It might have been nice to have a easy go link to the thread and page where the answers are. I must say I still have not gotten a satisfying answer to my question is it a really bad idea to get the New Hope Sonar as I have Vista on my laptop (I have Seven on my desktop). Would there be like constant crashing or blue screening taking place with Vista.

I was not trying to sound negative and I was not aware that this was much talked about. On, for example, the Native Instrument forums, ASIO4ALL was often recommended as a reasonably good driver and it is updated now and then.
 
I will drop this with one last data dump. When Sonar does not terminate, there are 11 threads that remain running.
Some are duplicates, but the unique thread stacks look like this. As the threads are running, the exact values may be changing:
 
 

Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! int audioConv(wchar_t *,wchar_t * *,struct IFile *,unsigned int,unsigned int,unsigned int,unsigned int,unsigned int,double *,int *,int volatile *,struct tAudioConvCom volatile *,int (*)(unsigned __int64,int,int,int,void *,void *,void *,void *),int (*)(void),unsigned int,unsigned long,struct tDspVolItem *) + 0x311d8 ------ 1406ADFD8
                                                                                                                                                                                                                                                                                                                                                                            
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A13FB50
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF0485111813FB58





Thread Start Address: 
Symbol Name: Line Number: PC:
wdmaud.drv ! midMessage() + 0xfe10 ------ 7FFEFCB08C60
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA379FA50
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED379FA58





Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x5502e0 ------ 140670660
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A4E5FE60
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF048511184E5FE68




Thread Start Address: 
Symbol Name: Line Number: PC:
gdiplus.dll + 0x28C0 ------ 7FFEFD8D28C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA504FAD0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED504FAD8



Thread Start Address: 
Symbol Name: Line Number: PC:
combase.dll ! CoGetProcessIdentifier() + 0x3c0 ------ 7FFF04B512C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FAA57F8F0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513EDA57F8F8
ntdll.dll ! RtlValidSecurityDescriptor() + 0x85 ------ 7FFF073E3A35A57F918




Thread Start Address: 
Symbol Name: Line Number: PC:
MSVCR120.dll ! _endthreadex() + 0x90 ------ 7FFEFA135024
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8ABB4FCF0
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF04851118BB4FCF8
mfc120u.dll + 24EA54 ------ 7FFEEAD0EA54BB4FD08
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x31c7c5 ------ 14043CB45BB4FD18




Thread Start Address: 
Symbol Name: Line Number: PC:
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0
                                                                                  
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForWorkViaWorkerFactory() + 0xa ------ 7FFF0743273A100DFB70
ntdll.dll ! RtlFreeUnicodeString() + 0x1ab6 ------ 7FFF073D3AE6100DFB78
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0100DFB80

I must say I am terribly sorry. I put my comment here by mistake. Silly me.

 
arachnaut, I don't think kakku is in the right thread.  He posted the same thing in response to a post that was critical of the new membership model - nothing at all to do with this topic. 
 
He may not have even realized he did it.  (EDIT:  Yep, see above).
 
 
 
 
 

Is there any chance that with Windows defaulting to 16-bit 44.1 for its audio and Sonar set to 24-bit and 48K that somehow these are not being switched/handled properly?
 
I dimly recall setting up a bunch of setting in Windows for changing all the potential outputs from my Presonus audio interface to 24-bit and 48K on MY system, back when I used to try to run everything through the interface *been a long time since I did that, though.  For a long time now, I have kept the Windows Default Audio Device separate from what I use for Sonar or other music production applications, precisely so that I don't have any such conflicts.
 
Just wondering, 
 
Bob Bone
 

arachnaut
I was not trying to sound negative and I was not aware that this was much talked about. On, for example, the Native Instrument forums, ASIO4ALL was often recommended as a reasonably good driver and it is updated now and then.
 
I will drop this with one last data dump. When Sonar does not terminate, there are 11 threads that remain running.
Some are duplicates, but the unique thread stacks look like this. As the threads are running, the exact values may be changing:
 
 

Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! int audioConv(wchar_t *,wchar_t * *,struct IFile *,unsigned int,unsigned int,unsigned int,unsigned int,unsigned int,double *,int *,int volatile *,struct tAudioConvCom volatile *,int (*)(unsigned __int64,int,int,int,void *,void *,void *,void *),int (*)(void),unsigned int,unsigned long,struct tDspVolItem *) + 0x311d8 ------ 1406ADFD8
                                                                                                                                                                                                                                                                                                                                                                            
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A13FB50
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF0485111813FB58





Thread Start Address: 
Symbol Name: Line Number: PC:
wdmaud.drv ! midMessage() + 0xfe10 ------ 7FFEFCB08C60
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA379FA50
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED379FA58





Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x5502e0 ------ 140670660
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A4E5FE60
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF048511184E5FE68




Thread Start Address: 
Symbol Name: Line Number: PC:
gdiplus.dll + 0x28C0 ------ 7FFEFD8D28C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA504FAD0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED504FAD8



Thread Start Address: 
Symbol Name: Line Number: PC:
combase.dll ! CoGetProcessIdentifier() + 0x3c0 ------ 7FFF04B512C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FAA57F8F0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513EDA57F8F8
ntdll.dll ! RtlValidSecurityDescriptor() + 0x85 ------ 7FFF073E3A35A57F918




Thread Start Address: 
Symbol Name: Line Number: PC:
MSVCR120.dll ! _endthreadex() + 0x90 ------ 7FFEFA135024
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8ABB4FCF0
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF04851118BB4FCF8
mfc120u.dll + 24EA54 ------ 7FFEEAD0EA54BB4FD08
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x31c7c5 ------ 14043CB45BB4FD18




Thread Start Address: 
Symbol Name: Line Number: PC:
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0
                                                                                  
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForWorkViaWorkerFactory() + 0xa ------ 7FFF0743273A100DFB70
ntdll.dll ! RtlFreeUnicodeString() + 0x1ab6 ------ 7FFF073D3AE6100DFB78
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0100DFB80

I'm afraid all this shows is that Sonar has crashed and there is something going on at kernel level. Without source code you could factor in absolutely anything as the cause.

robert_e_bone
Is there any chance that with Windows defaulting to 16-bit 44.1 for its audio and Sonar set to 24-bit and 48K that somehow these are not being switched/handled properly?
 
I dimly recall setting up a bunch of setting in Windows for changing all the potential outputs from my Presonus audio interface to 24-bit and 48K on MY system, back when I used to try to run everything through the interface *been a long time since I did that, though.  For a long time now, I have kept the Windows Default Audio Device separate from what I use for Sonar or other music production applications, precisely so that I don't have any such conflicts.
 
Just wondering, 
 
Bob Bone
 

In my case, the Windows Sound playback control panel defaults to 24-bit, 48Khz. What they call 'Studio Quality'.
It is only the Mic input and unused Mixer that are 16-bit. The Mic and Mixer appear in Sonar as input devices, but they are not checked or enabled in Sonar.

CakeAlexS
 
 
I'm afraid all this shows is that Sonar has crashed and there is something going on at kernel level. Without source code you could factor in absolutely anything as the cause.

Actually Sonar has not crashed, it is just stuck in a wait loop and never gets the semaphore or token it needs to quit fully.
 
My post was only to allow others to see if they get a similar result. Even the symbols might be erroneous - I don't know how they get determined - maybe they are in the loader image.
 
I have seen a lot of the wait loops in NI products (NIHardwareSErvice) on termination. They are not technically crashes.
 
I suppose you could say the code might look like this:
 
done = false;
while (!done) {
    done = Check(something);
    suspend (100 ms);
}
 
 
and perhaps could look like this:
 
done=false;
start_timeout(10 seconds); // or whatever
while (!done and !Timed_out()) {
    done = Check(something);
    suspend (100 ms);
}
 
The error or misunderstanding is that some of these signals will always be sent, so no timeouts are made.
It not so unusual in the termination steps to find stuff like this, because the steps and variations don't happen so often in the test environment.
 

CakeAlexS

arachnaut
I was not trying to sound negative and I was not aware that this was much talked about. On, for example, the Native Instrument forums, ASIO4ALL was often recommended as a reasonably good driver and it is updated now and then.
 
I will drop this with one last data dump. When Sonar does not terminate, there are 11 threads that remain running.
Some are duplicates, but the unique thread stacks look like this. As the threads are running, the exact values may be changing:
 
 

Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! int audioConv(wchar_t *,wchar_t * *,struct IFile *,unsigned int,unsigned int,unsigned int,unsigned int,unsigned int,double *,int *,int volatile *,struct tAudioConvCom volatile *,int (*)(unsigned __int64,int,int,int,void *,void *,void *,void *),int (*)(void),unsigned int,unsigned long,struct tDspVolItem *) + 0x311d8 ------ 1406ADFD8
                                                                                                                                                                                                                                                                                                                                                                            
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A13FB50
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF0485111813FB58





Thread Start Address: 
Symbol Name: Line Number: PC:
wdmaud.drv ! midMessage() + 0xfe10 ------ 7FFEFCB08C60
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA379FA50
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED379FA58





Thread Start Address: 
Symbol Name: Line Number: PC:
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x5502e0 ------ 140670660
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8A4E5FE60
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF048511184E5FE68




Thread Start Address: 
Symbol Name: Line Number: PC:
gdiplus.dll + 0x28C0 ------ 7FFEFD8D28C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FA504FAD0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513ED504FAD8



Thread Start Address: 
Symbol Name: Line Number: PC:
combase.dll ! CoGetProcessIdentifier() + 0x3c0 ------ 7FFF04B512C0
                                                                                   
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! ZwWaitForMultipleObjects() + 0xa ------ 7FFF074311FAA57F8F0
KERNELBASE.dll ! WaitForMultipleObjectsEx() + 0xed ------ 7FFF048513EDA57F8F8
ntdll.dll ! RtlValidSecurityDescriptor() + 0x85 ------ 7FFF073E3A35A57F918




Thread Start Address: 
Symbol Name: Line Number: PC:
MSVCR120.dll ! _endthreadex() + 0x90 ------ 7FFEFA135024
                                                                                
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForSingleObject() + 0xa ------ 7FFF07430C8ABB4FCF0
KERNELBASE.dll ! WaitForSingleObjectEx() + 0x98 ------ 7FFF04851118BB4FCF8
mfc120u.dll + 24EA54 ------ 7FFEEAD0EA54BB4FD08
SONARPLT.exe ! l9_ippsCos_64f_A53() + 0x31c7c5 ------ 14043CB45BB4FD18




Thread Start Address: 
Symbol Name: Line Number: PC:
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0
                                                                                  
Thread Stack:: 
Symbol: Line Number: PC:Stack Frame:
ntdll.dll ! NtWaitForWorkViaWorkerFactory() + 0xa ------ 7FFF0743273A100DFB70
ntdll.dll ! RtlFreeUnicodeString() + 0x1ab6 ------ 7FFF073D3AE6100DFB78
ntdll.dll ! RtlFreeUnicodeString() + 0x1370 ------ 7FFF073D33A0100DFB80

I'm afraid all this shows is that Sonar has crashed and there is something going on at kernel level. Without source code you could factor in absolutely anything as the cause.

This is not from a crash dump, it's from Taskinfo on the running system after Sonar 'terminates'.
 
http://www.iarsn.com/taskinfo.html

Saw MSVCR120.dll. Do you have the latest C++ runtime libraries installed?
You wouldn't be running Visual Studio next to Sonar would you?
Did you get rid of ASIO4ALL? If not do it I suggest. Total uninstall (apparently it can be hard to get rid of?).

Ta.