Microsoft.XMLDOM msxml3.dll error '80070005' Access is denied. (The code worked yesterday, I think installing ASP.NET AJAX 1.0 broke it?) - asp-classic

I have some legacy asp classic code that typically runs fine so I haven't replaced it yet (it is on my long to do list though), it runs on a schedule as part of a larger system, parsing XML files.
Today it is throwing an error...
msxml3.dll error '80070005'
Access is denied.
/inc/inc_parsexml.asp, line 77
Line 77 is:
objXML.Load (Server.MapPath(strFilePath))
which is part of this larger snippit:
Set objXML = Server.CreateObject("Microsoft.XMLDOM")
Set objList = Server.CreateObject("Microsoft.XMLDOM")
objXML.async = False
objXML.Load (Server.MapPath(strFilePath))
If objXML.parseError.errorCode <> 0 Then
'do something here
session("LogMSG") = "XML parse error: " & objXML.parseError.errorCode & " on file " & strFilePath & "<br>" & Session("ErrMSG")
End If
Set objList = objXML.getElementsByTagName("*")
reDim strNodeParentName(objList.length -1)
For intCount = 0 To (objList.length -1)
strNodeParentName(intNodeParentCount) = objList.item(intCount).nodeName
If objList.item(intCount).hasChildNodes Then
buildNodeNameVar()
writeNode()
If objList.item(intCount).firstChild.nodeName = "#text" Then
If intCount <> (objList.length -1) Then
checkParent()
End If
Else
intNodeParentCount = intNodeParentCount +1
End If
Else
buildNodeNameVar()
writeNode()
If intCount <> (objList.length -1) Then
checkParent()
End If
End If
Next
To the best of my knowledge it was running fine yesterday, however I did install ASP.NET AJAX 1.0 ( http://www.microsoft.com/en-us/download/details.aspx?id=883 ) on the server (for a different project in asp.net 2.0) so maybe I stepped on some toes?
I hope it is something simple, please help, thanks!
EDIT: Thanks to John, it turned out to be that the IUSER account did not have access to the file it was trying to read...

"Access is denied" suggests that your website's IUSR account is denied access to msxml3.dll. You need to find this file and check permissions.
Assuming that you're not running a really old version of IIS, you should have the current version of the file - msxml6.dll - for which you would use Server.CreateObject("Msxml2.DomDocument.6.0") You may find that that the correct permissions are already in place for this version and you aren't denied access
Edit
While I got there in the comments, this answer was wrong. I should have read the question more carefully. If the IUSR account really didn't have access to the dll then the script would fall over three lines earlier at Server.CreateObject

I just experienced the same issue. After a lot of searching and trying, it just turned out that I was trying to save a file that was still marked as "read-only".
This solved the issue for me.

Related

classic asp : MSXML3 dll ServerXMLHTTP

I am using below code
Set objXML = Server.CreateObject("MSXML3.ServerXMLHTTP")
objXML.Open "GET", sendstring, false
objXML.Send()
Its giving error on objXML.Send on localhost environment
I dont see any problem in this code but could not able to understand why its giving error.
I have already register successfully dll MSXML3 using regsvr32 from location C:\wINDOWS\SysWOW64\msxml3.dll
Do I have to run proxycfg - d ?
Please advise
Please see attached error screenshot
attaching debug error

Classic ASP migration to Windows 2016 Chilkat Zip Activex issue with temdir

This is as much a note for myself as to help anyone else.
We migrated a Classic ASP application to Window 2016. Everything worked in the end. Then an issue surfaced with some zip & download functionality for which we use a Zip component from Chilkat.
Initially, all looked well - the software component was installed and responded to instantiation, but the zip files did not appear on disk where expected.
What could it be? Modifying the code as:
Set oZip = Server.CreateObject(CHILLKAT_ZIP_OBJECT_NAME)
oZip.UnlockComponent(<the license code>)
oZip.WriteZipAndClose()
Response.Write "<pre>" & Server.HTMLEncode( ozip.LastErrorText) & "</pre>"'
response.end
Produced
ChilkatLog:
WriteZipAndClose:
DllDate: Mar 1 2011
UnlockPrefix: *******
Username: *******
Architecture: Little Endian; 32-bit
Language: ActiveX
tempFile: .\ckz_40NT.tmp
Encryption: 0
PasswordProtected: 0
Failed to open file (2)
filename: .\ckz_40NT.tmp
currentWorkingDirectory: C:\Windows\SysWoW64\inetsrv
osErrorInfo: Access is denied.
Filename: .\ckz_40NT.tmp
Failed to open output Zip file
zipFilename: .\ckz_40NT.tmp
Retrying with a new temp filename
Encryption: 0
PasswordProtected: 0
Failed to open file (2)
filename: .\ckz2_I473.tmp
currentWorkingDirectory: C:\Windows\SysWoW64\inetsrv
osErrorInfo: Access is denied.
Filename: .\ckz2_I473.tmp
Failed to open output Zip file
zipFilename: .\ckz2_I473.tmp
tempFileName: .\ckz2_I473.tmp
Cannot open temporary file
Failed.
What could the prolem be ?
The issue was with chilkat's tempdir setting. On our version of Chilkat Tempdir defaulted to the IIS home folder which is unlikely ever to be happy having random files written to it. Adding a line to set tempdir to something more sensible, as below, cured the issue.
Set oZip = Server.CreateObject(CHILLKAT_ZIP_OBJECT_NAME)
oZip.UnlockComponent(<the license code>)
' added the next line !
oZip.TempDir = Server.MapPath("/some accessible folder path")
oZip.WriteZipAndClose()
Response.Write "<pre>" & Server.HTMLEncode( ozip.LastErrorText) & "</pre>"'
Useful info. I'm a Classic ASP programmer and at some point will need to move from Windows 2012 to Windows 2016. Been putting it off!

MSWC.BrowserType on IIS 8.5 always returns "Unknown" as Platform and "Default" as Browser

We recently moved an old Classic ASP website to a newer Windows Server 2012 running IIS 8.5. After this switch, MSWC.BrowserType can no longer get the browser or platform of a user.
On a test page, I have the following code:
<%# Language=VBScript %>
<%Option Explicit%>
<%
Dim browserdetect
Set browserdetect = Server.CreateObject("MSWC.BrowserType")
if isObject(browserdetect) then
response.write("The object was created!<br>")
else
response.write("The object was not created")
end if
Response.Write("Platform = " & browserdetect.Platform & "<br>")
Response.Write("Browser = " & browserdetect.Browser & "<br>")
%>
This returns:
The object was created!
Platform = unknown
Browser = Default
I do have the latest browscap.ini in c:\Windows\System32\inetsrv on the server. Do I need to do anything else for this to work?
As Kul-Tigin pointed out in the comment above, if the application pool running your app is 32-bit (which it was, in my case) browscap.ini will be searched in C:\Windows\SysWOW64\inetsrv.
I had previously copied the browscap.inito C:\Windows\System32\inetsrv, exactly as I always had done on the old server.

Excel VBA errors only when saving non-XL files, to network, from virtual server

We are using a new box to run our VBA
I’m getting some unexpected errors when saving non-excel files, from Excel, to the network.
In one program it fails on the following
.SaveAs "\\fileserve\department$\x\yyy\xxx\" & RepOperName & FileName & strdate & ".msg", olMSG
Showing a run-time error '-2147287008(80030020)'
In another the following just stops on the line Excel.ActiveSheet.ExportAsFixedFormat... with a alert saying document not saved - these are pdf docs it is attempting to save:
Dim FullPath_pdf As String
FullPath_pdf = "\\fileserve\department$\x\Statistics\Reporting\zzz\yyy\kkk\Daily Summary.pdf"
Excel.ActiveSheet.ExportAsFixedFormat _
Type:=xlTypePDF, _
FileName:=FullPath_pdf, _
Quality:=xlQualityStandard, _
IncludeDocProperties:=True, _
IgnorePrintAreas:=False, _
From:=1, _
To:=2, _
OpenAfterPublish:=False
Is this likely to be down to the configuration of Excel on the server?
Or will it be more in connection with the configuration of the virtual server and its relationship to the network?
Had the same problem.
I found out I can’t save non-xls files directly to a network path from Excel.
So, my work around was:
Export the file locally to any directory
Use ROBOCOPY (since you are using Windows 7) to transfer the file
across the network
That should work.
Another tip is to make Excel delete the old file before creating a new one.
You could use a Macro like this:
Sub DeleteExample()
'You can use this to delete all xml? files in the folder Test
On Error Resume Next
Kill "C:\Users\Neo\*.xml*"
On Error GoTo 0
End Sub

Failed to CoCreate Profiler error - but not using a profiler

We're getting a:
.NET Runtime version 2.0.50727.5448 - Failed to CoCreate profiler
message in the Event Viewer on our webserver, along with an accompanying:
.NET Runtime version 4.0.30319.239 - Loading profiler failed during CoCreateInstance. Profiler CLSID: '{d37a1b78-6dc5-46fc-bc31-f7c4d5a11c9c}'. HRESULT: 0x8007007e. Process ID (decimal): 224. Message ID: [0x2504].
The thing is, we're not trying to use a profiler, there are no profiler's running or installed on the server and the code makes no reference to profilers anywhere...
We've tried removing the registry keys that other's have pointed out are related to these messages but to no avail; it would seem that two of our websites/webapps are firing off the error, one using .Net2 and the other using 4, but I'm not sure where to look.
After much searching I found that someone had previously installed dotTrace, then uninstalled it, however the uninstall wasn't very clean and had left the registry littered with entries, though we'd removed some entries we thought could stop the problem there were more specific to that profiler.
After removing all registry entries related to dottrace and the CSID it presented we no longer have the error appearing in the event viewer.
See this answer for a script to aid in hunting down such entries: https://stackoverflow.com/a/36129656/361842
Removing Environment variable COR_ENABLE_PROFILING (or set it to 0) from User variables (Control panel > System > Advanced system settings > Environment variables) solved my problem (Could not start MongoVUE)
While removing all the references to the profiler's CLSID in the registry can't be a bad thing, you can also choose to just disable profiling by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\COR_ENABLE_PROFILING to 0
To help find where this tool may be used, the below PowerShell code can be used to help detect environment variables and registry entries relating to the profiler:
clear-host
if (-not (get-psdrive HKU)) {
New-PSDrive HKU Registry HKEY_USERS
Set-Location HKU:
}
"COR_ENABLE_PROFILING: $env:COR_ENABLE_PROFILING "
"COR_PROFILER: $env:COR_PROFILER"
$GUID = $env:COR_PROFILER
#(
"HKLM:\Software\Classes\CLSID\$GUID",
"HKLM:\SOFTWARE\Classes\Wow6432Node\CLSID\$GUID",
"HKLM:\SOFTWARE\Wow6432Node\Classes\CLSID\$GUID",
"HKU:\*\Software\Classes\CLSID\$GUID"
) |
get-item |
%{$p = $_.Name;Get-ItemProperty $_.PSPath ''} |
select #{N='Path';E={$p}}, '(default)'
get-itemproperty 'HKLM:\SYSTEM\CurrentControlSet\Services\*\' 'Environment' -ea SilentlyContinue |
%{
$serviceName = $_.PSChildName
$x = new-object PSObject -Property #{ServiceName=$serviceName}
$_ | select -expand Environment |
%{if($_ -match '^(?<Name>[^=]+)(=)?(?<Value>.*)$'){$x | Add-Member -MemberType NoteProperty -Name $matches['Name'] -Value $matches['Value']}}
$x
} |
?{$_.COR_ENABLE_PROFILING -eq 1} |
ft ServiceName, COR_ENABLE_PROFILING, COR_PROFILER, NEWRELIC_INSTALL_PATH -AutoSize
Hope that helps others in future.
Use regedit do a Data search for the CLSID value in the error log
Remove COR_PROFILER and its value
Change Cor_Enable_Profiling=1 to Cor_Enable_Profiling=0
Do not remove the Cor_Enable_Profiling setting for any of the following:
HKEY_LOCAL_MACHINE\SYSTEM\Services\WAS
HKEY_LOCAL_MACHINE\SYSTEM\Services\W3SVC
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IISADMI‌​N
Doing so may cause IIS to fail to start. See this question for more details.
You may also need to remove/disable additional User and System variables. Try disabling first (COR_ENABLE_PROFILING = 0) delete if error persist. Hope that helps. Thank you #Andreas and #Mike-Monkey for the initial guidance.
For us COR_ENABLE_PROFILING was at multiple places
HKEY_LOCAL_MACHINE\SYSTEM\\Services\W3SVC and HKEY_LOCAL_MACHINE\SYSTEM\\Services\WAS
Stackify Profiler Will also do the same thing to you. :(, I am finding it difficult to remove from the registry.
We see this problem from time to time when trying to start Windows Services.
This issue is invariably that the app.config for the executable is corrupt (not valid xml).
Double checking that your app.config is valid xml is a quick easy thing to check before heading of to edit registry settings..
Things did not work even after doing what mentioned in Answer from Agnes. In my case, I had my application pool set to an account and it's password was expired...

Resources