'Access is Denied' message from IMediaControl.Pause()
James
IMediaControl.Pause() method. Any ideas that would point me in a good
direction to fix this? I haven't found any information regarding the
IMediaControl class and this particular exception.
System.UnauthorizedAccessException: Access is denied. (Exception from
HRESULT: 0x80070005 (E_ACCESSDENIED))
I've got a button in the application that when pressed creates the
graph. The graph runs successfully once. Then the graph is destroyed.
All the filters are removed, etc. When the button is pressed a second
time and I try to run the graph, I get the above exception. It looks
like the graph is built correctly, I can connect to the graph in
GraphEdit and the graph looks good, but when I call the
IMediaControl.Pause() method just after creating the graph the exception
occurs. (Same code that just ran the graph successfully the first
time).
Another interesting thing is that if I use GraphEdit to save the graph
to a .grf file, then open the graph later with GraphEdit and run the
graph, the graph runs successfully. So it looks like the graph is ok,
but for some reason I can't start it a second time from within my
application.
I believe I'm releasing and destroying all the objects when I destroy
the first graph. I've been through that code many times now.
The graph is a capture graph whose source filter is a digital camcorder.
I'm using the SmartTee filter to provide both capture to a file and a
preview window.
Camera --> SmartTee --> SampleGrabber --> Mux --> FileWriter
|
--> Splitter --> DV Decoder --> Video Renderer
|
--> Audio Renderer
Regards,
James
Iain
Have you changed output file names between runs?
It may be that the file is still locked.
AVI files can take some time to close (because indexing information needs
to be written).
It may be the graph is not completely torn down holding the output file
open.
Iain
--
Iain Downs (DirectShow MVP)
Commercial Software Therapist
www.idcl.co.uk
James
news:1v3ydsomjw4xb$.xj81r9x5...@40tude.net:
Thanks Iain. Starting to look I've been barking up the wrong tree. I
just ran Process Explorer from systernals and it does show that the file
is kept open. Now I've got to figure out why the files are not being
closed. They are staying open and not closing after the graph is
destroyed. I don't have any specific information on why yet.
James
Iain
>
> Thanks Iain. Starting to look I've been barking up the wrong tree. I
> just ran Process Explorer from systernals and it does show that the file
> is kept open. Now I've got to figure out why the files are not being
> closed. They are staying open and not closing after the graph is
> destroyed. I don't have any specific information on why yet.
>
> James
I'm told a large AVI DV file can take many minutes or even hours to close.
This is because it is writing indexes (these are written when Stop() is
called. Clearly this is asynchronous and holds the file open [and the
graph like as not] until the index write is complete] . I know no more
than this (though I have experienced the effect).
There's been a fair amount of discussion of this in the past in this group
Thore Karlsen [DShow MVP]
wrote:
>> Thanks Iain. Starting to look I've been barking up the wrong tree. I
>> just ran Process Explorer from systernals and it does show that the file
>> is kept open. Now I've got to figure out why the files are not being
>> closed. They are staying open and not closing after the graph is
>> destroyed. I don't have any specific information on why yet.
>I'm told a large AVI DV file can take many minutes or even hours to close.
>This is because it is writing indexes (these are written when Stop() is
>called. Clearly this is asynchronous and holds the file open [and the
>graph like as not] until the index write is complete] .
It is not asynchronous, Stop() won't return until the index is written.
After Stop() returns, you should be able to do what you want with the
file. I haven't had any problems with the file being locked after I have
stopped the graph.
--
New to newsgroups? Read: http://dev.6581.com/newsgroups.html
Iain
WHat happens if you Stop on one thread and destroy the graph on another?
I HAVE had problems with the file being locked after stop is called and
there have been reports of this in the group (IIRC). [Though they're recent
and I haven't looked into them yet]
James
news:5hn30snv8ek0.9...@40tude.net:
> On Sun, 26 Feb 2006 11:31:25 -0600, Thore Karlsen [DShow MVP] wrote:
>
>> On Sun, 26 Feb 2006 17:09:01 +0000, Iain <Ia...@idclTAKEAWAY.co.uk>
>> wrote:
>> It is not asynchronous, Stop() won't return until the index is
>> written. After Stop() returns, you should be able to do what you want
>> with the file. I haven't had any problems with the file being locked
>> after I have stopped the graph.
>
> WHat happens if you Stop on one thread and destroy the graph on
> another?
>
> I HAVE had problems with the file being locked after stop is called
> and there have been reports of this in the group (IIRC). [Though
> they're recent and I haven't looked into them yet]
>
> Iain
I've determined that the file is being closed correctly after the capture
graph.
My problem is with a DES graph that I create just after the capture graph
closes. The DES graph opens 2 handles to the file that do not get closed.
So that when I run the capture graph again, the file is still open and I
get the access is denied message. I've yet to determine the problem with
the DES graph. Could be that I'm not destroying it correctly. I'm working
on that now.
James
Thore Karlsen [DShow MVP]
wrote:
>> It is not asynchronous, Stop() won't return until the index is written.
>> After Stop() returns, you should be able to do what you want with the
>> file. I haven't had any problems with the file being locked after I have
>> stopped the graph.
>WHat happens if you Stop on one thread and destroy the graph on another?
The graph won't be destroyed until it's stopped, so both threads will
wait until the index is written and the file is closed.
>I HAVE had problems with the file being locked after stop is called and
>there have been reports of this in the group (IIRC). [Though they're recent
>and I haven't looked into them yet]
Yes, I've seen those reports, but I can't help but think there's
something else wrong in those cases. Like in this case, it looks like
it's DES that's keeping the file open, not the AVI mux.
lgs.lgs
IMediaControl->Pause()), I'm guessing you are using .NET?
If so, you might try adding
GC.Collect();
GC.WaitForPendingFinalizers();
This should force a release of any COM objects that you failed to explicitly
release. If that fixes it, you can go back and look for what you missed.
James
news:5hn30snv8ek0.9...@40tude.net:
> On Sun, 26 Feb 2006 11:31:25 -0600, Thore Karlsen [DShow MVP] wrote:
>
>> On Sun, 26 Feb 2006 17:09:01 +0000, Iain <Ia...@idclTAKEAWAY.co.uk>
>> wrote:
>> It is not asynchronous, Stop() won't return until the index is
>> written. After Stop() returns, you should be able to do what you want
>> with the file. I haven't had any problems with the file being locked
>> after I have stopped the graph.
>
> WHat happens if you Stop on one thread and destroy the graph on
> another?
>
> I HAVE had problems with the file being locked after stop is called
> and there have been reports of this in the group (IIRC). [Though
> they're recent and I haven't looked into them yet]
>
> Iain
Are there any known issues/fixes regarding DES graphs leaving open handles?
I compiled the example code from MSDN and it has the same issues as my
code.
http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-
us/directshow/htm/samplecodedes2.asp
Running this code and watching the process with Process Explorer from
systernals, I can see that 2 file handles are opened to the file. These
handles are not closed even after the graph is stopped and destroyed. I
put a long loop following the CoUninitialize() call so that I could see
what resources were left after the graph.
I have the Dec 2005 release of the Directshow SDK and just downloaded the
most recent Platform SDK. msinfo32 shows my DirectX version as 9.0c
(4.09.0000.0904). The OS is Windows XP Pro SP2.
Regards,
James
Iain
Fair enough. AS I said, I've had a report of this happening with an app I
just put out (a beta, I hasten to add!) so I'll post the outcome (unless
it's plain too embarassing!).
The March Hare [MVP]
> Running this code and watching the process with Process Explorer from
> systernals, I can see that 2 file handles are opened to the file. These
> handles are not closed even after the graph is stopped and destroyed. I
> put a long loop following the CoUninitialize() call so that I could see
> what resources were left after the graph.
Sounds like a bug. The only things I didn't see (but may have missed) is:
1. Are you adding the graph to the ROT for viewing in GraphEdit? This is
known to cause problems.
2. Are you running a debug build? If so, try running a release build to
see if it makes any difference.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
James
news:ih5rlifo3oqp$.1ryk8kctc4ryr$.d...@40tude.net:
> On Mon, 27 Feb 2006 04:40:47 GMT, James wrote:
>
>> Running this code and watching the process with Process Explorer from
>> systernals, I can see that 2 file handles are opened to the file.
>> These handles are not closed even after the graph is stopped and
>> destroyed. I put a long loop following the CoUninitialize() call so
>> that I could see what resources were left after the graph.
>
> Sounds like a bug. The only things I didn't see (but may have missed)
> is:
>
> 1. Are you adding the graph to the ROT for viewing in GraphEdit?
> This is known to cause problems.
No, I compiled the code that came straight from the MSDN example. The only
modification was a loop at the end so I could watch resources being
released from the graph.
>
> 2. Are you running a debug build? If so, try running a release build
> to see if it makes any difference.
>
I just tried again with a release build. Same results. Two file handles
remain open to the file that is rendered.
James
Joe Flynn
James wrote:
> Are there any known issues/fixes regarding DES graphs leaving open handles?
>
> I compiled the example code from MSDN and it has the same issues as my
> code.
>
> http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-
> us/directshow/htm/samplecodedes2.asp
>
> Running this code and watching the process with Process Explorer from
> systernals, I can see that 2 file handles are opened to the file. These
> handles are not closed even after the graph is stopped and destroyed. I
> put a long loop following the CoUninitialize() call so that I could see
> what resources were left after the graph.
>
> I have the Dec 2005 release of the Directshow SDK and just downloaded the
> most recent Platform SDK. msinfo32 shows my DirectX version as 9.0c
> (4.09.0000.0904). The OS is Windows XP Pro SP2.
>
I ran some of my test code to see if it exhibited this problem and the
results were negative (I used SysInternals Process Explorer). I then
took the code referenced in your link above and compiled it (Release
Build - Static Linking) in both the Visual Studio 6 and .NET 2003
environments (.NET2003 is running with the Feb2005 DX SDK) and again the
results were negative. The OS platforms used for the tests were Win98SE,
XP Pro SP1, and XP Pro SP2. For my video test clips I used two clips -
one uncompressed AVI and the other using Cinepak.
I would offer to test with a later release of the DShow SDK but I have
seen too many problems posted here from people having issues getting the
Platform and DShow SDKs up and running properly - and I don't really
need the headaches right now. :)
Joe Flynn
The March Hare [MVP]
> I would offer to test with a later release of the DShow SDK but I have
> seen too many problems posted here from people having issues getting the
> Platform and DShow SDKs up and running properly - and I don't really
> need the headaches right now. :)
Smart man. IIABDFI. I won't upgrade to VC8, the latest PSDK and DX SDK
until there is a compelling reason to (x64 support, for example).
Thore Karlsen [DShow MVP]
<ph...@ndsm.maps> wrote:
>> I would offer to test with a later release of the DShow SDK but I have
>> seen too many problems posted here from people having issues getting the
>> Platform and DShow SDKs up and running properly - and I don't really
>> need the headaches right now. :)
>Smart man. IIABDFI. I won't upgrade to VC8, the latest PSDK and DX SDK
>until there is a compelling reason to (x64 support, for example).
Compelling reason to upgrade to VC8: Can take advantage of multiple
CPUs, debug iterators, better support for standard library containers in
the debugger, determines which projects are outdated quicker, etc.
Personally I haven't had any problems using VC8 with the latest PSDK and
DX SDK. I did have to make a few changes in the base classes, but I have
a copy of the base classes in my solution so I only have to make those
changes there.
The March Hare [MVP]
> Compelling reason to upgrade to VC8: Can take advantage of multiple
> CPUs, debug iterators, better support for standard library containers in
> the debugger, determines which projects are outdated quicker, etc.
Better debugging with iterators and better STL support in general is
definitely one reason. I like having my other CPU free for me though <g>
> Personally I haven't had any problems using VC8 with the latest PSDK and
> DX SDK. I did have to make a few changes in the base classes, but I have
> a copy of the base classes in my solution so I only have to make those
> changes there.
You don't use the IDE though, correct? I tried it when it first released
and got a few crashes. I've read that others are experiencing crashes too.
I also would have to modify my baseclasses ( which are based on yours :)
Thore Karlsen [DShow MVP]
<ph...@ndsm.maps> wrote:
>> Compelling reason to upgrade to VC8: Can take advantage of multiple
>> CPUs, debug iterators, better support for standard library containers in
>> the debugger, determines which projects are outdated quicker, etc.
>Better debugging with iterators and better STL support in general is
>definitely one reason. I like having my other CPU free for me though <g>
But if you get a quad core you can have one CPU for you and three for
VS2005. :)
Another thing I like is that it's finally easy to back up and restore
settings. That was about time!
>> Personally I haven't had any problems using VC8 with the latest PSDK and
>> DX SDK. I did have to make a few changes in the base classes, but I have
>> a copy of the base classes in my solution so I only have to make those
>> changes there.
>You don't use the IDE though, correct? I tried it when it first released
>and got a few crashes. I've read that others are experiencing crashes too.
Hmm.. I use the IDE for compiling and debugging, but not editing. Is the
editor where you are seeing the crashes? I also use it for ASP.NET
stuff, but again I don't use the editor much there.
>I also would have to modify my baseclasses ( which are based on yours :)
I'm glad to see that someone is taking my bug reports seriously. ;)
James
news:OMdKTeAP...@TK2MSFTNGP12.phx.gbl:
>
> James wrote:
>> Are there any known issues/fixes regarding DES graphs leaving open
>> handles?
>>
>> I compiled the example code from MSDN and it has the same issues as
>> my code.
>>
>> http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/
>> en- us/directshow/htm/samplecodedes2.asp
>>
>> Running this code and watching the process with Process Explorer from
>> systernals, I can see that 2 file handles are opened to the file.
>> These handles are not closed even after the graph is stopped and
>> destroyed. I put a long loop following the CoUninitialize() call so
>> that I could see what resources were left after the graph.
>>
>> I have the Dec 2005 release of the Directshow SDK and just downloaded
>> the most recent Platform SDK. msinfo32 shows my DirectX version as
>> 9.0c (4.09.0000.0904). The OS is Windows XP Pro SP2.
>>
>
> I ran some of my test code to see if it exhibited this problem and the
> results were negative (I used SysInternals Process Explorer). I then
> took the code referenced in your link above and compiled it (Release
> Build - Static Linking) in both the Visual Studio 6 and .NET 2003
> environments (.NET2003 is running with the Feb2005 DX SDK) and again
> the results were negative. The OS platforms used for the tests were
> Win98SE, XP Pro SP1, and XP Pro SP2. For my video test clips I used
> two clips - one uncompressed AVI and the other using Cinepak.
>
> I would offer to test with a later release of the DShow SDK but I have
> seen too many problems posted here from people having issues getting
> the Platform and DShow SDKs up and running properly - and I don't
> really need the headaches right now. :)
>
>
>
> Joe Flynn
>
>
I just ran the same executable on a second computer. No files handles were
left open. Looks like something with my system. I did try uninstalling
the Dec2005 SDK and installed the Feb2005 DX SDK, no luck, I still get the
open file handles.
James
The March Hare [MVP]
> I just ran the same executable on a second computer. No files handles were
> left open. Looks like something with my system. I did try uninstalling
> the Dec2005 SDK and installed the Feb2005 DX SDK, no luck, I still get the
> open file handles.
Quite possibly you have a rogue decoder on your system. Try running the
GSpot Codec tool (see my Links page) on a typical file and compare the
results on the two systems.
The March Hare [MVP]
> But if you get a quad core you can have one CPU for you and three for
> VS2005. :)
I'm waiting for a more stable Vista build for that. BTW, do you know if
they've improved the power management so you can hibernate and sleep with
dual processors? That's one of the biggest pains with my current machine.
I think it's a limitation of ACPI or whatever the power management is
called. I want to get a motherboard that supports instant-on for Vista but
I don't know if the dual proc ones do that. If you don't know, Chris or
Alessandro probably do.
> Another thing I like is that it's finally easy to back up and restore
> settings. That was about time!
That's another good one.
> Hmm.. I use the IDE for compiling and debugging, but not editing. Is the
> editor where you are seeing the crashes? I also use it for ASP.NET
> stuff, but again I don't use the editor much there.
IIRC, it was with Intellinonsense ;)
>>I also would have to modify my baseclasses ( which are based on yours :)
>
> I'm glad to see that someone is taking my bug reports seriously. ;)
I take your advice very seriously :)
Thore Karlsen [DShow MVP]
<ph...@ndsm.maps> wrote:
>> But if you get a quad core you can have one CPU for you and three for
>> VS2005. :)
>I'm waiting for a more stable Vista build for that. BTW, do you know if
>they've improved the power management so you can hibernate and sleep with
>dual processors? That's one of the biggest pains with my current machine.
>I think it's a limitation of ACPI or whatever the power management is
>called. I want to get a motherboard that supports instant-on for Vista but
>I don't know if the dual proc ones do that. If you don't know, Chris or
>Alessandro probably do.
I'm not sure, since I never use hibernate. Don't have a laptop, and my
desktop machine is on all the time. Speaking of Vista, has anyone here
tried any capture devices with WDM drivers on Vista?
>> Hmm.. I use the IDE for compiling and debugging, but not editing. Is the
>> editor where you are seeing the crashes? I also use it for ASP.NET
>> stuff, but again I don't use the editor much there.
>IIRC, it was with Intellinonsense ;)
Ah, same old story then. Intellisense seems to have been a constant
source of headaches for everyone using it. My Intellisense is limited to
word completion in Vim and Alt-Tabbing to MSDN. Hey, at least it's
faster than restarting a crashed IDE several times a day. ;)
Iain
> Compelling reason to upgrade to VC8: Can take advantage of multiple
> CPUs, debug iterators, better support for standard library containers in
> the debugger, determines which projects are outdated quicker, etc.
>
> Personally I haven't had any problems using VC8 with the latest PSDK and
> DX SDK. I did have to make a few changes in the base classes, but I have
> a copy of the base classes in my solution so I only have to make those
> changes there.
I've been running 2005 for some time with a variety of applications
(including DS).
Once you've got everything working (!) I'm only seeing relatively
infrequent crashes of the IDE and it's as likely to be due to me using x64
as 2005.
But VS2005 is not finished. It is buggy, does odd things from time to time
and I don't think all of that's x64 (though they've managed to lose edit
and continue with x64 in .net which is more than a tad annoying).
James
news:1wl993io31rmv.h...@40tude.net:
> On Tue, 28 Feb 2006 03:11:22 GMT, James wrote:
>
>> I just ran the same executable on a second computer. No files
>> handles were left open. Looks like something with my system. I did
>> try uninstalling the Dec2005 SDK and installed the Feb2005 DX SDK, no
>> luck, I still get the open file handles.
>
> Quite possibly you have a rogue decoder on your system. Try running
> the GSpot Codec tool (see my Links page) on a typical file and compare
> the results on the two systems.
>
>
Good call. I had a filter from Elecard that was in the graph. Once I
uninstalled the Elecard mpg encoders, everything works correctly.
Thanks for all the help.
The March Hare [MVP]
>> Quite possibly you have a rogue decoder on your system. Try running
>> the GSpot Codec tool (see my Links page) on a typical file and compare
>> the results on the two systems.
>>
>>
>
> Good call. I had a filter from Elecard that was in the graph. Once I
> uninstalled the Elecard mpg encoders, everything works correctly.
Glad you got it working. You may want to report this to Elecard. They're
general responsive to issues from what I've seen.