Problems registering E2kdsn.dll during upgrade to Exchange 2003 SP1
I've replied to this question a handful of times in the newsgroups, so perhaps there's a need to post the solution here as well. This is evidently happening to a number of people out there.
When you upgrade your Exchange 2003 server to Exchange 2003 SP1, lots of the Exchange binaries get upgraded to newer versions. Some of these binaries need to be registered with the OS. A common one I've seen have problems registering during the SP1 install is the E2KDSN.DLL file. You'll see something like this in your Exchange Server Setup Progress.Log file:
[21:38:17] The command
regsvr32 /s e2kdsn.dll
failed, returning error code 5 (Access is denied.). -- ID:31136 -- ScCreateProcess (f:\tisp1\admin\src\libs\exsetup\hiddenw1.cxx:1821)
Error code 0XC103798A (31114): An internal component has failed.
The error code listed could be just about anything. I've seen error code 5, error code 3, etc.
There's a couple common causes I've seen for this problem:
- File-level Antivirus scanning is blocking access to either the file or its dependencies
- Open-file backup manager is blocking access to either the file or its dependencies
- The file and its dependencies are not matching versions
Whoa! What does that last one mean?!
Well, very few of the Exchange DLLs stand alone; they almost always have hook-ins to other Exchange DLLs, and these other DLLs are known as dependencies of DLL we're trying to register. For instance, for the Exchange 2003 SP1 version of E2KDSN.DLL, we have dependencies on these Exchange DLLs: EPOXY.DLL, PTTRACE.DLL, EXCHMEM.DLL, TRANMSG.DLL, GWART.DLL, and DSACCESS.DLL. We potentially may need to be able to find these DLLs (and the correct, updated versions if they're updated for SP1!) and call into them during the DLL registration process.
This means that if there are old, outdated versions of these particular DLLs lying around on your server, they might get in the way of the updated versions during the registration. The most common example of this is an outdated copy of EXCHMEM.DLL sitting in the %SystemRoot%\System32 directory. When we try to register the E2KDSN.DLL, we hook into the WRONG version of EXCHMEM.DLL since it's in the System32 directory. Then we try to register the E2KDSN.DLL file and fail. Simple solution -- the EXCHMEM.DLL file doesn't belong in System32. Remove the old one and then the newer/updated version in your ExchSrvr\Bin directory will be found instead, as it should be!
For the particularly curious reader, that leads to the question: How did you get the list of dependencies for E2KDSN.DLL? Well, it's easier than you might think if you have Visual Studio installed. There's a tool called the “Dependency Walker“ (Depends.exe) that ships with Visual Studio. Just open up a DLL in this tool and it will give you a list of the dependency DLLs! For more information on Dependency Walker and alternate ways to get it, see Steve P. Miller's site. In particular, see the FAQ where he points out a more involved method for troubleshooting REGSVR32 failures if the list of DLL dependencies initially listed in the utility are not useful.
Update Sept 5, 2004: blog reader Martial reports (using the Dependency Walker method) that a 3rd-party DLL "rahook.dll" can also conflict with the success of the E2KDSN.DLL registration. This dll is associated with the "Remotely Anywhere" software product.
Update Feb 2, 2008: blog reader James reports (using the Dependency Walker method) that there's a version of "atl.dll" dropped by Samsung Yepp MP3 player software which can also conflict with the success of the E2KDSN.DLL registration.