User breakpoint called from code. Please help!

redeemer

I get this error when using acmDriverEnum to enumerate all the different codecs on my system, this is the callback function:

BOOL WINAPI listCallback(HACMDRIVERID hadid, DWORD dwInstance, DWORD fdwSupport)
{
if (fdwSupport & ACMDRIVERDETAILS_SUPPORTF_CODEC)
{
ACMDRIVERDETAILS details;

	details.cbStruct = sizeof(details);

	acmDriverDetails(hadid, &details, NULL);

	SendMessage(GetDlgItem(ghWnd, IDC\_CODECS), LB\_INSERTSTRING, 0, (LPARAM)details.szLongName);
}

return true;

}

In this routine i simply check if the current driver is a codec, and if it is i add the name of it to a listbox. The error happens when i have looped though all of the different codecs and the return true; statement has been executed. After that it jumps to some assembly code, and this is the stament it gives me the message after completing:

call dword ptr [ebp+8]

When that statement has been executed, the "User breakpoint called from code at 0x77f9f9df" message appears, and it jumps to this statement:

int 3

I've never experienced this message before and i haven't got a clue what it means. All help appreciated. -Rune Svendsen

Daniel Turini

This is an exception being thrown... Try review the call stack and get some other clues... Concussus surgo. When struck I rise.

redeemer

Sorry for my ignorance, but what is the call stack and how to i review it? Thanks.

Daniel Lohmann

The message "User breakpoint called from code at 0x77f9f9df" means that a software interrupt 3 was thrown, which is used for breakpoints. An int 3 asm instruction is a so called "hardcoded breakpoint" and causes the message and halts the program in the debugger. In debug mode the compiler initializes any unused memory and also some bytes before and after every function with this instruction. This is a good thing, because it let you find jumps to invalid adresses, and obviously such an illegal jump is also your problem. Okay, so much about the magic things in the background. What actually happens in your case is a bit difficult to figure out. I assume that the stack is not layed out as it should, therefore the app crashes while executing the return statement. Note: The return statement is only the position it crashes - the real problem is somewhere else and just not detected before. Please do the following:

What happens if you remove anything from your function, but the return true statement? Is the problem still there?
Please show us the line you where you pass the callback function to acmDriverEnum(). Are you doing some ugly cast's there because otherwise it would not compile? Maybe your callback functions prototype is not layed out as it should. Casting it to the "correct type" is a typical source for big trouble, if you are not absolutely sure about what you are doing.

(I really do have a feeling that it is 2. that causes your problem - but hey, it's just a feeling :rolleyes: ) -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D )

Daniel Turini

Try View/Debug Windows/Call Stack (or press Alt+7) It's a debug window that shows all the functions called until your program got into that line the debugger is showing. Concussus surgo. When struck I rise.

redeemer

1. I have tried removing everything from the callback function except return true;, and when i do that the messagebox doesn't appear, but in the Debug fan (the one where there's Build, Debug, Find In Files 1 etc.) it says First-chance exception in MP3.exe (MSACM32.DLL): 0xC0000005: Access Violation. First-chance exception in MP3.exe (MSACM32.DLL): 0xC0000005: Access Violation. (yes, the statement is shown twice) 2. The line where i call the function that uses the callback function is as follows:

acmDriverEnum(listCallback, NULL, ACM_DRIVERENUMF_DISABLED);

The prototype of the callback is:

BOOL WINAPI listCallback (HACMDRIVERID hadid, DWORD dwInstance, DWORD fdwSupport);

but that is actually not the original callback function definition, it's like this:

BOOL ACMDRIVERENUMCB acmDriverEnumCallback(HACMDRIVERID hadid, DWORD dwInstance, DWORD fdwSupport);

the reason i changed it was that it wouldn't compile when i used ACMDRIVERENUMCB, a lot of compile errors showed. so i asked what could be wrong and one said that maby ACMDRIVERENUMCB was just a typedef of WINAPI so i used that, could that be where the problem lies? Thanks for your help.

redeemer

umm, not sure if it makes much sense, but this is the contens of it when the message appears: NTDLL! 77f9f9df() NTDLL! 77fb4966() NTDLL! 77fb3bdc() NTDLL! 77fa7131() NTDLL! 77fca4cb() MSMS001! 01ac7b68() MSMS001! 01ac7539() MSMS001! 01abfcf7() VCT3216! 01254326()

Daniel Lohmann

redeemer wrote: the reason i changed it was that it wouldn't compile when i used ACMDRIVERENUMCB, a lot of compile errors showed. so i asked what could be wrong and one said that maby ACMDRIVERENUMCB was just a typedef of WINAPI so i used that, could that be where the problem lies? I doubt it. (Maybe this is just because it was me who suggested you to change it ;P. However, I never said is a typdef for WINAPI, but it is a typedef for the pointer to listCallback. Take a look at the definition of ACMDRIVERENUMCB in the header file. The docs are just wrong here.) However, back to your problem: It works if you remove all code from your listCallback. Therefore it is probable (but not sure...) that the problem is caused by that code. (The exception messages you get are no problem. If the debugger does not claim about an unhandled exception they are catched inside MSACM32.DLL - nothing you should worry about.) Next step: Trackle it down. If it fails because of that code, check which part of the code (especially the calls to acmDriverDetails() and/or SendMessage()) causes the problem. (Don't forget to pass a valid string in SendMessage() if you remove the call to acmDriverDetails()!) -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D )