Why can’t I install this DLL via Regsvr32 /i?


A customer asked for help installing a particular DLL. They ran the command regsvr /i SomeDll.dll but got the error "SomeDll.dll was loaded, but the DllInstall entry point was not found. This file can not be registered."

A DLL needs to be specifically written to be used with the regsvr32 command. You can't just grab some random DLL and expect regsvr32 to work. As we saw last week, the regsvr32 program merely loads the specified DLL and calls an entry point established by convention. If the DLL was not written to be used with regsvr32 then the conventional entry point will not be found, and you get an error message.

The /i switch to regsvr32 instructs the program to look for the entry point known as Dll­Install. By convention, the Dll­Install function performs installation and setup of a DLL, but since it's just some function exported by a DLL, it could do anything it wants (or nothing at all).

You can't just grab a random DLL and expect regsvr32 to do anything meaningful with it. The DLL has to be designed to operate with regsvr32.

Handing random DLLs to regsvr32 is like dialing a random telephone number, sending a tone at 1170Hz and getting upset when you don't get a 2125Hz tone in response.

The number one hit for a search on what does regsvr32 do is an old Knowledge Base article which explains what regsvr32 does, and it even contains a sample program which emulates regsvr32 so you can use it to debug your DLL. (The sample program hasn't been updated to support the /i flag, which I leave as an exercise.)

One day, I received a piece of email from another employee whom I had never met nor had ever heard of. It didn't even begin with an introduction; it just jumped right in as if we'd been friends for years. "I'm trying to debug a problem where regsvr32 cannot register my DLL. It gives the error 'The specified procedure could not be found.' I saw a blog entry written by you and am trying to understand what our problem is."

This blog thing has backfired. The reasons I write these articles is to get people to stop asking me questions. (The mechanism for that being to give the answer out in public for everyone to see.) Instead, it turns into "Hi, I found an article you wrote about X, which ipso facto makes you not only the world's foremost authority on X, but also the world's leading support technician on X."

News flash: Posting a blog entry about something on the Internet should not be taken as evidence that the author is an expert on that subject. (One might argue that it in fact is more likely to be the opposite.)

At the time, I wasn't aware of the knowledge base article that explains what regsvr32 does and how to debug it, so I couldn't point to it. I wrote back, "All regsvr32 does is Load­Library, Get­Proc­Address, and then calls the function. You can write your own test that does the same thing. You do not require any expertise from me."

Less than an hour later, I received a reply: "Thanks. I figured it out. There was an older version of the DLL in the path ahead of the one I was trying to register."

And I never did figure out which blog entry I wrote that made them think I was an expert on regsvr32. Maybe the person worked in Microsoft Research and used a prototype of their machine that predicts the future, and used it to predict that I was going to write about regsvr32 two years later.

Comments (26)
  1. Gabe says:

    Of course being the author of a blog post doesn't make you an expert on a subject. Everybody knows that you have to write the Wikipedia entry on a subject to make you an expert!

  2. "There was an old DLL in the path".

    Luke, use full path names!

  3. Anonymous Coward says:

    "SomeDll.dll was loaded, but the DllInstall entry point was not found. This file can not be registered."

    The error message says exactly what the problem is. Why waste a blog post on the subject?

  4. Adam Rosenfield says:

    @Anonymous Coward: Haven't you learned that nobody reads error messages?

  5. Joshua says:

    Time machine is up and running. I've analyzed crash reports where a time machine was required to reach the crash point.

  6. "regsvr /i SomeDll.dll but got the error"

    Hmmm, yes, we can start with the fact that regsvr doesn't even exist on my 64-bit Windows 7, so yes – I'd imagine there would be an error…

  7. Chris Walken says:

    Years ago back in the "DLL not found" days we wrote a debugger that would figure out the missing DLLs and all sorts of COM and registry issues. regsvr was always a mystery to the VB crowd at the time. We wrote a little tool that would actually explain the error codes if possible that were returned from trying to register a DLL. Its called regdrop and it's here http://www.addisonsw.com/revsqu.htm if anyone wants it.

  8. kinokijuf says:

    It’s the number seven hit, not number one.

    [Comes out as #1 for me. -Raymond]
  9. Tanveer Badar says:

    @James

    Because it is actually regsvr32?

  10. Me says:

    Luke, use full path names!

    As Raymond has written several posts about this before, I know that you have to use full path names when calling LoadLibrary from your own program.

    But without checking first, I would have guessed that regsvr32 uses its current directory to convert the given file name argument to a full path before calling LoadLibrary. That's what I except a well behaved command line utility to do. (e.g. "dir explorer.exe" doesn't search the path, either)

    Apparently this is not the case.

  11. Leo Davidson says:

    @Me: Correct, Regsvr32 appears to just call LoadLibrary on the name/path given on the commandline, without any modification.

    If you've set the registry value which bans the current directory from the library path (plugging the DLL-planting hole) then it means you always have to give regsvr32 a full path.

    (Would be nice if you could use ".dllname.dll" as a shorthand to make regsvr32 resolve it to the absolute path, but I guess there's probably something wrong if you are (un)registering DLLs by hand often enough to care that much.)

  12. Mark says:

    I suspect it's actually your blog comment to the first hit for 'The specified procedure could not be found regsvr32' on that same search engine:

     blogs.msdn.com/…/regsvr32-exe-gives-error-quot-the-specified-procedure-could-not-be-found-quot.aspx

    So it's really what you get for venturing out from your blog and roaming among the masses.

  13. Jim O says:

    Maybe they're this guy, who's going to live in London for a while. (Blue plaques are common in London to document why a place has historical significance.)

    http://www.flickr.com/…/5456293852

  14. blog backfire says:

    Hi Raymond, I am looking at buying a large metal bird, perhaps naming it after a celebrity and you have a blog post mentioning a large metal chicken named Beyonce. I need you to give me a detailed breakdown / cost benefit analysis of the various metal bird options, along with suppliers, distributors etc.

    Please note: incorrect subject area, haven't read post, lack of 'please' and use of "I need you", lack of contact details, vague requirements…

  15. RichardDeeming says:

    But surely you *are* the world's foremost authority on X? What you don't know about X isn't worth knowing.

    Y, on the other hand, is a complete mystery to you, and always will be! :o)

  16. Cheong says:

    @blog backfile: Awesome, you almost made it. It'd have been better if the paragraph include a request to send him all the information despite without any email address mentioned, and make it 5+ lines long without breaking lines.

    It makes me remember a post I once saw on a BBS board, where someone attempted to violate every board rules on a single post. The board moderator dutifully followup by another post explaining how long would the poster need to be banned based on these, that's quite a view.

  17. xpclient says:

    Why is it that many DLLs fail to register under Vista/7 using regsvr32 from an elevated admin cmd prompt but those same DLLs registered successfully on XP and earlier? Leads me to believe something is broken in Vista's regsvr32. Doesn't happen with all DLLs though.

  18. Ivan K says:

    Meh. A particular DLL registration function could succeed on XP but fail on Vista/7 if the first thing it tried to do was some interaction with a service that is now isolated in session 0 and then failed out. Probably about a thousand other things too.

  19. Ian says:

    @xpclient – Generally poorly written things behave that way.  

    I've written software in 2000 that still runs just fine on Windows 7 – of course we knew we had to run on NT4 terminal server edition and didn't want to make the stupid cop-out of "Oh you'll also need to make all of your staff administrators".  The rules aren't difficult.

    Could you provide some examples of such DLLs?  Are they video codecs, explorer extensions?

  20. xpclient says:

    @Ian, some of them are shell extensions, some of them are DirectShow filters, some of them used to be called by Rundll32 after registering etc. I have come across many such unregister-able files under Vista.

    [Looks like you didn't learn the lesson from today's topic: DLLs support Regsvr32 only if they are documented as supporting Regsrv32. I suspect the ones you're having "problems" with were never documented as supporting Regsrv32, so you shouldn't have been relying on it in the first place. -Raymond]
  21. xpclient says:

    Raymond: "Looks like you didn't learn the lesson from today's topic"

    Looks like you are blind. I have been using these DLLs under XP/2000 with no problems but some of them register properly under Vista/7.

    [The question is whether the DLLs are documented as supporting regsvr32. Many Windows DLLs dropped Regsvr32 support because Windows Setup stopped using regsvr32 to install them. They were never documented as supporting Regsvr32, so this was a valid change. -Raymond]
  22. xpclient says:

    I meant "some of them *DO NOT* register properly under Vista/7."

  23. Dave Bacher says:

    @xpclient:

    Originally, Windows didn't support this mechanism for registering DLLs at all.  

    Now, I don't work for Microsoft, and this is based on my personal experience.  However, as a developer who occasionally has written DLL files, including COM, I have occasionally implemented self-registering DLLs.  However, I will never — never — implement another one.  If a registry entry is corrupt, there are a variety of reasons why it could be corrupt, but none of them involve Windows just randomly changing the entry because it feels like it.  Some process, it changed that entry to point at the wrong thing.

    Now when you change that entry back (using RegSvr), you eliminate any ability to diagnose the problem.

    For Windows System DLLs, you can usually fix them using System File Check (sfc /scannow).  For third-party DLLs, you can usually run the same installer that copied them onto the system in the first place.

    Now I want to ask you something though:

    "Looks like you are blind. I have been using these DLLs under XP/2000 with no problems but some of them register properly under Vista/7."

    Ok so I'll bite — why are you running RegSvr32 on, apparently from your message, Microsoft provided DLLs in the first place?  If you're not having any problems, then you shouldn't have to re-register them.  If you're upgrading the files, the correct route would be Microsoft's MSM — which would register the files appropriately on its own.  If you're downgrading, you'd want to uninstall then install the down level MSM.  If you're just coping the files, or running RegSvr32 on random files to mask some problem, the MSM for DirectShow — for example — does a lot more than simply registering a couple of the DLLs it copied, and if you don't run its installer, you can cause problems in a week, month, year when some other program runs and doesn't find the entries the MSM writes, and therefore installs some other random version of the components.

    If you write a MSI file (WiX, 10 minutes — for vast majority of installs), then services like System Management Server or LogMeIn One-To-Many can easily install it on multiple computers.  The people installing it don't have to understand batch files, or write one — they just drag the MSI on, and say "deploy this to that group."

    For testing in Visual Studio, on your own code, there's a value in running it — but you shouldn't be running it against Microsoft's DLLs in that scenario.

    What scenario do you have where you're having to register Microsoft's already installed files in the first place?

  24. 640k says:

    >> It’s the number seven hit, not number one.

    > [Comes out as #1 for me. -Raymond]

    Bing favours ms own "facts".

    [Comes out as #1 on Google, and Excite and Hotbot, too. On the other hand, Wolfram Alpha doesn't know what to make of it. -Raymond]
  25. 640k says:

    This blog is #6 btw, thus more authoritative :)

  26. Paramanand says:

    It looks like these kinds of issues arise mostly because they fall in the trap of thinking that "regsvr32" is a tool used to register DLLs (thanks to the name regsvr32). Anyone who has ever tried writing even a test COM DLL will understand that regsvr32 is just a way to loading the COM DLL and invoking its DllRegisterServer function. In fact like in case of COM, if you can just add the registry entries manually for the DLL, there is no need to use regsvr32. Also in general the DllRegisterServer function is not specifically supposed to create some registry entries, it might do anything which the author of DLL wishes to achieve. The confusion arises probably because people who use regsvr32 may not be specifically used to COM programming.

Comments are closed.