How to troubleshoot ASP.NET app never loading in IIS - asp.net

I have an ASP.NET app (.NET Framework) deployed to an ec2 instance running Windows Server and IIS. The app never loads in my browser - it just spins forever. This is true for .aspx pages as well as simple static .html pages.
What I've tried so far
Loading the website as localhost from a browser on the server itself...no luck
Website physical path is correct
Website binding matches what I've used on other servers
<binding protocol="https" bindingInformation="*:443:*" sslFlags="0" />
Windows permissions look OK (both the app pool user and IIS_IUSRS have full control)
The app pool looks OK (Mode=Integrated; Identity=ApplicationPoolIdentity)
Server Roles and Features look OK (Web Server role, .NET Framework 3.5/4.6 Features, etc.)
This ASP.NET app works fine on other machines
I created a simple "HelloWorld" website in IIS on this same server - it loads fine
I tried adding logging to Global.asax.cs, but it seemingly never gets hit
I don't see any traffic in IIS logs
I don't see any obvious issues in the Windows Event Viewer (I do see lots of activity, but nothing that points to a problem with my app, as far as I can tell)
Disabled proxy settings in Chrome
Viewed network traffic in Chrome - the request just shows as "Pending" and never returns
This is frustrating, because I can't seem to get any logs or information about what might be the problem. How can I troubleshoot this issue?

Related

iis not working with domain user

I have a problem which I cannot solve after some days. Simply, we have a web application which should run as a domain user (domain\user). We can do this in IIS (ver 8.5) manager in one server (statging) through application pool settings but when we do the same on another server (production) it is not working.
By not working I mean : If you browse that website and come back to the application pools tab, you see that it is stopped! and you receive HTTP Error 503. The service is unavailable. in the browser.
I have tried many things and solutions on SO but no success so far.
but when we do the same on another server (production) it is not working:
1.) Check Website Browsing Directory if enabled.
2.) Check Framework in application pools.
3.) Is your IIS set up correctly?
Hope it helps

Access denied to Temporary ASP.NET Files folder after iisreset when browsing site using the server's own Internet Explorer

