I recently got an email with the following question:
“Can you give me some very helpful hints with this one ? I am struggling with the following error in an asp.net application.
Exception Message: Internal Error : Unable to load DLL ‘RdbNet.dll’: A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A) The RdbNet.dll is an .NET dll from Oracle so I can’t debug into it.
If I use a windows forms application I never have the error. I have already used procmon, filemon and regmon to search for access denied, not found… and so but couldn’t find a reasonable one.”
My note: The actual .net Exception is System.DllNotFoundException
I don’t really have a silver-bullet answer for this one, but I thought I’d discuss how I would go about troubleshooting this if it happened to me or if I got a case on it.
An “initialization routine failed.” problem generally occurs because a) some dll that this dll referenced was not found or b) something in the init method failed.
The problem is that option B could really mean anything, such as the init routine making calls that require permissions that you don’t have, or for example that it interacts with the desktop which is not permitted from a service etc.
The most common issue though is that the component was not properly installed, so that some of its dependencies are not available.
Differences between web forms and win forms (in this context)
The most apparent difference between a web forms and a win forms application is the user context that it runs under. Unless you’re impersonating or the app pool id is changed, the application pool runs under the network service account which has very limited access.
Another big difference is that an asp.net service is not allowed to interact with the desktop.
There are of course a lot of other differences but these are the two that I think may be relevant for this issue.
Where to go next
1. Run filemon + regmon to look for not found or access denied
My first troubleshooting step is exactly what they mention that was done in the email. Running procmon (filemon+regmon) to look for not found or access denied, specifically focusing on the files that RdpNet.dll depends on. A quick search gave me this link to the release notes of the Oracle RDB Provider for .NET including the dependencies for it.
I still believe that there might be something in there, but it is a bit tricky to look at these files if you are not exactly sure what you are expecting to find. A neat trick, since there is a working win forms solution is to run filemon+regmon when it works to see if it accesses some files that it didn’t access in the web forms case.
The other thing that is interesting here is to find out if it was tested in a win forms application on the same machine as the web server. This would tell us if we can exclude the idea of some dependencies missing.
2. Reinstall the component
If the win forms app was not tested on the actual web server I would simply reinstall the component as this is a quick and easy step to make sure things got registered properly.
3. Test with elevated permissions
If the problem reproduces on a development server or a test server you can temporarily create a new application pool running under a user that has high permissions (admin or similar) to see if the problem still reproduces. If it does, then you have a permissions issue and it is back to filemon/regmon again. I wouldn’t recommend running with elevated permissions live of course, but in a test/dev environment it would be an ok step to try.
4. Get a memory dump on the Exception and log stack traces for all first chance exceptions
With debug diag you can set up a crash rule for the w3wp.exe process and configure it to “Log Stack Trace” for unconfigured first chance exceptions, and then use “add exception” to add a specific action for the CLR (.NET) Exception System.DllNotFoundException and ask it to create a full dump when this exception occurs.
For more info on setting up such rules see http://blogs.msdn.com/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx
Once you have the log and the dump, look in the log for exceptions (native or .net) that occurred just before the System.DllNotFoundException as this is probably what later bubbled up to generate this exception.
In the dump you can dump out all recent .net exceptions to see if some exception has occurred recently that might lead up to the exception you are seeing now.
5. Contact the vendor of the component
If you can’t get anything from the above steps I would suggest contacting the vendor of the component. Sometimes (I don’t believe it is the case with this particular component though) the dll you are trying to use is not mean to be used from ASP.NET because it interacts with the desktop, uses System.Drawing or similar.
Perhaps you need to configure something to be able to use it from ASP.NET or they can tell you what permissions are needed etc.
If you ran through step 4 and did get a call stack for an exception occurring in one of their components right before the DllNotFoundException occurred, that is usually very useful.