All sorted! My assumptions were completely wrong. It turns out I was not allocating enough room for a call to a DLL procedure which returned a pChar string. There is no documentation on the size of the string returned and I thought I had allocated plenty. It was obviously enough for some of the plugins but not others.
It was difficult to track down because the error only occured after the local variable holding the pChar was destroyed as my procedure completed execution. Thanks for all the help. Ross. ----- Original Message ----- From: "Ross Levis" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Wednesday, July 06, 2005 2:05 PM Subject: Re: ignoring DLL exceptions Steve Williams wrote > First place to look when getting crashes accessing DLLs written in C > is > to check the calling convention of the functions in your code. Are > the > functions in your code that the DLL is calling specified correctly? > cdecl or stdcall? Yes, all functions and procedures are declared with cdecl. Several plugins work fine and they are repeatedly calling functions in my app to provide the audio data and visualization data. Perhaps there are some undocumented calls to the main app from some of these DLL's. When the problem occurs, the CPU window appears immediately sitting at address 0. If I select the Caller option on the right-click menu, it jumps to address 7C90378B which is POP EDI. I'm not sure if that means anything or not. This is in the routine ntdll.RtlConvertULongToLargeInteger. The top of the stack has the value 7C9037BF which is close to that address. EDI and ESI registers contain 0. I'm not sure if this is useful information or not. It's too low level for me. The DLL is using a thread to convert the audio to PCM and it is after the thread starts that the error occurs. Any other suggestions welcome. Regards, Ross. _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
