Board index » Visual Studio » First-chance exception . . . Access Violation

Visual Studio125
A while back I asked for help in this newsgroup, concerning my audio program

(short sentence constructed and played every 4 or 5 seconds) breaking down

on my brother's XP machine. Now that I have XP myself, I can see this debug

information after 10 minutes of running. Does anyone have a comment to help

me understand what's going on? I wasn't getting this on Windows98.



What is WDMAUD? Thank you.

-------------------

First-chance exception in Room 101.exe (KERNEL32.DLL): 0xC0000005: Access

Violation.

First-chance exception in Room 101.exe (WDMAUD.DRV): 0xC0000005: Access

Violation.

First-chance exception in Room 101.exe (WDMAUD.DRV): 0xC0000005: Access

Violation.

DBG: Break command failed within 3 seconds.

DBG: Potential deadlock. Soft broken.

The program 'C:\Hand in Hand\Room 101\Debug\Room 101.exe' has exited with

code 0 (0x0).


-

... so this exception only appears to start after 10 minutes?



You can set the VC debugger to break on the exception (by default it

passes it onto the OS).



If the exception only starts after 10 minutes, I wonder if you have

some sort of resource leak issue - something that just happened to be

OK under Windows 9x.



Taken from MSDN:



"WDMAud System Driver

The user-mode WDMAud system driver (wdmaud.drv) is paired with the

kernel-mode WDMAud system driver (wdmaud.sys). Together, the WDMAud

system drivers translate between WinMM API calls and kernel-streaming

I/O requests. The kernel-mode mode WDMAud driver is a client of the

SysAudio system driver.

"



Dave

--

MVP VC++ FAQ: www.mvps.org/vcfaq">www.mvps.org/vcfaq

-

Thank you very much, Dave.



In answer to your question:



I can bring on the exception almost immediately, simply by clicking the

mouse a time or two. Any thoughts on this?





-

First chance exceptions are often perfectly valid. However, from your

initial description, it appeared to me that you were saying they only

started after 10 minutes running, which would seem to indicate that

something about your program wasn't stable. This is pure speculation

though, you need to debug it and find where it's occurring.



Dave

--

MVP VC++ FAQ: www.mvps.org/vcfaq">www.mvps.org/vcfaq

-

I am finding that when my audio crashes, my Variables window "this" tab

shows the very same result every time:



Value: CXX0017: Error: symbol "this" not found



What does this indicate?





-

Steve Russell wrote:

It probably indicates that when the crash occured the code was not in a

member function of your class. "this" can only be seen by the debugger

when execution is within a member function. As soon as execution

proceeds down into a nonmember function "this" is out of scope.



The key information at a crash is the stack window. In fact, you can

double click in it to go to a member function context and your variables

should reappear.



--

Scott McPhillips [VC++ MVP]

-

I guess one reason I am stumped so far is that my call stack window is only

showing me this:



WDMAUD! 72d2456b()



which gives me this upon double-clicking:



72D2456B mov ecx,dword ptr [ecx+18h]



and the Variables "this" tab information remains the same.



Any further comment??



I am taking a hard look at my lpData variable. Currently I am setting its

size to a bit larger than the combined datasizes of the audio files which

are being layered into it. Could this be my problem? Do I need to

initialize, or later adjust, the size of lpData to equal the total datasize?

....................................

Scott McPhillips" wrote:



-

Scott McPhillips wrote:



I wonder if you are using CALLBACK_FUNCTION when you open the device.

If you are then it calls you from its own thread context and there are

severe limits on what you are allowed to do in your callback function.

They are described in the waveOutProc doc page.



The size of the data buffer has to be big enough to hold all the data,

but there's nothing harmful about it being a bit bigger. Are you

checking the return value of waveoutPrepareHeader for errors?

....................................

Scott, thank you very much for the feedback! Now I can at least eliminate

the buffer size as a factor.



No, I am not using CALLBACK_FUNCTION; I am using CALLBACK_WINDOW.



In my relevant class:



if(waveOutOpen(&hWaveOut, WAVE_MAPPER, &Format,

(DWORD)m_pAct->m_pView->m_hWnd,NULL, CALLBACK_WINDOW))

{AfxMessageBox("Can't Open Device");

mmioClose(hmmio, 0);

return;}

. . . .

And in my view:



LRESULT CRoom101View::DefWindowProc(UINT message,

WPARAM wParam, LPARAM lParam)

{

switch (message)

{

case MM_WOM_DONE:

waveOutUnprepareHeader((HWAVEOUT) wParam,

(LPWAVEHDR) lParam, sizeof(WAVEHDR));

waveOutClose((HWAVEOUT) wParam);

m_pAct->m_pPat->AudioCleanUp();

break;

}

return CView::DefWindowProc(message, wParam, lParam);

}



Concerning waveOutPrepareHeader, do you mean I should do more than this?:



if(waveOutPrepareHeader(hWaveOut, &WaveHdr, sizeof(WAVEHDR)))

{AfxMessageBox("Can't Prepare Header");

return;}



I would sure like to put this issue behind me....





-

Steve Russell wrote:

Your test of waveOutPrepareHeader is fine - another possibility ruled

out.



Do you have more than one audio buffer? If so it might get lost or

cause a crash when you attempt to free it. You're supposed to call

waveOutReset before calling waveOutClose. In my (multiple buffers

recirculating) code I call waveOutReset, which causes all buffers to be

returned, and I don't call waveOutClose until all buffers have been

returned.



--

Scott McPhillips [VC++ MVP]

-

Scott McPhillips wrote:

No, I have only one buffer. However, I added the waveOutReset just to

eliminate another question, with no change in the results. So I will strip

down the code to the simplest form and see if I can isolate the problem

further, before posting again. Thank you very much.





-

Scott McPhillips wrote:

Does this provide any more of a hint?:



NTDLL! 77f767cd()

NTDLL! 77fa311b()

NTDLL! 77f8566a()

KERNEL32! 77e73a2d()

WDMAUD! 72d22145()

e877e830()

-