Configuration:
Windows Server 2008 R2/IIS 7.5
ASP.NET web application using Windows Integrated Authentication. Application pool identity is set to NetworkService. Targeting .NET Framework 2.0. Managed Pipeline mode = Classic.
Full permissions granted to the Temporary ASP.NET Files folder for the Users group and the Internet Guest Account
Logged into server as a test user account (let's call it testuser) which is a member of the Administrators group
User Account Control is on
Internet Enhanced Security is off
Internet Explorer is using all the default security settings and all Compatibility View settings are off
Now I do the following:
iisreset.exe
clear Temporary ASP.NET Files folder
open Internet Explorer
browse to the local ASP.NET web site => success
close Internet Explorer
iisreset.exe
open Internet Explorer
browse to the local ASP.NET web site => FAIL
So far, I have found a few things I can do to keep the site working after an iisreset.exe (each of these work individually, i.e. they do not have to be combined):
Turn off User Account Control
Log in as the Administrator
Run Internet Explorer "As Administrator..." (instead of defaulting to the testuser account)
Use Google Chrome or Mozilla Firefox instead of Internet Explorer(?!?) Those two browsers do not have to be run using the Administrator account but work perfectly well running under the user account and with User Account Control turned on.
Browse the site using an Internet Explorer instance running on an external machine
This problem does not exist on Windows Server 2003. It would appear to be related to User Account Control somehow.
It makes no difference if the user is a member of the Administrators group or not.
Using Process Monitor, it would appear that the access denied problem happens when NetworkService (w3wp.exe) is impersonating the user, but given all the permissions granted to the Temporary ASP.NET Files folder, this still does not make much sense.
The question is:
Why does this only occur with the local Internet Explorer browser, running as a non-administrator user? I would like to use the local Internet Explorer browser for testing, but having to clear the Temporary ASP.NET Files folder after an iisreset is annoying.
What makes Internet Explorer different from Chrome or Firefox (which both work) in this scenario? I could understand if this was something that affected all local browsers, but this is not the case.
I could understand if my web application was doing something special when detecting that Internet Explorer is being used as the client browser, but I do not believe that to be the case and we are talking about an assembly binding failure here - I am not trying to access some arbitrary folder.
EDIT:
The tests above were done using Internet Explorer 8. I have since tried Internet Explorer 9 on the same machine, but with the same results.
If I enable ASP.NET Impersonation for the web site, the problem goes away - but I still would like to know why it does not work for a local Internet Explorer when ASP.NET Impersonation is disabled.
EDIT 2:
What I failed to mention the first time around is that logging in is a two-step process: When accessing the application (let's call it "MyWebApp"), you are redirected to a MyWebApp/Login directory where you will be prompted for your Windows credentials before granted access to the login page residing in that Login directory.
This always works.
After entering your application credentials (in case the code in the login page does not recognize your Windows credentials), you are redirected to a page in the root folder.
The Authentication settings for MyWebApp and MyWebApp/Login are as follows:
MyWebApp MyWebApp/Login
-------- --------------
Anonymous Authentication Enabled Disabled
ASP.NET Impersonation Disabled Enabled
Basic Authentication Disabled Disabled
Digest Authentication Disabled Disabled
Forms Authentication Enabled Enabled
Windows Authentication Enabled Enabled
In both cases, I am getting the "Challenge-based and login redirect-based authentication cannot be used simultaneously" warning.
These settings date back to before I got involved with the project, but that is besides the point. Right now I am only interested in what it takes to get it right - preferably a set of settings that will work for IIS 6.0 and 7.x alike.
Setting ASP.NET Impersonation = Disabled for "MyWebApp/Login" appears to be another way of making my problem go away, but clearly there is more to be done here.
The issue is almost certainly related to Internet Explorer using Windows authentication rather than Basic Authentication (what you'd likely get with FF or Chrome). The combination of Windows authentication and ASP.NET impersonation. If you enable NTLM authentication in Firefox, you will likely see the same behavior there. Likewise, disabling Windows authentication (forcing IE to use basic) or disabling impersonation will likely cause IE to behave like Firefox.
I cannot imagine that browsers have anything to do with it, but if you experienced differences, it must be true.
For ASP.NET to be able to compile an ASPX file, 2 things are imported (as we found out today:
Write access to the ASP.NET Temporary files dir (where the compiled DLL is written)
Write access to the Windows TEMP (where csc.exe writes intermediate files like *.obj)
Which user should have acces there? Depends. In our case the Application Pool user. In your case maybe the impersonated user. Or the IUSR. To me, that part is still obscure.

Sitefinity, IIS 6 WCF services return home page

I'm evaluating Telerik's Sitefinity CMS. On my dev box (Win7 x64/IIS7), everything works great.
However, when I deploy the site to our Win2k3/IIS6 server, the backend system doesn't work correctly. According to fiddler, anytime the browser makes an AJAX request to a WCF (.svc) service within the application, the home page is being returned.
Any suggestions?
I've tried:
re-registering ASP.net
Re-registering WCF with
\windows\microsoft.net\framework\v3.*\wcf\servicemodelreg -i
Made sure that the .svc extension is allowed
Deleted and recreated the site in IIS
Argh. Suggestions?
You can find installation information and other tips on getting Sitefinity up and running by visiting the documentation.
This turned out to be related to the IIS6 application pool identity, permissions on the web folder, and having multiple authentication methods checked in site properties. By playing with those things I was able to get it to work.
As a test, I ran the site through the Sitefinity project manager app (using its integrated Cassini server), and everything worked correctly.

How do I set up debugging under my local IIS for an MVC3 app?

My host is having issues getting my MVC3 app to work on their server, so I though I'd check it out myself. Until now I've been too busy developing under the built in server to worry about IIS, but today I tried my first deployment to the host with no joy. Then I tried one to my local IIS, with no joy. Then I tried telling VS to use IIS for debugging, to maybe resolve some local issues, with no joy.
What steps and configuration are required to use local IIS 7.5 to debug an MVC3 application?
EDIT: Going through a browser, after clearing up a permission problem for my Windows user on Temp ASP.NET Files, I now site with a I get a HTTP Error 403 (Forbidden), but the occassional basic auth login dialogue. Here I have tried a Forms auth user, my normal Windows user, and my Windows admin user, all to no avail.
When I try and debug under VS, I get a 500, internal error.
THE PLOT THICKENS: When I enable directory browsing on the site, I get a proper directory listing for the site root url. This suggests the the MVC3 routing is not working, but why not?
If you're getting a directory listing that means there's not a default file set (for IIS6). It usually means the request wasn't routed to IIS to deal with. thing are slightly different with II7 & it's integrated pipeline.
Simon

Precompiled .NET app receiving "Internet Explorer cannot display the webpage"

We have a web server that is running many web applications. When I took over this server, I noticed that the sites were not precompiled, so in an effort to clean it up, I precompiled the site using the Publish option in VS2008 (and allow the precompiled site to be updatable).
When I deployed the site to the web server, the site stopped working - In IE, I get "Internet Explorer cannot display the webpage" - in firefox I get "Unable to connect. Firefox can't establish a connection to the server at >>sub.domain.com<<". Here are a few things I've noticed:
I am able to manually browse to the one static .html file that is part of the site
If I replace the precompiled files on the server with uncompiled code, the site works fine
If I switch the application pool to use .NET 4.0, I get errors with duplicate system.web.extensions module, which I would expect to see with an application built for .NET 3.5.
When I initially browse to the site after a fresh IISRESET, the app redirects to /Login.aspx, which the web.config defines as the forms auth login page. It then redirects to /default.aspx and displays the error in question.
CustomErrors is OFF, debugging is ENABLED, and yet I don't get a helpful .NET error page, and I see no System or Application-level events in the Windows event log.
Any hints as to why this might be happening? I was able to successfully precompile another site on the same server with ZERO problems.
I found the problem myself. The login page was redirecting to HTTPS if the host header wasn't localhost. I noticed that in the uncompiled site, someone manually went into the .VB file for the login page and added the specific domain for the beta site into this check, preventing the redirect to HTTPS. I copied the code into my local, recompiled, and deployed, and now the site works as expected.

Resources