The WCF web service I worked on failed with the following error message when I tried to launch it from IIS:
The specified module could not be found. (Exception from HRESULT: 0x8007007E).
From the previous encounter, I was pretty sure that it must have something to do with WrapperUtilAPI.dll. The library written in managed C++ serves as the bridge between the managed and unmanaged code.
Since the web service is in the managed code, I first tried the Fusion log viewer to see whether there had been any assembly binding error. Except that the web service module itself did not show in the log viewer, there had been no assembly binding error for all other dependent modules, such as WrapperUtilAPI.dll:
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
It seemed that the culprit was from the unmanaged code. Then I used Process Monitor to record the activities from aspnet_wp.exe when I tried to launch the web service through it.
For a DLL to load successfully, the following operation sequence should take place,
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
CreateFile C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
CloseFile C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
Load Image C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
QueryOpen will try to locate a module using the DLL search path.
While looking through the log from Process Monitor, I noticed the following lines,
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Support Tools\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\zlib1.dll NAME NOT FOUND
QueryOpen C:\MinGW\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\QuickTime\QTSystem\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\windowspowershell\v1.0\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\zlib1.dll NAME NOT FOUND
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\WrapperUtilAPI.DLL SUCCESS
It seemed that the application tried to load zlib1.dll. However, the module could not be found in the DLL search path. Therefore, instead of loading zlib1.dll, the application closed WrapperUtilAPI.dll, which had been loaded early.
Since I was pretty sure that zlib1.dll had to be loaded so that WrapperUtilAPI.dll could be loaded successfully, and its location was not in the PATH environment variable and the DLL search path. So at the point, the root cause seemed to be the failure to load zlib1.dll. Then I copied it to the location on the DLL search path, the web service could be launched from IIS.
The specified module could not be found. (Exception from HRESULT: 0x8007007E).
From the previous encounter, I was pretty sure that it must have something to do with WrapperUtilAPI.dll. The library written in managed C++ serves as the bridge between the managed and unmanaged code.
Since the web service is in the managed code, I first tried the Fusion log viewer to see whether there had been any assembly binding error. Except that the web service module itself did not show in the log viewer, there had been no assembly binding error for all other dependent modules, such as WrapperUtilAPI.dll:
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
It seemed that the culprit was from the unmanaged code. Then I used Process Monitor to record the activities from aspnet_wp.exe when I tried to launch the web service through it.
For a DLL to load successfully, the following operation sequence should take place,
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\ftpaccess.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
CreateFile C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
CloseFile C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
Load Image C:\Program Files\Ipswitch\Common\ftpaccess.dll SUCCESS
QueryOpen will try to locate a module using the DLL search path.
While looking through the log from Process Monitor, I noticed the following lines,
QueryOpen C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\Perl\site\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\Perl\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\wbem\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Microsoft SQL Server\90\Tools\Binn\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Support Tools\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\Ipswitch\Common\zlib1.dll NAME NOT FOUND
QueryOpen C:\MinGW\bin\zlib1.dll NAME NOT FOUND
QueryOpen C:\Program Files\QuickTime\QTSystem\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\system32\windowspowershell\v1.0\zlib1.dll NAME NOT FOUND
QueryOpen C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\zlib1.dll NAME NOT FOUND
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e SUCCESS
CloseFile C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\wsftp.webservicehost\89b3cfc4\ab5fbeff\assembly\dl3\f9b47a83\007d695c_3011ca01\WrapperUtilAPI.DLL SUCCESS
It seemed that the application tried to load zlib1.dll. However, the module could not be found in the DLL search path. Therefore, instead of loading zlib1.dll, the application closed WrapperUtilAPI.dll, which had been loaded early.
Since I was pretty sure that zlib1.dll had to be loaded so that WrapperUtilAPI.dll could be loaded successfully, and its location was not in the PATH environment variable and the DLL search path. So at the point, the root cause seemed to be the failure to load zlib1.dll. Then I copied it to the location on the DLL search path, the web service could be launched from IIS.
0 comments:
Post a Comment