I have this sort of runtime error in a fairly involved project:
---------------------------
main.exe - Application Error
---------------------------
The instruction at "0x0411b00e" referenced memory at "0x00000020". The memory could not be "read".
---------------------------

Background info:
Its a realtime app, and I can't really run a debugger since there's a high-priority thread being started by a device driver, and stepping through code would immediately break the app.

The app loads a DLL that processes some audio in real-time. Loading a DLL from one vendor runs perfectly, audio gets processed and I can hear back the result. But loading a DLL from a different vendor gives me this  runtime error. Another thing is I can show the GUI (if its available) of either DLLs, (generally audio plugins do come with GUI's). Both plugins show the GUI and I can interact with it with no issues. But trying to process audio on one of the DLLs fails.

I've tried it with over a dozen vendor DLLs. So far there's only one that fails. Its not so uncommon for an audio processing plugin to fail, but I'd like to know _why_. There are many plugin hosts on the market, and I've tried this specific DLL with a few of them, it seems to work. So something with my piece of the code might be wrong.

My real question is: how do I even begin to debug code that needs to run in realtime? There's no memory debugger for D2 that I know of (maybe Vlad will port his Diamond to D2 one day :) ), I've tried using a stacktrace but its not of much help, all I get back is this:

00 D:\dev\projects\sequencer\src\.\stacktrace\stacktrace.d::57(0) _D10stacktrace10stacktrace10StackTrace32UnhandeledExceptionFilterHandlerWPvZi
01 UnhandledExceptionFilter
02 ValidateLocale

Wrapping my main() inside a try{}catch{} doesn't help either, even if I try to catch Throwable's. So it might be an exception thrown from within a DLL. Or not. :)

I'm a complete newbie when it comes to runtime bugs like these. Any good resources, something to read, or techniques, to figure this out? Something tells me I'll just have to dive in neck-deep into the disassembly..

Actually it looks like I can recreate this bug in non-realtime mode as well. I forgot that I can actually process audio at whatever timing I want to (I haven't touched this project in a while..). Oddly enough I can call various DLL functions but it fails the second I try to pass some audio data to it. Other plugins work fine. I wonder what I'm missing here..

On 3/27/2011 7:58 PM, Andrej Mitrovic wrote:
> Actually it looks like I can recreate this bug in non-realtime mode as
> well. I forgot that I can actually process audio at whatever timing I
> want to (I haven't touched this project in a while..). Oddly enough I
> can call various DLL functions but it fails the second I try to pass
> some audio data to it. Other plugins work fine. I wonder what I'm
> missing here..
Are you passing D data to a C or C++ dll?

It may be related to size and alignment of any data passed.  When I wrote wrappers for freetype2 I used long for my dll calls forgetting that long and int are the same size for C.

It could also be Structured Exception Handling used by Windows.

I've found the problem and the solution, see this post: http://www.kvraudio.com/forum/viewtopic.php?p=4467686#4467686

I completely forgot that the VST standard has at least two different implementations, v2.3 and v2.4. And I've also forgot that I need to ask the DLL if it supports calling one of two different function implementations. The problem was I was calling a function that's only defined in the v2.4 standard, but this vendor-specific DLL conforms to v2.3 and didn't have it.

So luckily this wasn't such a big problem at all. Yay! :)