It's quite rare for me to find an AAF file that has me tearing my hair out - but I've found one with the weirdest behaviour I've ever seen.
I'm running the Windows SDK. If I open the AAF file in a Console app (such as InfoDumper) everything works fine. I don't actually need to run InfoDumper itself. I can just step through the code until the point where the input file gets opened - and then I immediately jump to the bit that closes it. No problems at all.
However, if I try the same thing using a conventional Windows app, simply opening the file and closing it again causes dozens of memory leaks. No matter how simple I make the app, I can't seem to just open this AAF file and close it again without all the errors. In both cases, I'm using AAFFileOpenExistingRead() and I close the file by calling pFile->Close() on the returned pointer, followed by pFile->Release().
Can anyone think of a difference between a standard Windows app and a Console app? For example, I assume they use different CRT libraries??? More importantly, is there anything in the toolkit that behaves differently between a Windows app and a Console app?
I should add that I've got hundreds of other AAF files that all behave as expected. It's just this one file that exhibits this strange behaviour.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's quite rare for me to find an AAF file that has me tearing my hair out - but I've found one with the weirdest behaviour I've ever seen.
I'm running the Windows SDK. If I open the AAF file in a Console app (such as InfoDumper) everything works fine. I don't actually need to run InfoDumper itself. I can just step through the code until the point where the input file gets opened - and then I immediately jump to the bit that closes it. No problems at all.
However, if I try the same thing using a conventional Windows app, simply opening the file and closing it again causes dozens of memory leaks. No matter how simple I make the app, I can't seem to just open this AAF file and close it again without all the errors. In both cases, I'm using AAFFileOpenExistingRead() and I close the file by calling pFile->Close() on the returned pointer, followed by pFile->Release().
Can anyone think of a difference between a standard Windows app and a Console app? For example, I assume they use different CRT libraries??? More importantly, is there anything in the toolkit that behaves differently between a Windows app and a Console app?
I should add that I've got hundreds of other AAF files that all behave as expected. It's just this one file that exhibits this strange behaviour.
I should have added that both the Open and Close methods return AAFRESULT_SUCCESS.