I'm reading some registries in ASP Classic to get some values I need and saving them as application level variables. In the global.asa file I have the code:
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Application_OnStart
Application("test") = "testing..."
Dim WSHShell, regLink
Set WSHShell = CreateObject("WScript.Shell")
regLink = "HKEY_LOCAL_MACHINE\SOFTWARE\Odyssey\"
Application("test2") = WSHShell.RegRead(regLink & "value")
End Sub
</SCRIPT>
In my test.asp file, I simply output the "test" and "test2" variables. However, on running test.asp, I get the error message:
WshShell.RegRead error '80070002'
Invalid root in registry key
I have checked and double checked that the key indeed exists, and this code worked on our old server, so I think it is a configuration issue in IIS. I'll be damned if I can find it though. ASP Classic is installed and enabled, and I'm using IIS 7.5 on Windows Server 2008 R2 x64. Hopefully someone has an idea of what the problem is.
EDIT: I downloaded Process Monitor to look at the registry access. After some searching. I found that it is actually looking for the key in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Odyssey\value". I gather this has to do with the server being 64x. I don't want to move the keys to that location, as they will likely never be found again, especially when the code points to a different directory.
Is there a way to stop this redirection or change the structure so this can work?
Thanks in advance for your help.
Doug
As mentioned in the edit to my question, the problem appears to be that the URL was being redirected because it was a x64 system. I ended up moving the registries I was trying to access to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Odyssey. I then modified the code slightly to look for the keys in that location specifically.
regLink = "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Odyssey\"
Since I specified the Wow6432Node myself, the system won't add another one in. I would've rather kept the keys in their previous location, but at least the code points to where they are. As it was previously, someone looking at the code would never have guessed to look in the Wow6432Node directory. The important part is that the keys will not be lost to the depths of the Windows registry system.
Related
I don't know ASP, I've just started working for a large corporation and had task with an asp-classic web app dumped in my lap and it doesn't work. No one knows anything about it and apparently I am not allowed to write to IIS log files. So far it would seem that the program is failing because as far as I can tell, the POSTed HTTP parameters, which I can see in IE developer console, being sent in never make it to the server and can not be found in its Request.Form. Does anyone know what to make of that and how I might be able to print out the Response.QueryString where I might have access to it?
Clarifications:
I can see the log files but I can not add my own debugging lines as I am used to with PHP and Apache on Linux. I'm a fish out of water.
Proof the program is failing is that there is a program called ASPXTOASP.ASP which I think turns .Net request parameters into classic parameters is breaking. It gets an index out of bounds exception and I think it's because it is being passed an empty query string. When I tried to write the query string somewhere it never showed up. Where might I be able to write this query string where I can view it?
I am not certain I know enough about all of the components of the web app to organize it into a working version on my desktop for debugging.
I've just used Response.Write and Response.End to write the Request.QueryString to the screen. It's empty. Based on this and the fact that the program immediately preceding the one that breaks is called login.aspx and consists of setting some EVs haing to do with AD authentication I think my issue must be an authentication configuration issue. We are using Active Directory for authentication. Could anyone tell me about any specific settings in IIS that I ask the admins/senior dev to poke at which might fix such an issue?
A couple of ideas to help you debug:
1) If you're debugging this on the live site, you could output all of the Request.Form values into an HTML comment so that your users aren't affected.
<!-- <%
dim key
for each key in Request.Form
Response.Write key & "=" & Request.Form(key) & vbCrLf
next
%> -->
2) If you can debug the web app on your computer using Visual Studio, see this answer for how to debug ASP.
Based on the feedback I've received, the best solution to troubleshoot the application was to try to print the query string to the browser and then stop the program. To do this, I wrote something like this:
Response.Write("Query String: " & Request.QueryString)
Response.End
Ultimately this led me to discover that my parameters had disappeared. The query string is empty. I supposed I'll now need to read Questions about disappearing HTTP parameters.
We have created one .Net Assembly and made it accessible as COM object.When we are trying to expose any method of this object in ASP page we get an error "80131509". We are not getting any error when we are instantiating the Object. i.e. Server.CreateObject is passing through.
This is working fine in our development environment but we are getting this error in UAT environment. Development and UAT are almost same except UAT is more secure. I have tried all possible ways but no luck. I am working on this issue for past 4 days and any help will be appreciated.
I am suspecting there may be some permission issue with IIS 7 on exposing that dll. But not sure what it can be? We have given full rights to IUSR too.
Code :
set obj = Server.CreateObject("DataAccess")
dim rs
set rs=obj.GetLocations("All") <--- **Here i am getting an error.**
We have a few com dll's at my work and we often run into problems where we register the dll with regasm and the dll does not work. It works in other live environments but for some reason it just will not work in this one instance. Com dlls are fickle. Sometimes we will register it, unregister it, re-register it, and reboot. Sometimes they mysteriously start working other times not.
There are a couple more things that can go wrong.
Make sure that the correct permissions are set on the folders the dll lives in and on the dll itself. Also make sure that any dependent dlls are present and also have the correct permission. Ensure that everything the dll needs access to also has the correct permissions.
If that fails open regedit. Search for the guid associated with the com object. Sometimes you will discover that the paths the registry have are all mixed up. Clean out any references to the com object, reboot, and re-register it.
I have also seen an exception being thrown in the constructor causing issues. When the com object starts up it blows up. In one of our objects added a method to send an email when an exception occurs.
In one case we had an old com object that was no longer compatible with the version of windows we were running. If you have upgraded the server it is on that could be the problem. In our case we wrote our own component to replace the broken old one.
Also make sure that if the com object is strongly typed that you use the "regasm /tlb /codebase fickle_com_object.dll"
In short there are several things that cause com object to not work:
Multiple paths in the registry
Wrong security permissions on folders
Crashing when being created
Perhaps one of these things will solve your issue. I know how difficult it can be sometimes. Good luck!
I've just reinstalled a server, it is a new machine, same OS verion (Win2008) and same IIS version (7.0). The app was working perfectly (and then the machine blew up).
I'm getting this error when I try to access a file outside the webroot:
ADODB.Stream error '800a0bba' File could not be opened
I can access it fine using FileSystemObject, but cannot open it with ADODB.Stream.
Also, I can create a PDF using abcPDF, but I cannot create one again with the same name and overwrite it (this used to work). This works fine inside the website folder structure but not outside.
Also, I cannot attach a file using JMail any more. This applies to files BOTH inside and outside the webroot. So that is weird.
I've assigned Full Control to Everyone on the whole drive to isolate whether it is a permissions problem and it made no difference.
Any ideas anyone?
UPDATE: The problem with attaching files inside the site does not appear to be happening any more, since I mucked round with several things. I'm not sure what did it unfortunately. I got nowhere on this and lost hours over it, so I ended up move all the files inside the webroot and now everything works. This is not ideal and I would still like to get to the bottom of it, but the workaround is acceptable.
Updated question as I accidentally wrote Win2003 instead of 2008.
I think you should check the from your database in the first place how you save the PDF file in question. That is where you saved the file in question into the database from the same machine or from a remote machine. Usually when you save from the same developer machine and you are accessing there will be no error but when the file was saved from a machine other than the developer machine, then you will have such error.
For example:
'1. dbSignatureImage = New ADODB.Stream
'2. dbSignatureImage.Type = ADODB.StreamTypeEnum.adTypeBinary
'3. dbSignatureImage.Open()
'4. dbSignatureImage.
LoadFromFile(dbRecordSet.Fields("client_signature_filename").Value)
From the above code, I was trying to display two different images from the database (one at a time) and among the two images I saved one directly from the developer machine and the other image was saved from a different PC over my network. Whenever I try displaying the second image which was saved from a network PC, then I have the error of file could not be opened. Now what I did was commenting the 4th line and the error seized but then the image was not displaying so I tried displaying the image itself directly from the BLOB field using IO.MemoryStream with the following codes and it is working fine for both the developer machine and any PC over the network.
Dim PassportImageArray() As Byte = CType(dbRecordSet.Fields("client_passport_image").Value, Byte())
Dim SignatureImageArray() As Byte = CType(dbRecordSet.Fields("client_signature_image").Value, Byte())
Dim PassportImageMemoryStream As New MemoryStream(PassportImageArray)
Dim SignatureImageMemoryStream As New MemoryStream(SignatureImageArray)
With picSearchPhotograph
.Image = Image.FromStream(PassportImageMemoryStream)
.SizeMode = PictureBoxSizeMode.StretchImage
.BorderStyle = BorderStyle.None
End With
I think you can go round your problem with this my small idea. I hope it will you some how.
Kasapa-Sunyani
You probably need to take a closer look at the security permissions on the folders outside of your applications home folder. Also take a look at the what user identity is actually used to run your code, for example do you have windows integrated security turned on? If not, is that true of the previous server?
It might help if we could know for sure whether this really is an IIS7 question in which case your server is 2008 not 2003. You might also find that this sort of thing is best handled by the serverfault.com people.
The problem with attaching files inside the site does not appear to be happening any more, since I mucked round with several things. I'm not sure what did it unfortunately. I got nowhere on this and lost hours over it, so I ended up move all the files inside the webroot and now everything works. This is not ideal and I would still like to get to the bottom of it, but the workaround is acceptable.
I have been trying to work on integrating a NewsLetter for a companies local intranet and I keep running into the same error that everyone seems to be getting. I am running this on IIS 5.1 and on error exists at Server.CreateObject(ADODB.Connection), also the purpose of the ASP code is to read an Excel file
Error Type:
Server object, ASP 0196 (0x80040154)
Only InProc server components should be used. If you want to use LocalServer components, you must set the AspAllowOutOfProcComponents metabase setting. Please consult the help file for important considerations.
I have tried the solution to locate to my AdminScripts directory and setting the boolean value to True with cscript adsutil.vbs set /w3svc/aspallowoutofproccomponents True and then verified by cscript adsutil.vbs enum /w3svc > verified.txt
Opening up the textfile, it does show that the value is set to true but I run into the same error again when trying to access the ASP page. I am at a loss, I figured after reading all those people post questions that I'd ask the question myself.
I cringe at the sight of that error messages, please make my nightmare end.
Its a bizare error to be getting in the first place. Why would the simple ADODB.Connection object be considered an out-of-process component?
The only thing I can think of that might cause this is if someone has accidently dragged the ADO dll into a COM+ Service. Check the set of COM+ Services anything unusual installed there?
In an attempt to repair you could download the latest MDAC from Microsoft's download area and re-install it on your machine.
Enabling out-of-proc components to is not the answer ADODB.Connection should not be out-of-proc.
Next Step
Fire up Regedit, find in Keys the key value of {00000514-0000-0010-8000-00AA006D2EA4} under
HKEY_CLASSES_ROOT
You should find an InprocServer32 key with a default value: C:\Program Files\Common Files\system\ado\msado15.dll
The ProgID should ADODB.Connection.2.8.
I had to use:
Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"
in the command window to have the InProcServer32 key appear, thank you Anthony.
Everything is up and working now. My nightmares are over!
What setting might be missing or misapplied that would cause the same code that works on an IIS 6.0 server to fail on an IIS 5.1 server?
I've inherited this large Classic ASP application. It "caches" a series of files with funcitons in them using the ExecuteGlobal command. On both server, the command executes without error. However, when the application later tries to reference the functions that were 'cached', IIS 6.0 seems to work just fine while IIS 5.1 acts as though those functions never existed and I get errors to that effect.
The 5.1 system is for testing purposes on an XP Pro box. The 6.0 is our production system on Windows 2003.
It's taken a long time to isolate the problem (identical code failing in test but working in production) to this code. Setting up another server isn't an option unfortunately (budget restraints - no money to pay the support people or to rent space where all servers must be physically located - military installation).
What directions have I missed looking into?
Are "caching" and "using the functions that were cached" happens while processing the same HTTP request?
If the answer is "yes", then I've got no ideas, and I sincerelly hope someone else will answer your question.
If the answer is "no", then I'm pretty sure your problem is you "cache" the function into a different VBScript execution context.
Try (on the test server, of course :-) adding the following 2 lines in a file that defines the functions:
Dim g_FunctionsLoadedOK
g_FunctionsLoadedOK = "OK"
and the following line just before you're using the function:
if( Eval( "VarType(g_FunctionsLoadedOK)" ) <> vbString then
' Then you're sure there's no 'g_FunctionsLoadedOK' string variable defined in this VBScript execution context,
' so maybe you should reload the cached functions, or do something else..
end if
P.S. Unless the system you're dealing with is really large, why not use <!-- #include file="MyFile.inc" --> instead of that "ExecuteGlobal" approach?
Can you post the code for the fake ExecuteGlobal stuff, it might be possible to refactor it to get it to do what you want using Includes so that you don't have to break anything. Failing that a bit of find and replace might be needed :)