Well Gee... I was general because I wasn't sure if this was the area to post it in! But since you ask, let me say this before I describe the details. As a programmer myself, ANY combination of actions that can repeatably result in a program abort is certainly a bug. Granted there are many bugs that actually can be traced to operating system or peripheral supplied DLLs and services. There are even bugs in the Direct-X 9 this program uses, which is why there is Direct-X 10. But the point is if it were my product and that happened, I'd look for a work around.
Anyway, here's the issue. It relates to sound processing during export. As near as I can tell, it is the result of (a) having used the audio editor to modify the volume envelope of a segment of the native audio portion of a clip, specifically to boost the volume of important content at that point, and ( Attempting to export the audio WITH the box checked to NORMALIZE the audio in the entire exported file. After crashing at the same point in the export repeatedly, I came to realize it was crashing while processing that portion of the project where my graphically drawn volume boost was occurring. Undoing the NORMALIZE resulted in a clean export.
I realize that details can be a factor, and it is obviously impossible to send you an entire project when huge video clips are involved. But in case it matters, the main Video track (as opposed to clips I had in the overlay track) was an AVI file, and the output method I had chosen was DV format AVI. I don't know exactly what type of AVI file the original imported clip was. there were also some speare audio clips in the audio track, but there were no such audio clips in the portion of the project that would caust the crash.
I believe some kind of math error is occuring, perhaps an un-handled overflow exception, and probably due to a conflict between the normalize function and the volume boost produced by the envelope built up graphically in the sound editor. The resulting crash would display the typical warning that "the program has encountered a problem and needs to shut down", along with a dialog box referencing a pure virtual function call that had failed. The title bar on that dialog box specifically mentioned VideoWave, so there is a reasonable likelihood there is an oversight in the product code.
A simple NORMALIZE function typically works by pre-scanning an entire audio track (or clip) to find the greatest peak amplitude. It then calculates a factor to multiply that loudest peak by in order to achieve the maximum possible number within the allowed (usually 16 bit ) resolution. As the file is processed, it then multiplies every data point in the sound track by that number. So the problem may lie in the pre-scan not taking the manual volume boost into account, thus causing an overflow condition when the boost AND the normalize factor are both applied..
That's just a guess at what's going on. In any case, the problem is repeatable, and if the company is interested in resolving it I'd be happy to try a few recommendations. Obviously I KNOW now how to avoid the problem. But it seems that either a smarter NORMALIZE algorithm is in order. I use a lot of high end audio software that handles such unintended user generated audio overflows without crashing. Unintentional audio overflows are too easy to do, and the program should predict and CATCH such exceptions.