Classic ASP and .Net Com DLL website hangs on concurrent requests - asp-classic

The website hosted in IIS 10, website developed using Classic ASP and .Net Com DLL.
.Net dll registered by following comment
RegAsm.exe XXXX.dll /codebase
Website work fine when single user access the website but when multiple user give the concurrent requests then site starts loading.... and no response received, it's loading until we close the browser window.
When the website has long loading.... in one browser(chrome), if I tried same website in another browser(firefox) it's working normally but in chrome it's still loading...
I have verified log details there is No updates in iis log files, but we have logs for other requests until loading issues came
There is no updates in httperr file.
If we restart the IIS it took some time to restart and got the following WAS warning in system event log,
A worker process '####' serving application pool 'XXXXXXXX' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.

Related

IIS only processing one request at a time

We have an asp.net web application that works fine in our environment. One of our partners tries to the exact same code in their environment and can only process one request at a time. For example, there is only page that calls a long running stored procedure (5 minutes). If you call that page and the try to open a new page, the new page won't serve until after the first page has completed. We can see the request back up by looking at the worker processes for their application pool. They are running IIS 8.5 on a windows 2012 server. They're also running SQL Server 2016.
The database connection is structured the same as as in our environment. The stored procedure is not wrapped in a transaction. Any ideas what might be causing this behavior?
IIS also can work in the Debug mode, when it is enabled, Asp is limited to processing one request at a time in a single-threaded manner.
Open “InetMgr” or IIS manager, double click ASP under the IIS section of the website. Check the below settings in Asp section.
See the below discussion for more information.
IIS7 - only serves up one page at a time. It's a making me crAzY!

Application Insights is showing no data at all

I am experimenting with Application Insights (v0.14.0) and an ASP.NET application that I maintain, and I am finding its data collecting to be quite erratic. For a while, I was only getting client-side data being published (e.g. Browser Page Load Time) but none of the server metrics. I checked that the ApplicationInsights.config file was in both the web root folder and in the bin folder as per Application Insights not showing data in Azure Preview Portal, and that the correct instrumentation key was being used. We are not currently running the AI agent application.
Last night we deployed a new version of our application, without changing the AI configuration, and suddenly the server metrics started coming in. Hurrah! Unfortunately, 45 minutes later we deployed a single assembly hotfix to the application, and after the app pools had been recycled, the server metrics stopped, and this time the client metrics stopped as well.
Opening up the web application in my browser, I can see the AI.js script being loaded, and looking at the outbound network calls, I can see the telemetry being successfully submitted to AI:
Remote Address:23.101.207.84:443
Request URL:https://dc.services.visualstudio.com/v2/track
Request Method:POST
Status Code:200 OK
Any ideas what's going on?!
Unfortunately yesterday we had issue in the pipeline, that was causing latency of upto 4 hours. You can always get information on the service at http://aka.ms/aistatus. We are still working through some of the issues, but they are mostly resolved.

View state errors in development but not production

I have two websites which are more or less identical, both running on the same server, but under different app pools. The app pools are both configured to run with "NETWORK SERVICE" credentials.
On one website - call this the development copy, I receive the infamous "validation of view state MAC failed" error. This happens when a postback occurs after the page is idle for 20 minutes. I've been informed this is because I don't specify the machine key in the web.config or the machine config file. Manually recycling the app pool reproduces the error as expected. So my question is not about how to stop the issue, but rather I want to know why the error happens in dev but not production. The only difference between the setup of the two sites is the authentication method.
In the "basic settings" section of the IIS config, the dev version of the site is set to connect using a service account, while the production version is using "application user" (pass through authentication). Under authentication settings, both pages are configured with impersonation and windows authentication.
This is the only difference I can see. My knowledge of how IIS handles authentication at the site and app pool level is fairly limited. Is there a specific reason why one setup should result in the machine key being refreshed but the other does not?
After installing .NET 3.5 SP1 you may get Validation of viewstate MAC failed exceptions when doing post backs on ASP.NET pages.

ASP.net web service on server sometimes doesn't load

We have an ASP.net web service (.asmx) up on our server that one of our clients uses to get data from us.
They've been complaining about timeout issues occurring now and then. I decided to check out my code to see if anything could be causing the issue.
I went to our .asmx url using my internet explorer and saw that it just kept loading. This is the second time that I've noticed this happen. I just can't connect to the .asmx page. I get no error message, just keeps loading.
Now obviously, this would cause timeout errors for their client program as the service is unreachable. Any idea why this could be happening??
Also, where are the asp.net error logs usually stored on the server??? Is it in the same directory as the .asmx?? And do these error logs get generated automatically or do I have to put something in my code??
EDIT: Forgot to mention that the server where my web service resides is a Linux based server. I had to use MonoDevelop to package it for such.
Look at the application event viewer on the server. If any errors are occuring at the service level, you'll see them posted there. Timeout processes can be tricky to debug. If there are server resources that are being vied for by other application pools, this application might be getting the shaft. I would look at process usage of memory and cpu at the server first. If all looks well there, check into IIS and see what other applications reside with your service. If it is all good there, then I would look into your code for long running possibilities.

ASP.NET Application Goes to 500.21 ... until IIS Reset + Clear Tempoary ASP.NET Cache

We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.
After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.
If we do nothing but:
1) IISRESET
2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.
And then surf to our web applications, all is fine.
Then several hours later, however, the 500.21 errors return.
What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.
Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?
Text of Error:
Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx
Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers#modules are in system.webServer/modules#name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »
Thanks in advance,
Howard Hoffman
Faced the same problem and the fix was easy.
1) Open visual studio 2010 command prompt.
2) Run the command aspnet_regiis.exe -i
We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.
The problem consistently occurs in this scenario:
1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.
2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.
3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)
4) The application uses HttpServerUtility.Execute during that 1st request.
It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.
Our application is using an 'Integrated' IIS App Pool.
The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.
For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.
So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.
MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.
I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.
The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.
Thanks all for reading,
Howard Hoffman
1. IIS 7 throws an exception as shown in below
2. Open visual studio 2010 command prompt in Administrator mode and execute aspnet_regiis.exe -i
3. Problem fixed, as shown below ASP.Net Application and ASP.Net MCV Application are running smoothly.
The problem more likely is in the application code. The Temporary ASP.NET Files folder contains pre-compiled copies of your app and will be refreshed every time the applications files are accessed. You can pre-compile these files with aspnet_compiler.exe in the \Windows\Microsoft.NET\Framework\v2.0.50727\ folder. Use the -errorstack option allow for more information to be generated about the error you are getting. Long running applications that don't recycle will run into problems if they use a lot of memory or retain large amounts of data in an inproc session state. if your sessions contain large amounts of information, consider using a sqlserver-based session manager.

Resources