Attempted to read or write protected memory
DirectShow programming library for .Net programmers
Brought to you by:
snarfle
Menu
▾
▴
One of my users is getting a "Attempted to read or write protected memory..." error. While previewing the video, it will occassionally throw this exception when MediaControl.Stop() is called, just before starting to record.
He is running Vista 64-bit. The software is compiled to run as a 32-bit app, since he was having even more problems when it was compiled for any CPU.
If anyone can point me in the right direction, I'd appreciate it.
Thanks,
Randy
Are you using DsRotEntry? Do you wait for the graph to completely stop before doing anything else? Remember, the Stop call is async.
To help in troubleshooting, I did enable DsRotEntry, when I recompiled as a 32-bit app, so this user could send me a screenshot of his graph. Originally, he was saying that he could preview but not record. He can record now, but was occasionally getting this exception.
According to the stack trace, the exception is being thrown at DirectShowLib.IMediaControl.Stop()
So, I take it you think the exception is occurring because of the DsRotEntry being enabled?
Given the lack of data, it's just a guess. A bad filter could also be involved.
I'll go ahead an pull it out of there and see if that problem goes away. He wasn't able to get GraphEdit to connect anyways.
On verifying that the graph has actually stopped, do you recommend putting in a loop right after to check GetState() before proceeding with the recording?
In Vista, failure to connect to a graph may mean proppage.dll hasn't been regsvr32'ed. Note that there are separate dlls for 32 and 64 bit, and that the vista proppage is different from the one that shipped in previous sdks. Also, there is a bug that affects 64bit attempts to connect to graphs (https://sourceforge.net/tracker/?func=detail&aid=2612087&group_id=136334&atid=735691).
For Stopping preview graphs, I wouldn't expect it to take even a full second. However, stopping captures to avi files can take much longer.
Seems like there are lots of bugs and device driver issues with 64 bit systems, especially with Vista in the mix.
Anyways, I do want to go from preview to record as quickly as possible. Since IMediaControl.Stop() is an async call, then it seems I really should verify that the graph is stopped before I add the compressor filter to it and initiate the recording. I hadn't really seen anything like that in any of the example projects, that I can recall.
It's true few (if any) of the samples do this. Of course most of the samples are limited by waiting on user input (clicks, etc). That generally gives plenty of time for the graph to finish what it's doing before needing to start something else.
As for the 64 bit stuff, well, it's new for a lot of people, and there haven't been near as many customers using it yet as x86. Over time, presumably these will get shaken out too.
That's no excuse for the filter writers or OS developers who are writing bad code, but there it is. We had some issues in our code as well, so I'm not in the best position to throw stones. We cleaned up most of them in v2.0, but as you saw from my previous post, we missed (at least) one more.
I am getting the same problem here calling IMediaControl.Stop(), happening
occasionally.
I am running Vista 32 bits, compiling AnyCPU. It is the only problem I am
getting right now compiling in this environment using these settings.
Did you find the cause of the problem? How did you fix it?
Best regards