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.
Related
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.
Sorry about the mishmash of words in the title, but that's how confused I am. I can't even summarize the error I'm getting in a simple sentence.
This flex/amfphp application works fine on my computer, even though it accesses an Oracle database on another server. However, when I try to access it from another computer, this is the error I get. I'll try and put the most relevant code in. (My browser tell me this is an ActionScript error).
Fault faultString="Send failed"
faultCode="Client.Error.MessageSend"
faultDetail="Channel.Security.Error error Error #2048: Security Area Violation..
Couldn't load data from http://localhost/.../amfphp/gateway.php
As I said before, it works on my machine for some reason. Now, when I try to access this remotely from other machines, it seems that the PHP engine is looking for gateway.php on the localhost of that machine?? Does this mean that PHP is looking for gateway.php on the client's localhost rather than on the server??
Correct me if I'm wrong, and thanks in advance
Your services-config.xml in Flex propably points to http://localhost/.../amfphp/gateway.php
You'll need to change the endpoint in that XML file and recompile the application.
You could also create your ChannelSet at runtime. In that case you don't need the services-config.xml anymore. Take a look at http://raghuonflex.wordpress.com/2008/06/05/endpointatruntime/ for some inspiration...
I'm having a simple ASP.NET application hosted on my local IIS6, under Vista.
It contains a button that when I click I execute a piece of code for recognizing the text in a WAV file (using the System.Speach.Recognition.SpeechRecognition class) and display the text in a label.
The code works great on a desktop application, and it almost works on the web one... I say almost, because if I debug, I can see that the recognizer returns the correct text from the WAV, I can see that I am finishing the handler for the button click with no error, but nothing gets displayed in my page, and the page appears like loading... it's hanging, or something... No errors, no timeout, nothing. Just loading...
I don't know if this detail helps, but in order to make the piece of code that was already working on the desktop application work on the web application, I had to set the identity of the ApplicationPool of my application to LocalSystem (security breach, I know). Otherwise, I would have received a Access Denied error (0x80070005(E_ACCESSDENIED)).
Do you have any ideea why the call hangs like that? I'm fighting with this for more than two days, time pressures me, and I have no clue... Any help is really welcomed!
Thanks!
After another one week of stuglles, I found an overcome to the problem. I'm posting this just so other that might have this problem find the solution faster.
The solution was to call the method for making the speech recognition on a different thread. I think this forced the release of all resources in that thread after the recognition ended.
I cannot make any sense why this even happened on the first place (I used using blocks and I closed and disposed all the object in all the imagining ways), but I suspected to be a memory release problem...
Anyway, a very simple call on another thread fix it!
I currently have an ASP Classic script that runs every 15 minutes (via scheduled task). The task is responsibly for opening up Internet Explorer and loading the create report ASP page. Once the page is done loading, I have Javascript at the bottom of the page responsible for closing the IE window. We often run into issues where the script will hang for whatever reason and not reach the end. Thus, we end up with multiple IE instances at the end of the day. However, generating report in this manner seems very clunky and unnatural. I am using IIS and switching over to .NET.
Would anyone have any alternatives?
Thank you.
Why don't you just call your ASP page using a plain XmlHttpRequest script in vbscript, instead of running Internet Explorer?
Set http = CreateObject("Microsoft.XmlHttp")
http.open "GET", "http://yourserver/yourReportPage.asp", FALSE
http.send ""
Dim content
content = http.ResponseText
set http = nothing
Use this instead of calling IE.
Now, there may be better way to generate the reports, but at least this way you get rid of the scary IE automation.
We use SQL Reporting Services for this very purpose. We used to have a system very similar to yours, but haven't had any problems since migrating to RS.
Does it have to be called through the HTTP interface? That is, can you make a command-line project that does the same thing? If you can, you can easily set up a scheduled task to call the command-line app every 15 minutes.
Something that needs to run on a regular schedule seems like it would be related to a database. If that's the check out SQL Server Agent (presuming SQL Server) and store your results into a table that can be queried quickly from the ASP page.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.