Bekijk Volledige Versie : Server.CreateObject Failed
Hallo,
Een 'klant' heeft een website in klassiek ASP. Deze werkt lekker, totdat hij een FileSystemObject aanroept. Deze melding krijgt-ie:
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/directory.asp, line 3
800401f3
Directory.asp bevat deze code:
<%
Dim objFSO, strPath, objFolder, Folder
Set objFSO = Server.CreateObject ("Scripting.FileSystemObject")
strPath = Server.MapPath("../")
Set objFolder = objFSO.GetFolder(strPath)
response.write strPath & "<br />"
For Each Folder in objFolder.SubFolders
response.write Folder.Name & ": " & Folder.Size/(1024*1024) & " MB<br />"
Next
%>
De server draait op IIS6/W2K3. Via Google ben ik bij deze tip gekomen:
regsvr32 scrrun.dll
Dll is geregistreerd, IIS gerestart maar geen soelaas. Andere ASP pages binnen die site doen het wel.
Wat kan dit zijn?
martysmarty
07/02/07, 20:35
Om welk component gaat het?
Ik ben de betreffende 'klant' en heb zo'n 8 jaar ervaring met IIS e.d., maar kwam hier zelf dus ook niet uit.
Beide configuraties (oud & nieuw) zijn Windows 2003 Server machines.
Oude site draaide bij een andere provider, nu overgezet naar de server die Glenn beheert.
DLL is dus geregistreerd, dus het Scripting.FileSystemObject zou gewoon aangemaakt moeten kunnen worden.
Hoe kunnen we achterhalen waarom IIS dit deze class niet kan instantieren en hoe dit op te lossen
martysmarty
07/02/07, 21:21
Zou het kunnen dat het een nieuwe versie van het component is? En dat FileSystemObject daar een andere benaming heeft of iets dergelijks?
Krijg je dezelfde error ook als je alleen maar de server.createobject doet, zonder andere code?
Draait IIS onder de standaard gebruiker of een andere gebruiker? Deze melding krijg je vaak wanneer de rechten niet goed staan op het component.
Zou het kunnen dat het een nieuwe versie van het component is? En dat FileSystemObject daar een andere benaming heeft of iets dergelijks?
Krijg je dezelfde error ook als je alleen maar de server.createobject doet, zonder andere code?
Ja, helaas wel. Ik heb even een aparte pagina gemaakt met 1 regel:
Set objFSO = Server.CreateObject("Scripting.FileSystemObject")
Deze geeft dezelfde melding....
Misschien iets met de rechten op die DLL ?
Misschien iets met de rechten op die DLL ?
De desbetreffende DLL heeft geen specifieke rechten voor IUSR, dat heb ik nu wél gegeven. Het lijkt me echter vreemd dat dit zou moeten, aangezien overige ASP dll's ook geen specifieke IUSR rechten hebben terwijl die wel gewoon werken.
Overigens heb ik nog geen reboot geprobeerd na al die wijzigingen, dat zal ik vanavond doen. Uit ervaring weet ik dat dat nog wel eens wilt helpen.
Nog een paar sites waar ik meer op vond met tips (ook voor de andere lezers met hetzelfde probleem):
ttp://classicasp.aspfaq.com/components/why-do-i-get-800401f3/800a01ad-errors.html
en
ttp://classicasp.aspfaq.com/components/why-do-i-get-server-createobject-access-error.html
Mogelijk dat het script wel werkt als ik niet Server.CreateObject doe, maar CreateObject (zonder Server.) Kan het nu echter niet testen, omdat ik aan het werk ben.
Toegang tot FSO wordt dichtgezet met IIS Lockdown.
http://www.microsoft.com/technet/security/tools/locktool.mspx
Mogelijk dat het script wel werkt als ik niet Server.CreateObject doe, maar CreateObject (zonder Server.) Kan het nu echter niet testen, omdat ik aan het werk ben.
Inmiddels bovenstaande scenario ook getest, maar helaas, het enige dat verandert, is de foutmelding:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'Scripting.FileSystemObject'
Toegang tot FSO wordt dichtgezet met IIS Lockdown.
http://www.microsoft.com/technet/security/tools/locktool.mspx
Reboot wil niet helpen. Locktool is alleen voor IIS5.0 en 4.0. Het betreft hier IIS6.
Nog twee mogelijkheden gevonden, die misschien kunnen helpen bij het opsporen van een oplossing hiervoor. Er is een tooltje genaamd DCOMCNFG.EXE , waarmee je (als ik het goed begreep) je componenten kunt configureren en autoriseren. Staan nergens in je control-panel, maar bestaat wel in de system32 directory.
Andere mogelijke oorzaak is verschil in filesysteem (NTFS vs FAT). Hierbij moet de IIS-user dus ook rechten krijgen op je system32 directory, ander mag het nog de DLL niet initieren (alleen lezen, zou waarschijnlijk voldoende moeten zijn).
Bron (in het frans!):
aspfr.com/infomsg_FILESYSTEMOBJECT-FSO-PROBLEME-SECURITE_281742.aspx
Heb IUSR toegevoegd aan de administrators-groep en ik krijg geen errors meer, maar keurig een dir output. Zit 'm dus in de security. Ben er echter nog niet achter wat er precies voor rechten nodig zijn. Ik zou wel heel system32 readable kunnen maken, maar dat lijkt mij niet echt safe.
Beide schijven hebben NTFS filesystem.
't Is 1 dll in de system32 folder, ik ben het tegen gekomen op google. ;)
't Is 1 dll in de system32 folder, ik ben het tegen gekomen op google. ;)
Klopt, bedoel jij scrun.dll? Die heb ik namelijk al full rights gegeven voor IUSR.
Heb IUSR toegevoegd aan de administrators-groep en ik krijg geen errors meer.
Die zou ik daar asap weer weghalen. IUSR als admin is zeer gevaarlijk. Als je gewoon User-group leesrechten tot system32 geeft ben je klaar. Als je precieze rechten wilt weten kan ik ze wel even opzoeken voor je.
Die zou ik daar asap weer weghalen. IUSR als admin is zeer gevaarlijk. Als je gewoon User-group leesrechten tot system32 geeft ben je klaar. Als je precieze rechten wilt weten kan ik ze wel even opzoeken voor je.
Dat heb ik gelijk weggehaald ja, ik ken de gevaren ;) Als je de rechten zou willen opzoeken: graag!