Without Supervision

Today I compiled the WavDest DirectShow sample program included in the Windows SDK (the one that is oh-so-reassuringly referred to as “WavDes” on the MSDN Web page). It compiled fine after conversion to VS2010. Then, I opened a command window (running it as adminstrator, of course), changed to the directory containing wavdest.dll, and solemnly entered this:

regsvr32 wavdest.dll

What I have laughingly (ever since Windows 7) continued to refer to as “my” computer replied with this:

Which seems pretty unequivocal, wouldn’t you agree? Seemed that way to me. However, the filter didn’t show up in graphedt.exe. Hmmm…, so I tried to unregister it:

regsvr32 /u wavdest.dll

And got this:

“You have got to be kidding me,” I said to my machine. I don’t know why I keep telling my computer it must kidding me. It never is. As far as I can tell, my computer has no sense of humor whatsoever. But I said it because it seemed as though I had registered a filter that had some kind of bug preventing it from appearing on the visible list of DirectShow filters, and that also prevented me from unregistering it.

My computer had become The Black Hole for buggy filters. Once they go in, they don’t come out. (Or am I talking about New York in 1997?)

Here’s the problem: regsvr32 was trying to be helpful. For a variety of badly documented reasons, regsvr32 will ignore a file by the name of, say, “wavdest.dll,” if that exists in your current directory when you run regsvr32, provided that it can find a file of that name elsewhere first. Where does it look? Ah, well, you won’t learn the answer to that by reading a page in the technet subdomain of microsoft.com. (I only found that by following the link at Wikipedia’s page on regsvr32; a lot of searching at MSDN didn’t turn it up.) That one tells you regsvr32 registers your dll, but it doesn’t say anything about the fact that it may not register your dll. That’s elsewhere too.

Apparently, regsvr32 works by calling LoadLibrary (or, in some opinions, by calling LoadLibraryEx). Both of which include in their documentation a whole bunch of convoluted language that, in simple terms that even I can understand, amount to, “You should use a fully qualified path to specify your down dll when using regsvr32.” That’s because those functions look in a whole convoluted list of places for files that match any not-fully qualified path you might give regsvr32 first.

In the case of wavdest.dll, it finds one. It is in C:\Windows and, as far as I can tell, has no connection to the DirectShow sample I was interested in. Nor, apparently, can it be unregistered, notwithstanding that it returns success when registered with regsvr32. In any case, the sure way to register what you think you are registering is to use fully qualified paths, every time you use regsvr32.exe, like this:

regsvr32 C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\
multimedia\directshow\filters\wavdest\Debug\wavdest.dll

No, I am not kidding you. (Gee, it’s rare when I get to say that.) Note that, despite what it says on Wikipedia, a relative path will not make any difference. That is, if you try this:

regsvr32 .\wavdest.dll

you will still load the wrong one.

Lesson from all this: When you specify a file for regsvr32 to register, be explicit and use a fully qualified path.

By the way, I ran into a similar problem using Java, which should have tipped me off to this sooner, but the art of computer programming would appear to be defined by the act of figuring out why something you’ve done right still doesn’t work.

Odds are pretty good that, if you are developing a DirectShow filter, you will want to register your filter so graphedt.exe¹ can “see” it. That is, you will want it to show up on the list of filters graphedt.exe offers when you pick “Insert Filters…” from the “Graph” menu. (You can add filters to a DirectShow graph without registering them, which can be useful if you want to keep your filter contained within your application, and not available to others; see Geraint Davies’s explanation on how this can be done.)

A simple way to do this is to open a command window, “cd” your way to the directory containing your filter’s .dll file, and use this command:

regsvr32 myfilter.dll

When you do, you might see this:

That’s what I got, the first time I used that command. The advice is the kind of thing that gives DirectShow some of its notoriety: search online it says. Might as well say, here there be dragons, eh? Anyway, the solution (in my case) was to right-click on the “Command Prompt” application under “Accessories” in the Start menu (or whatever it’s called now on Windows 7, which only shows you the funny waving-flag Windows logo, so maybe it doesn’t have a name anymore), and choose “Run as administrator” to start it up. Then that regsvr32 command worked fine.

