Hi,
I'm currently playing around with XAudio2 and X3DAudio. My application does nothing more than loading and playing a sound. Everything works perferctly but soon enough I found a strange line in the output window:
The thread 'Win32 Thread' (0xc88) has exited with code -1073741749 (0xc000004b).
I'm quite new to C++ so I asked Google. I found out that this exit code could be caused by a memory leak. So I called _CrtDumpMemoryLeaks() just before the main function exits. After some quick debugging I realized that two global variables were the cause. After fixing those leaks I ran the application again. No memory leaks were detected this time but the strange exit code was still there. So I ripped down the application so that it only initializes XAudio2 and frees XAudio2 afterwards. The exit code is still the same.
What else can be the cause of such a strange exit code?
C++ Interpreting exit codes
The thread exit code is the value returned by a thread's main function. The process exit code is the value you return from main() or WinMain().
XAudio probably creates one or more threads to do streaming and other work, that message just tells you that a thread in your program (Which is probably one created by XAudio) exited with 0xc000004b, which according to Google is STATUS_THREAD_IS_TERMINATING.
I'd guess you're getting that error because XAudio's other thread has just started up as your application terminates. If you add a Sleep(1000); call before freeing XAudio, and that message goes away, then that's almost certainly the cause.
In general, you shouldn't be concerned with thread exit codes unless its a thread you created with CreateThread() or similar.
XAudio probably creates one or more threads to do streaming and other work, that message just tells you that a thread in your program (Which is probably one created by XAudio) exited with 0xc000004b, which according to Google is STATUS_THREAD_IS_TERMINATING.
I'd guess you're getting that error because XAudio's other thread has just started up as your application terminates. If you add a Sleep(1000); call before freeing XAudio, and that message goes away, then that's almost certainly the cause.
In general, you shouldn't be concerned with thread exit codes unless its a thread you created with CreateThread() or similar.
Author
Thanks for your reply,
I added Sleep(1000) between Initializing and Freeing. It didn't solve the issue but If you say it's harmless I will trust you.
Thanks again.
I added Sleep(1000) between Initializing and Freeing. It didn't solve the issue but If you say it's harmless I will trust you.
Thanks again.
Quote:Original post by Soul ReaverIf you're not creating the thread, then it must be XAudio. And so long as any XAudio functions you call don't return any errors, I can't see why it'd be an issue.
Thanks for your reply,
I added Sleep(1000) between Initializing and Freeing. It didn't solve the issue but If you say it's harmless I will trust you.
Thanks again.
It's caused by funky goings on in MMDevApi.dll, independent of XAudio. Basically, it calls into setupapi.dll to free a buffer after setupapi.dll has already had the DllMain(DLL_PROCESS_DETACH) notification.
This buffer freeing tries to enter a critical section that's already been deleted, however the memory of the critical section still looks valid enough for Windows to think it's ok and locked by a different thread. Just before it tries to wait for it, there's a check to see if the process is exiting (which it is, as all this happens deep in ExitProcess after main has returned) and so instead of an incompletable wait, NtTerminateProcess is called with STATUS_THREAD_IS_TERMINATING which ends up as the thread and process return value.
This buffer freeing tries to enter a critical section that's already been deleted, however the memory of the critical section still looks valid enough for Windows to think it's ok and locked by a different thread. Just before it tries to wait for it, there's a check to see if the process is exiting (which it is, as all this happens deep in ExitProcess after main has returned) and so instead of an incompletable wait, NtTerminateProcess is called with STATUS_THREAD_IS_TERMINATING which ends up as the thread and process return value.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
