How do I resolve this issue with requests to
msmdpump.dll for connections to SQL Server Analysis Services? I am receiving a 500 Error from the IsapiModule.
On a Windows Server 2012 R2 machine, with IIS 8.5, I have setup the OLAP data pump (
msmdpump.dll), using the following instructions: https://msdn.microsoft.com/en-us/library/gg492140.aspx#bkmk_copy
As far as I can tell (and I've double and triple checked), everything is configured as laid out in the MSDN article. Also, compared to another server where I have this setup (on a different network), it is essentially the same.
When I request
http://localhost/OLAP/msmdpump.dll in a browser on that machine, I receive a 500 Internal Server Error. The error indicates that it is trying to use the
OLAP handler that I created. This is not the same error that I would normally expect when doing a
GET request to msmdpump.dll. The normal error for a straight
GET, when everything is working correctly, is sent back in a SOAP envelope. In my case, the request does not appear to ever be processed by
(see below for full screenshot)
Module IsapiModule Notification ExecuteRequestHandler Handler OLAP Error Code 0x8007007e Requested URL http://localhost:80/OLAP/msmdpump.dll Physical Path C:\inetpub\wwwroot\OLAP\msmdpump.dll Logon Method Anonymous Logon User Anonymous
I also receive an error when trying to connect to the data pump via SQL Server Management Studio:
One appreciable difference between the machine I'm setting up, and the server where the data pump already works, is that there are a few more roles setup on the new server.
The problem server includes:
While the other machine (where the data pump works), does not include those roles. Would the presence of ASP.NET 4.5 or .NET Extensibility 4.5 cause an issue with IIS serving requests for this IsapiModule?
In my case installing KB3138367 (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) resolved the issue.
There are a few debugging steps that can be useful.
Configure IIS tracing
However, you can ignore the parts where it tells you to delete your existing content - they're going a little overboard there to ensure you get the same results in the tutorial. Just add the failed request tracing to your existing site, catching "500" status codes.
In my case, that led me to the result:
ModuleName IsapiModule Notification EXECUTE_REQUEST_HANDLER HttpStatus 500 HttpReason Internal Server Error HttpSubStatus 0 ErrorCode The specified module could not be found. (0x8007007e)
I confirmed that my handler mappings had the correct path to msmdpump.dll, but still got the error. So time for the next debugging step:
Use Sysinternal Process Monitor to check w3wp.exe Process monitor is a free tool from Microsoft: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Use Process Monitor to log file system access (filter on the "w3wp.exe" process to avoid being overwhelmed)
NAME NOT FOUND and
PROCESS NOT FOUND results. There will be a number of these as the system attempts to e.g. locate various dlls, so it is normal to see some
NOT FOUND results followed by
SUCCESS results for the same filename. You are looking for
NOT FOUND results that do not have any corresponding
In my case, this highlighted two dlls:
These turn out to be part of the “Microsoft Visual C++ 2013 Redistributable” package (https://superuser.com/questions/1163409/msvcp120-dll-and-msvcr120-dll-are-missing).
However, "Add/Remove Programs" showed that the package was already installed. Running "repair" on the package did not resolve the issue.
Locating the dlls
In my case, the OLAP pump is installed an a web server separate from Analysis Services.
Running these powershell commands:
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcr120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcp120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
yielded some interesting results. On the web server, the dlls only showed in
However, on the server where Analysis Services was installed, the dlls were present in both
C:\Windows\SysWOW64 (as well as a few other sql server paths)
(as an aside, SysWOW64 contains 32 bit dlls, and System32 may contain 64 bit dlls. So simply copying from SysWOW64 to System32 is likely to cause you problems. See https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows)
I could see from the Process Monitor logs on the web server that one of the search paths was
C:\Windows\System32. A little more searching led to KB3138367 (Installing both Visual Studio 2013 Redistributable packages (x86 & x64) at the same time)
The actual KB text (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) describes the issue:
When you install an updated redistributable package, binaries for non-target architectures are removed. For example, after you install an update for an x86-based application, the x64 Visual C++ 2013 runtime libraries are missing. This fix makes sure that both versions of the Visual C++ redistributable are visible when you add or remove programs after installation of the update.
User contributions licensed under CC BY-SA 3.0