But what about searching online? Well, the first (non-paid) hit on Google took me to a page in Microsoft’s Knowledge Base. It wasn’t about installing .dll files. It was about updating your operating system. Nice to imagine that installing your own code and updating your system might, in some way, be the same thing, but it doesn’t immediately suggest this is really related to the problem I’m talking about here. Regardless, it does, sort of, offer the same solution: it says, “Log in as an administrator.”

Now, one of the things I really have grown to dislike about Windows 7 is the frequency with which it decides I don’t have rights to my own computer. For example, if I click on “Documents and Settings” under the “C:” drive in the directory tree in Windows Explorer, I get this:

Dear God, how emphatic do they have to be? “Location is not available,” it says. My (my!) directory “is not accessible” it says. “Access is denied,” it says. Okay, I get it. Seems like there are a lot of things you can’t do without being an administrator on Windows 7 (the whole point of this post, btw, doesn’t arise in XP, which happily installs my filter .dll files like the obedient little robot it’s supposed to be, no matter who I’m logged in as).

But, Microsoft’s Knowledge Base overstates the situation, imho. You don’t have to “log in” as anything, if you can run Command Prompt as an administrator. Wish they’d just say so, but they don’t. I found the solution when I first needed it by Googling a bit farther, but it still took longer than it should. So, this post is an effort to help the next guy. Just run Command Prompt as an adminstrator and regsvr32 will do your bidding (until some other problem comes along).

Just to be more expansive (and to avoid going back to work on my latest annoying filter bug), I will mention the err.exe program that is part of the v7.1 Windows SDK. From time to time, when I am feeling adventurous, I run one of the .exe files that is in the SDK bin directory. If they’re all documented somewhere, someone please tell me. Until then, it will continue to be a thrilling little moment when I run another one for the first time and find out what it does. err.exe (when run without arguments) tells you it does this:

All values on the command line will be looked up in our internal
tables and presented to you. If available, informational data
associated with the value(s) will also be shown (see below).
All tables are searched by default, but you can restrict the
output to those tables you deem appropriate by adding
"/<tablename>" to the beginning of the commandline

If you’re one of those people who has laboriously compiled a spreadsheet or other centralized list of all those HRESULT error codes, this might be appealing. For 0×80070005, you get this:

COR_E_UNAUTHORIZEDACCESS corerror.h
# Access is denied.
DIERR_OTHERAPPHASPRIO dinput.h
DIERR_READONLY dinput.h
DIERR_HANDLEEXISTS dinput.h
DSERR_ACCESSDENIED dsound.h
ecAccessDenied ec.h
ecPropSecurityViolation ec.h
MAPI_E_NO_ACCESS mapicode.h
STIERR_READONLY stierr.h
STIERR_NOTINITIALIZED stierr.h
E_ACCESSDENIED winerror.h
# General access denied error
# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x5
# for hex 0x5 / decimal 5 ERROR_ACCESS_DENIED winerror.h
# Access is denied.

There it is again, “Access is denied.” Funny, how often the errors you get from Microsoft’s products add up to one form or another of that phrase, but that’s life in the fast lane, I guess. Anyway, that’s my rant on the fact that you can’t run regsvr32 on Windows 7 the way you did on XP, and what it takes (or took me) to figure out how to get it to work. Maybe that will help someone else, somewhere. Drop me a line, if that’s you.

¹If, like me, you are over 50 and have been programming since computers ran on coal, you will remember a time when “8.3″ was an informal standard for file names (as opposed to the unemployment rate in a lot of Virginia since “Bob’s for Jobs” McDonnell got elected governor, but this isn’t a political blog anymore). Of course, those days were over long before DirectShow arrived, so one has to wonder why Microsoft gave a broken keyboard to the person who wrote graphedt.exe. I mean, Microsoft itself calls this thing “GraphEdit” (camel-case and missing “i” included) on their Web site. Yet, that very same site says, without apology or explanation, that, “The name of the GraphEdit application is ‘graphedt.exe’.” Which means that, whenever you Google for it, you have to Google for it twice, as half of us appear to call it GraphEdit most of the time, while the other half of us call it graphedt most of the time. Even if one uses the immensely superior GraphEditPlus,
there is no way out of Googling for GraphEdit/graphedt if you are going to do DirectShow work, as everyone uses it (and, when discussing what they are doing, everyone makes mention of it). You just have to get used to it.