# Unable to load DLL 'xmogrt': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

We are deploying a DotNet website managed using SDL Tridion 2013. We need to deploy the website on two web servers (web1 & web2) load balanced using a NLB. The CMS is set to publish files through the Content Deployer which is running on web1. This deployer is configured to store all published contents on a network share which is accessible to both web servers. The IIS website on both servers is set to use the network share as the home directory (using UNC path). The Application Pool identity has been set to a user that has full access to the network share.

Publishing contents from the CMS is working fine and the contents are being stored on the network share. However when we try to access the website we are getting the below error. So far we have verified the following:

The web servers are running a 64 bit OS and the xmogrt.dll being used is also for the same Access privileges at various levels Restarted IIS on both servers and also restarted the server boxes

@Dominic: Could you please elaborate on how you think this setup is not "standard configuration". For a load balanced setup you would have to store the published website contents on to a network share accessible from all your web servers, unless you want to setup multiple Publishing Targets (associated with the same Target Type) which if I am not mistaken is not recommended by SDL.

Line 10: <script runat="server">
Line 11: string linkAsString = "";

[DllNotFoundException: Unable to load DLL 'xmogrt': The specified module could not be found. (Exception from HRESULT: 0x8007007E)]
Codemesh.JuggerNET.NativeInterface.GetJvmLoader(Int32 ctorVersion, String configFile, String vers, String conf, String reserved, Boolean bEnvOverrides, Boolean bDefaultJvm, Int32 traceFacility, Int32 traceLevel, Int32& error) +0
Codemesh.JuggerNET.JavaClass.init() +92
Codemesh.JuggerNET.JavaClass.get_JObject() +34
Codemesh.JuggerNET.JavaMethod.init() +838
Codemesh.JuggerNET.JavaMethod.CallObject(JavaProxy jpo, JavaMethodArguments args) +494
ASP.default_aspx..ctor() in \\172.20.11.67\websites\xxx\default.aspx:12
System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp) +174
System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +42
System.Web.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +516
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

• To answer your question, Abdul: using UNC shares like that is a bit off the beaten path. – Dominic Cronin Feb 27 '14 at 15:22

The error message explicitly states The specified module could not be found.

xmogrt.dll is not a .NET assembly. It's a "good old-fashioned" Windows DLL. The rules for locating this kind of dll are fully described at http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

That page also links to information about how you might help Windows to find the dll with techniques such as using a Manifest to explicitly specify a location. Putting the dll in the system directory might also work, but then you'd need to watch out for other resources that are loaded relative to the dll location.

Frankly - trying to solve it this way might be more trouble than just setting everything up with a more standard configuration. You would also need to check with support to ensure your chosen infrastructure is supported. (I fear it would not be.)

I would suggest that you give more details here about exactly what you mean by a 'shared location', and why you have chosen that design. Then we will be able to help with answers that address the fundamentals, rather than simply solving problems with loading a dll.

Did you check the presence of xmogrt dll of correct bit-format and at the right place? You may want to refer this question:

Check the dll in exception is compatible with your machine (32-bit/64-bit) and is available

• yes everything is in correct format when i put my application file on local it works fine but when i put files on shared server it gives this error – Abdul Qadir Dec 26 '13 at 8:38
• Can you please specify what do you mean (what all it includes) in your application file? – Pankaj Gaur Dec 26 '13 at 8:43
• i mean complete website folder which contains all required dll for tridion – Abdul Qadir Dec 26 '13 at 8:45
• Also, did you checked whether your local machine and server both are of same bit (32 bit or 64 bit). It may be the case on your local, the machine is 32 bit and you have used the 32 bit version of xmogrt dll but on server it is 64 bit and same 32 bit xmogrt dll goes as part of build or vice versa. – Pankaj Gaur Dec 26 '13 at 8:45
• Can you share the screen shot of properties of xmogrt dll that your application is using? also let me know whether the server is 32 bit or 64 bit – Pankaj Gaur Dec 26 '13 at 8:47

As @Dominic mentions in his answer, xmogrt is an standard windows library and not a .NET assembly so you will be getting issues while executing it from a network shared location. It is not like a .NET assembly where you can configure CAS (Code Access Security) allowing your DLL to be executed from a Network location.

I understand that having it in a network share you won't need to synchronize your published content. Try having a .NET Web Site configured in both servers (Bin folder, Web.config, Global.asax) and then include a Virtual Folder in both Web Sites, then you can point that Virtual Folder to the network shared folder where you are publishing your content.

I hope this helps.

We r able to resolve this problem the solution was pretty simple remove the xmogrt.dll from bin and put into windows/system32 folder(if website is 64 bit if it is 32 bit put in to windows/SysWOW64) on each webserver and also need to install microsoft visual c++ 2010 redistributable on both server.we r using dot net framwork 4.0 for the website.

• If you now have a solution, you should accept an answer. In this case, the various valid locations for a windows dll were covered by my answer. – Dominic Cronin Sep 11 '14 at 7:47
• copying xmogrt in system 32 solved my problem as well. We were using azure file storage as shared location and getting the same location.thanks – rdhaundiyal Jan 28 '16 at 15:03