Nasty bluescreen in Win7 / Windowless mode
DirectShow programming library for .Net programmers
Brought to you by:
snarfle
Menu
▾
▴
Doing further tests of an application I've had working for several years in XP and Vista. I have it look for VMR7 or VMR9, and if it finds either sets up windowless mode so I can do some bitmap grabbing.
In Win7 I get a nasty BSOD when the app runs the windowless setup code. I "favor" VMR7 (for reasons I can't remember!) and it's in the VMR7 code that it blows up. The nearly identical code for VMR9 seems to work. The code for VMR7 and VMR9 is basically the same, except for calling the relevent methods for each.
I'm using the v1.5 library, and am running Win7 build 7100.
To set up the VMR7 in the graph I call this:
vmr = DirectCast(New VideoMixingRenderer, IBaseFilter)
hr = CType(graphBuilder, IGraphBuilder).AddFilter(vmr, "DS.NET Video Mixing Renderer 7")
DsError.ThrowExceptionForHR(hr)
Dim arc As IVMRAspectRatioControl = DirectCast(vmr, IVMRAspectRatioControl)
hr = arc.SetAspectRatioMode(VMRAspectRatioMode.LetterBox)
DsError.ThrowExceptionForHR(hr)
arc = Nothing
ConfigureVMRInWindowlessMode(hWin)
I get the BSOD if I leave in the Configure VMR code, which does this (hWnd is an IntPtr):
Dim hr As Integer = 0
Dim filterConfig As IVMRFilterConfig = DirectCast(vmr, IVMRFilterConfig)
hr = filterConfig.SetNumberOfStreams(1)
DsError.ThrowExceptionForHR(hr)
hr = filterConfig.SetRenderingMode(VMRMode.Windowless)
DsError.ThrowExceptionForHR(hr)
vmrCtrl = DirectCast(vmr, IVMRWindowlessControl)
hr = vmrCtrl.SetVideoClippingWindow(hWnd)
DsError.ThrowExceptionForHR(hr)
Good to know about v2.1. This is probably the last time I'll update this codebase before I revise it all in C#. I no longer have to do it in VB (for inner-department consistency) and I'd just as soon spend the time rebuilding from the ground up. The code I have now is part of a maintenance release for an older project I began in 2002 (in VB6 no less, using Geraint's overlay filter). No longer have any of that code in the current project, but anything I do from here on out will be all new, from scratch.
I've been meaning to also try out the new MediaFormat lib. I first tried it two years ago when there was a consulting prospect for using it, but my contact simple disappeared after I signed an NDA! Now that I'm working with Silverlight I have some plans for getting back into it.
While I have you on the phone, what's the real-world state of Media Foundation and the benefits thereof? With such good reviews for Win7 (I love it; never liked Vista) maybe there will be more users gravitating toward it? I've not picked up on MF simply because my userbase doesn't have the right OS.
We're wandering a little far afield from the topic of this thread.
I assume you already know that there are tools (free ones) that will take compiled vb code and decompile it to c#. Note that ugly vb code doesn't look any prettier in c#.
About Media Foundation. Hmm. Well, there are several things I see as problems.
-- First of all, it is considered part of the OS. This means that new features that get added don't get migrated back to previous OSes. For example, W7 adds device capture and some interfaces to make playback simpler. However, don't plan on using them in Vista.
-- Contrawise, vista doesn't have capture and playback can be a challenge.
-- DS has been around longer and has been used by more people. As a result, I believe it is more stable. Further, there are many more sample of using it out there, more people who are knowledgeable about it, and more products that support it. There are also a bunch of third party add-ins, which is something of a mixed blessing.
-- As you start digging in to MF, you find that it is firmly tied to WM. In fact, it has been stated that MF is just WM with a stronger DRM emphasis. Not something that recommends it to every developer.
-- DS has one main problem: MS isn't doing any real development work on it anymore. While that isn't really a problem today, one can envision the day when it will be.
For today I would still reach for DS to solve my AV related tasks. But that's primarily because it's the tool I know best. And perhaps because I feel more comfortable with the design approach DS took. But your tastes may be different.
IAC, keeping an eye on MF seems prudent. I've got a v2.0 of that library in the works too.
BlueScreen generally means a driver or hardware problem. It should not be possible for applications to cause a bluescreen.
That's what I thought, though I was very surprised to see that merely setting up VMR7 in windowless caused it. I guess it's a driver glitch, and I've been reading how some older XP drivers can cause BSODs of this nature. I installed Win7 as a dual-boot partition on a Vista box, so the driver ought not to be too old, but who knows.
For now I'll just use the VMR9 code, which works and is identical except that it of course calls the VMR9-specific interfaces and methods.
Could this problem be related to VMR7 relying on hardware, and VMR9 doing more in software? It's not the use of VMR7 generically (there's no problem there), but specifically running it in windowless mode.
The VMR7 internally use DirectDraw 7 and the VMR9 use Direct3D 9. Both technologies rely on the installed hardware and so on the Video Board Driver. What video board do you use ?
DirectDraw 7 is depreciated since Windows Vista so you should seriously consider upgrading your code to use the VMR9 (or better the EVR).
The way my code was written it was favoring VMR7, so even if a system had both, it would use VMR7 first, then fallback to VMR9, and if that failed, loaded the first renderer it found. It's something of a legacy app and since it's proven to work for several years I didn't want to monkey with it!
As it is, I'm now bypassing the VMR7 check completely, and am only checking for VMR9. (If that's not installed I fall back to the default VMR, and disable the bitmap grabbing. This also keeps the player in windowed mode.)
I checked and the Win7 installer updated the device driver for my machine to one dated 6/2009. The system says it's up to date. The driver is an Intel G33/G31 chipset (it's an HP machine so I assume the graphics board is integrated). The Win7 install is 100% clean, with no updates other than what Windows Updater has done, and my test app.
Have you tried to install the latest DirectShow which is now part of the Windows SDK? It seems there are some changes for Win7.
DirectShow is not a component that is installed as part of the SDK. The c++ header files and libraries are indeed in the SDK, but starting with Vista, the actual code is part of the OS. So, the only way to get W7 features is to install W7.
Plus there's virtually no sense in installing files over an RC that is only a month or so old, for an app intended for end users. If Microsoft didn't get that right for some reason, and are including old files, then there are lots of apps that will break!
Pretty sure it's some odd combination of hardware that doesn't like VMR7 in windowless mode. Since I don't think the code is faulty (the VMR9 version works swell), I wonder how many systems will be impacted when Win7 hits retailers.
I am using an older version of DirectShowLib, and maybe it has some variance in setting up VMR7 for windowless, but as mentioned previously, that should never cause a BSOD. Gotta be a driver flipping out.
An older version? The current version is 2.0. It's been out there a long time now
Correct. I think the version I'm using is 1.5 (originally with the old Code Project library). I told you my app was legacy!
I do plan on updating to the latest lib one day, but I'm concerned with any breaking changes in the new lib that my testing won't catch - I don't have the luxury of asking the client to allocate resources for inhouse testers, so any testing will be 100% up to me. The software has already been vetted over the years, but with Win7 poised to come out soon, I thought I'd run limited tests with it. Not happy with what I discovered, but maybe it'll be limited to a small subset of machines out there.
All the "breaking" changes in v2.0 should show up with a recompile. However, I understand your caution.
If you are preparing to spend the time and effort to do it anyway, I will mention that there is a v2.1 in the works. I don't have a specific date I can give you, but I'm guessing more than a week and less than a month.